Security and trust

What the admin can and cannot do, where the keys are, what is stored about you, and how to report a problem. Every statement links to the file or the on-chain record behind it.

Last checked 2026-10-11. The same text is in SECURITY.md.

What you trust

You trust one key with each epoch's payout list. The publisher key decides which wallets an epoch pays and how much, and the program cannot tell a fair list from an unfair one: it could pay its own wallet any SOL in the vault that is not already assigned.
Evidence: publish_epoch.rs · program review
That key lives on a Ledger hardware wallet, and a community's vault is funded one epoch at a time, just before it pays, to limit what is exposed. Unclaimed SOL from earlier epochs stays in the vault, and the same Ledger can upgrade or close the program, so its control reaches everything still in the vault.
Evidence: custody policy · key registry
Hyphae does not verify that an X account belongs to the member who submits it, or that a post really replies to or quotes the raid's post; both are recorded as unverified. A score is not proof of authorship.
Evidence: X handles · submission record
The rest can be checked: the program on chain is byte for byte its public source, every score shows its reasoning, and every correction stays visible.
Evidence: verify the build · decision history

What the admin can and cannot do

On chain, the program enforces the limits. Off chain, the operator's tools do.

The program has three instructions: create a community, publish an epoch, and claim. None of them withdraws or sweeps the vault.
Evidence: lib.rs
An epoch's payout root is published once and never changed: the epoch account can only be created, and no instruction writes its root again.
Evidence: publish_epoch.rs
SOL assigned to an earlier epoch and not yet claimed cannot be assigned again.
Evidence: publish_epoch.rs
The fee is 3% of each epoch's pot, paid to an address set when the community is created. No instruction changes the fee or that address.
Evidence: constants.rs · initialize_community.rs
Each wallet claims its leaf once. The claim rebuilds the leaf from the signing wallet, so nobody can claim for someone else.
Evidence: claim.rs · program.rs
The program can be upgraded, and an upgrade could change any of the above. The upgrade key is the same Ledger, and any upgrade is announced in the public program repository before it is used.
Evidence: custody policy · mainnet deploy receipt
A score is corrected only with the operator's command-line tool, with a reason and evidence. The correction is a new revision; the old one stays, and the contribution's public page shows who corrected it and why. A correction made after an epoch closes does not change that epoch's payout.
Evidence: reward-correct.ts · decisions.ts
An epoch is judged by the rubric and the scorer it pinned: an AI scoring prompt, or a Jev question set. A configuration change is a proposal that takes effect no earlier than the next epoch, and at least two epochs after the last change. Each epoch's configuration is public in the read API; pending proposals are not public yet.
Evidence: config.ts · Jev scorers · read API
During the pilot, the founder can amend an open epoch's scorer (its scoring prompt or Jev question set) with a public, announced, non-retroactive record. The record is made before it takes effect and says who, why and from when. An epoch's amendments form a chain: each starts from the scorer in force, a new one can be recorded only once the last is in effect, and there is no way back to the epoch's original scorer. An amendment applies only to contributions admitted from its time, and the rubric, credit rules and payout rules cannot change that way. The epoch page and the read API list every amendment, and the epoch's audit record commits them. First used on 2026-10-07: epoch 2 scores with reward-eval/2 from 18:00 UTC.
Evidence: amendment.ts · commitments.ts · read API · rubric changelog
Only the community's designated admin opens, closes or cancels a raid, and closing or cancelling needs a stated reason, which is stored. Whether reward intake is open or paused is public in the read API.
Evidence: raid.ts · raid-lifecycle.ts · read API

What is on chain and what is not

On chain, for each epoch: the payout root, a hash of the epoch's audit record, the pot, the fee and the totals. For each claim: the wallet, its score, the amount and an evidence hash.
Evidence: state.rs
Off chain, in a Postgres database: the text and links of contributions, what the AI was asked and answered, decisions and corrections, rubrics and configurations, and member and wallet records.
Evidence: database schema
The audit record behind the on-chain hash is stored but not yet published. Today you can check your own leaf and proof against the root, but not recompute a whole epoch.
Evidence: read API types · read API

Keys and custody

The program's only upgrade authority on mainnet, and the key that publishes Hyphae Lab's epochs, is the Ledger 2kz1Zq8UDm9Hq6XwPW6cViQZe7aySEBGk1gLWN8gofjR. It was read back from the chain at deploy.
Evidence: Ledger on Solana Explorer · mainnet deploy receipt
Hyphae Lab's fee goes to the MYCEL Treasury, Squads vault rRceAUBNsnZKJDytjdHfCdqgTJGoDagtKujfvaBu7MK, which needs 2 of 3 signers to move funds. It was fixed when the community was created on mainnet on 2026-10-10 and cannot change afterwards.
Evidence: vault on Solana Explorer · fee ruling · October 10 mainnet receipts
The temporary deployment keys were deleted after their recorded recovery checks. This is a historical operator attestation, not something a chain read can prove.
Evidence: key registry

Verifiable build

Program EAz8WkyUbGqr3ewSLpk94GWEoiWsvMENE5zV7Tvh4d6E runs on mainnet and devnet. Rebuilding its public source in Anchor's pinned Docker image gives the solana-verify hash 7e902d1b5f8d8c49dfd199ec2e7bf44139b56524d98408f1556e14f4e9ab43ac, the same hash the chain reports for the deployed program.
Evidence: verify the build · mainnet deploy receipt
Not done yet: the on-chain verification record that lets explorers show the program as verified.
Evidence: verification status

Independent reviews

Hyphae has been independently reviewed by AI reviewers, not a third-party audit. Each review below was done by a model from a different family than the one that built the change. Curated results and material findings are public; internal working reports are private.

2026-09-25, the on-chain program: three Codex rounds, approved in the third. The finding that the admin can publish any root was kept as the pilot's custody model, not fixed.
Evidence: program review
2026-10-03, community setup: Claude Opus approved it for local use with two fixes required, then approved the fixes.
Evidence: review results
2026-10-04, the read SDK and the adopter demo: Claude Opus accepted them after one round of fixes.
Evidence: review results
2026-10-04, raid alerts and the member journey (receipts, raid lifecycle, operator view): Claude Opus accepted both after rounds of fixes.
Evidence: review results
2026-10-06, the wallet link page: Codex accepted it with one advisory, fixed.
Evidence: review
2026-10-06, the scoring prompt reward-eval/2: Codex found the scoring itself clean and two defects in the evaluation script; both were fixed, and the fix was not reviewed again.
Evidence: review
2026-10-07, prompt injection (our own test, not a review): seven replies that try to instruct the AI scorer each earned 0 in 3 of 3 runs, and a real reply with an injection appended was not scored higher.
Evidence: result
2026-10-07, the Jev question set v4 (our own test, not a review): on 28 fixed reward cases it was right in 84 of 84 runs, all eight injection attempts at 0. On 64 new replies the founder labeled blind (then ruled on nine that broke his own written rules), it zeroed 2 of 36 he labeled pass and passed 1 of 24 he labeled zero; those misses are listed.
Evidence: calibration

When we get something wrong

Scores are never edited in place. A correction is appended with its reason and evidence and shown on the contribution's page.
Evidence: decisions.ts · receipt page
Changes to the rubric or the scorer are listed with the reason and the evidence behind them.
Evidence: rubric changelog
Public release milestones and known limits are documented with evidence. Owner planning, approvals and working notes are private.
Evidence: build log

Report a problem

Report a security problem privately through GitHub's private vulnerability reporting on the public program repository. Please do not post it in the Telegram group or on X first. There is no paid bug bounty.
Evidence: open a private report

Privacy and deletion

We store your Telegram user ID and username, up to three X handles, the wallet you signed with and its history, the text and links you submit, and the AI's scoring of them.
Evidence: database schema
Public receipts show a contribution's text, link, scores and reasons, a random member ID and the verified wallet. They never show your Telegram ID or username.
Evidence: read API
These services receive some of it: Anthropic and TypeSafe (their AI models read your contribution and the post it answers; TypeSafe's Jev only for an epoch that pins it), Telegram (the bot), X (public post data through X's embed service), Neon (the database), Fly.io (the API and worker), Vercel (this site, which sees visitors' IP addresses and passes them to the API on Fly.io for rate limiting) and a Solana RPC provider (wallet balance checks).
Evidence: service settings · Jev client · X embed reader · site's API client · rate limit
We keep this data while the community runs. On request, within 30 days, we delete your Telegram ID, username and X handles and end your wallet link. We cannot delete what is on Solana or the public receipts, because they are the audit trail: a receipt keeps the contribution's text and link (an X link names the account that posted it), its scores, and the wallet that was verified when its epoch closed.
Evidence: build log · read API
To ask, use the private report link above or ask your community's admin in Telegram. Deletion is done by hand today; there is no button for it yet.
Evidence: open a private report

What you trust

You trust one key with each epoch's payout list. The publisher key decides which wallets an epoch pays and how much, and the program cannot tell a fair list from an unfair one: it could pay its own wallet any SOL in the vault that is not already assigned.

Evidence: publish_epoch.rs · program review

That key lives on a Ledger hardware wallet, and a community's vault is funded one epoch at a time, just before it pays, to limit what is exposed. Unclaimed SOL from earlier epochs stays in the vault, and the same Ledger can upgrade or close the program, so its control reaches everything still in the vault.

Evidence: custody policy · key registry

Hyphae does not verify that an X account belongs to the member who submits it, or that a post really replies to or quotes the raid's post; both are recorded as unverified. A score is not proof of authorship.

Evidence: X handles · submission record

The rest can be checked: the program on chain is byte for byte its public source, every score shows its reasoning, and every correction stays visible.

Evidence: verify the build · decision history

What the admin can and cannot do

On chain, the program enforces the limits. Off chain, the operator's tools do.

The program has three instructions: create a community, publish an epoch, and claim. None of them withdraws or sweeps the vault.

Evidence: lib.rs

An epoch's payout root is published once and never changed: the epoch account can only be created, and no instruction writes its root again.

Evidence: publish_epoch.rs

SOL assigned to an earlier epoch and not yet claimed cannot be assigned again.

Evidence: publish_epoch.rs

The fee is 3% of each epoch's pot, paid to an address set when the community is created. No instruction changes the fee or that address.

Evidence: constants.rs · initialize_community.rs

Each wallet claims its leaf once. The claim rebuilds the leaf from the signing wallet, so nobody can claim for someone else.

Evidence: claim.rs · program.rs

The program can be upgraded, and an upgrade could change any of the above. The upgrade key is the same Ledger, and any upgrade is announced in the public program repository before it is used.

Evidence: custody policy · mainnet deploy receipt

A score is corrected only with the operator's command-line tool, with a reason and evidence. The correction is a new revision; the old one stays, and the contribution's public page shows who corrected it and why. A correction made after an epoch closes does not change that epoch's payout.

Evidence: reward-correct.ts · decisions.ts

An epoch is judged by the rubric and the scorer it pinned: an AI scoring prompt, or a Jev question set. A configuration change is a proposal that takes effect no earlier than the next epoch, and at least two epochs after the last change. Each epoch's configuration is public in the read API; pending proposals are not public yet.

Evidence: config.ts · Jev scorers · read API

During the pilot, the founder can amend an open epoch's scorer (its scoring prompt or Jev question set) with a public, announced, non-retroactive record. The record is made before it takes effect and says who, why and from when. An epoch's amendments form a chain: each starts from the scorer in force, a new one can be recorded only once the last is in effect, and there is no way back to the epoch's original scorer. An amendment applies only to contributions admitted from its time, and the rubric, credit rules and payout rules cannot change that way. The epoch page and the read API list every amendment, and the epoch's audit record commits them. First used on 2026-10-07: epoch 2 scores with reward-eval/2 from 18:00 UTC.

Evidence: amendment.ts · commitments.ts · read API · rubric changelog

Only the community's designated admin opens, closes or cancels a raid, and closing or cancelling needs a stated reason, which is stored. Whether reward intake is open or paused is public in the read API.

Evidence: raid.ts · raid-lifecycle.ts · read API

What is on chain and what is not

On chain, for each epoch: the payout root, a hash of the epoch's audit record, the pot, the fee and the totals. For each claim: the wallet, its score, the amount and an evidence hash.

Evidence: state.rs

Off chain, in a Postgres database: the text and links of contributions, what the AI was asked and answered, decisions and corrections, rubrics and configurations, and member and wallet records.

Evidence: database schema

The audit record behind the on-chain hash is stored but not yet published. Today you can check your own leaf and proof against the root, but not recompute a whole epoch.

Evidence: read API types · read API

Keys and custody

The program's only upgrade authority on mainnet, and the key that publishes Hyphae Lab's epochs, is the Ledger 2kz1Zq8UDm9Hq6XwPW6cViQZe7aySEBGk1gLWN8gofjR. It was read back from the chain at deploy.

Evidence: Ledger on Solana Explorer · mainnet deploy receipt

Hyphae Lab's fee goes to the MYCEL Treasury, Squads vault rRceAUBNsnZKJDytjdHfCdqgTJGoDagtKujfvaBu7MK, which needs 2 of 3 signers to move funds. It was fixed when the community was created on mainnet on 2026-10-10 and cannot change afterwards.

Evidence: vault on Solana Explorer · fee ruling · October 10 mainnet receipts

The temporary deployment keys were deleted after their recorded recovery checks. This is a historical operator attestation, not something a chain read can prove.

Evidence: key registry

Verifiable build

Program EAz8WkyUbGqr3ewSLpk94GWEoiWsvMENE5zV7Tvh4d6E runs on mainnet and devnet. Rebuilding its public source in Anchor's pinned Docker image gives the solana-verify hash 7e902d1b5f8d8c49dfd199ec2e7bf44139b56524d98408f1556e14f4e9ab43ac, the same hash the chain reports for the deployed program.

Evidence: verify the build · mainnet deploy receipt

Not done yet: the on-chain verification record that lets explorers show the program as verified.

Evidence: verification status

Independent reviews

2026-09-25, the on-chain program: three Codex rounds, approved in the third. The finding that the admin can publish any root was kept as the pilot's custody model, not fixed.

Evidence: program review

2026-10-03, community setup: Claude Opus approved it for local use with two fixes required, then approved the fixes.

Evidence: review results

2026-10-04, the read SDK and the adopter demo: Claude Opus accepted them after one round of fixes.

Evidence: review results

2026-10-04, raid alerts and the member journey (receipts, raid lifecycle, operator view): Claude Opus accepted both after rounds of fixes.

Evidence: review results

2026-10-06, the wallet link page: Codex accepted it with one advisory, fixed.

Evidence: review

2026-10-06, the scoring prompt reward-eval/2: Codex found the scoring itself clean and two defects in the evaluation script; both were fixed, and the fix was not reviewed again.

Evidence: review

2026-10-07, prompt injection (our own test, not a review): seven replies that try to instruct the AI scorer each earned 0 in 3 of 3 runs, and a real reply with an injection appended was not scored higher.

Evidence: result

2026-10-07, the Jev question set v4 (our own test, not a review): on 28 fixed reward cases it was right in 84 of 84 runs, all eight injection attempts at 0. On 64 new replies the founder labeled blind (then ruled on nine that broke his own written rules), it zeroed 2 of 36 he labeled pass and passed 1 of 24 he labeled zero; those misses are listed.

Evidence: calibration

When we get something wrong

Scores are never edited in place. A correction is appended with its reason and evidence and shown on the contribution's page.

Evidence: decisions.ts · receipt page

Changes to the rubric or the scorer are listed with the reason and the evidence behind them.

Evidence: rubric changelog

Public release milestones and known limits are documented with evidence. Owner planning, approvals and working notes are private.

Evidence: build log

Privacy and deletion

We store your Telegram user ID and username, up to three X handles, the wallet you signed with and its history, the text and links you submit, and the AI's scoring of them.

Evidence: database schema

Public receipts show a contribution's text, link, scores and reasons, a random member ID and the verified wallet. They never show your Telegram ID or username.

Evidence: read API

These services receive some of it: Anthropic and TypeSafe (their AI models read your contribution and the post it answers; TypeSafe's Jev only for an epoch that pins it), Telegram (the bot), X (public post data through X's embed service), Neon (the database), Fly.io (the API and worker), Vercel (this site, which sees visitors' IP addresses and passes them to the API on Fly.io for rate limiting) and a Solana RPC provider (wallet balance checks).

Evidence: service settings · Jev client · X embed reader · site's API client · rate limit

We keep this data while the community runs. On request, within 30 days, we delete your Telegram ID, username and X handles and end your wallet link. We cannot delete what is on Solana or the public receipts, because they are the audit trail: a receipt keeps the contribution's text and link (an X link names the account that posted it), its scores, and the wallet that was verified when its epoch closed.

Evidence: build log · read API

To ask, use the private report link above or ask your community's admin in Telegram. Deletion is done by hand today; there is no button for it yet.

Evidence: open a private report