WORM (BETH proof-of-burn)

transfer Assessed on Ethereum (chain 1)worm.cx

Ratings apply to this deployment only. Treat them as unverified for other chains. Why this deployment: The contracts README (worm@b34b507d README.md L9-L19) lists deployments only on Ethereum mainnet, and the official CLI maps network "mainnet" to BETH 0x5624…9Cf8 (worm-miner@fd23cd80 common/src/contracts/network.rs L58-L66). Unit: BETH (proof-of-burn mint and spend), its two Groth16 verifiers, the Staking reward pool that mintCoin pays, and the BETHToETH hook used by the official send flow. Excluded: the WORM mining token, distributors and ICO contracts (not in the payment path), and Sepolia.

At a glance

Category: Protocols for privacy-preserving transfers
Chain: Ethereum
CROPS tally: 17 of 23 hold up
Security audits: 2 published
Offered: Everywhere
Last edited: 2026-10-13 · History

Censorship Resistance2 PartialWeakest: Neutral settlement, disclosed filtering; Token and chain freeze risks disclosed
Open1 WeakWeakest: Can be self-hosted
Free0 FailsWeakest: Open-source licences
Privacy0 FailsWeakest: Endpoints can be changed
Security1 WeakWeakest: Audits and bug bounty

Holds up 17

3 StrongAdmin pause or freeze powers
3 StrongSettle without the provider
3 StrongReliance on hosted services
2 PartialNeutral settlement, disclosed filtering
2 PartialToken and chain freeze risks disclosed
2 PartialContracts verified onchain
2 PartialWhole stack published
2 PartialInterfaces and data export
2 PartialProtection against relicensing
2 PartialNo proprietary dependencies
2 PartialTracking and analytics
2 PartialPayments linkable onchain
3 StrongWho holds funds in transit
3 StrongWho can upgrade the code
2 PartialToken approval scope
2 PartialFunds safe if provider disappears
2 PartialSecrets and webhook handling

Not yet evidenced 0

Every criterion has evidence.

Where it is offered

Offered everywhere, per the provider's code or documents. Checked 2026-10-09. Not scored.

BETH has no address or country check, and both official clients (the worm.cx frontend source and the worm-miner CLI) contain no geolocation or country gate. We found no terms page listing countries; the frontend source has no terms text. Judgment call: the hosted prover at prover-2.worm.cx, used by the frontend's send flow, might filter requests, which we could not see. The CLI path avoids it.

Evidence (2)2 verified

Verified
mintCoin has no caller, address or country restriction.
worm-privacy/worm · src/BETH.sol
commit eab0f53b11 · checked 2026-10-09
Verified
A grep of the frontend source for country, geolocation, ipapi, sanction and chainalysis finds nothing.
worm-privacy/worm-privacy.github.io · src
commit 5c309e2548 · checked 2026-10-09

Censorship Resistance

Who can block valid use, and can users route around them?

2 PartialPillar rating: weakest of 5
5 of 5 Partial or better

What would raise this pillar

Neutral settlement, disclosed filtering reaching Strong: Settlement contracts contain no address or geographic filtering, and any filtering in the SDK, frontend, or backend is disclosed in code or a versioned repo document, names its list source, and is bypassed by the direct settlement path (C2 at least 2). Requires every required component in the request path to be public, or a trace.
Token and chain freeze risks disclosed reaching Strong: Supported tokens and chains enumerated in code and docs, with issuer freeze/blacklist powers and sequencer or forced-inclusion assumptions stated to payees.

Admin pause or freeze powers

Can any privileged role stop, freeze, or block payments through the settlement contracts, and how is that role constrained? C1

3 Strong

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

No one can stop, freeze or block a burn or mint. Burning is a plain ETH transfer to an address with no known key. Minting is open to any caller with a valid proof. BETH has no owner, and its one-time initializer has been cleared onchain. The Staking contract it pays a fee into also has no admin.

Evidence (3)3 verified

Verified
BETH inherits only ERC20, ReentrancyGuard and ERC20Permit; its one privileged role, initializer, can only set the reward pool once and then zeroes itself (L54). There is no pause, blacklist or allowlist. This file is identical to the Sourcify source of 0x5624…9Cf8.
worm-privacy/worm · src/BETH.sol
commit eab0f53b11 · checked 2026-10-09
Verified
initializer() returns the zero address and rewardPool() is the Staking contract 0x03d4…60B7, so the one-time role has been used and cleared.
0x5624…9Cf8 on sourcify.dev
0x5624…9Cf8 explorer · Sourcify · block 26153606 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Verified
Staking, which every mintCoin calls through depositReward, has no owner, no pause and no proxy (EIP-1967 implementation slot zero).
0x03d4…60B7 on sourcify.dev
0x03d4…60B7 explorer · Sourcify · block 26153606 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Settle without the provider

Can a payer or payee complete settlement by calling the public contracts directly, without the provider's API, signer, or relayer? C2

3 Strong

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

A payer can send ETH to a burn address that commits to the payee, and anyone can then call mintCoin with a locally generated proof. The payee receives BETH, or ETH through the optional swap hook. No signature, relayer or API from the provider is needed. Addresses are in the README and the CLI, and the ABI is committed in worm-miner. The proof must use a block hash from the last 256 blocks, which any client can choose at mint time. We did not run a transaction. Note that the payee receives BETH, a token whose ETH value depends on market liquidity; the burned ETH itself cannot be recovered.

Evidence (3)3 verified

Verified
mintCoin is public with no caller check. The receiver, broadcaster fee and prover fee are bound into the burn address through burnExtraCommitment (L176-L187), so whoever submits cannot change the payee. The payer chooses the receiver at burn time.
worm-privacy/worm · src/BETH.sol
commit eab0f53b11 · checked 2026-10-09
Verified
The official CLI documents burn with a --receiver-address, and mint with a broadcaster that may be your own private key; --prover-fee defaults to 0 "in case you want to prove it yourself".
worm-privacy/worm-miner · README.md
commit fd23cd8012 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Verified
The deployed BETH is a Sourcify exact match to that source and has no proxy (EIP-1967 implementation slot zero).
0x5624…9Cf8 on sourcify.dev
0x5624…9Cf8 explorer · Sourcify · block 26153606 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Reliance on hosted services

Does the payment flow require a relayer, paymaster, bundler, or API that only the provider runs? C3

3 Strong

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

No hosted service is required. The CLI proves locally from public parameters and can broadcast from any key. Prover and broadcaster code is public (worm-miner server). Fees for a third-party prover or broadcaster are fixed in the burn commitment, so the market is open to anyone. The official one-page send flow does default to the WORM-run prover. Judgment call: 3, because the protocol path does not need it and the self-host code is in the repo; the frontend default is counted under P2 and P4.

Evidence (2)2 verified

Verified
The CLI fetches proving parameters from worm-privacy/trusted-setup GitHub release assets and proves locally; its server binary is the same prover/broadcaster that others can run for fees.
worm-privacy/worm-miner · Makefile
commit fd23cd8012 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Verified
The frontend's mint tool lists the WORM public prover and a local machine endpoint; its one-page send flow (src/app/wormhole/loading.tsx L169-L208) uses the default WORM prover for proving and relaying.
worm-privacy/worm-privacy.github.io · src/app/tools/burn-eth/mint-beth.tsx
commit 5c309e2548 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Neutral settlement, disclosed filtering

Is the settlement layer free of address or geographic filtering, and is any filtering at the edge disclosed and avoidable? C4

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The settlement contracts and the official clients contain no address or country filtering, and the direct path needs no provider service. Whether the hosted prover filters requests could not be seen. Judgment call: the substance fits 3, but 3 needs a distributed package or a trace, so 2.

Evidence (2)2 verified

Verified
mintCoin checks only the nullifier, the mint cap, a recent block hash and the proof; there is no address or country check.
worm-privacy/worm · src/BETH.sol
commit eab0f53b11 · checked 2026-10-09
Verified
A grep of the frontend source for country, geolocation, ipapi, sanction and chainalysis finds nothing.
worm-privacy/worm-privacy.github.io · src
commit 5c309e2548 · checked 2026-10-09

Token and chain freeze risks disclosed

Are the tokens and chains the rail depends on enumerated, with their issuers' freeze powers and sequencer assumptions stated to payees? C5

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The only asset is native ETH, which no issuer can freeze. Ethereum L1 has no sequencer. The payee receives BETH, an immutable ERC-20, and the hooks sell it for ETH or tokens through one named AMM router. The repos do not state the liquidity or price risk of BETH against ETH, which is the main inherited exposure. Scored 2: enumerated in code, assumptions not stated.

Evidence (1)1 verified

Verified
The BETHToETH hook is immutably wired to BETH and to the CypherETH swap router 0x20C5…b0Ab; the burned asset is native ETH only (proof-of-burn reads an account balance).
0xbA5A…52b6 on sourcify.dev
0xbA5A…52b6 explorer · Sourcify · block 26153606 · checked 2026-10-09

Open

Is the whole stack visible?

1 WeakPillar rating: weakest of 4
3 of 4 Partial or better

What would raise this pillar

Can be self-hosted reaching Partial: Reproducible with minor undocumented steps, recorded.

Contracts verified onchain

Does the deployed bytecode match public source, and can a third party rebuild it? O1

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Every settlement contract is an exact Sourcify match, and the deployed BETH source matches an untagged commit (eab0f53b) in the public repo. Etherscan was not checked: it blocks automated access. No rebuild was attempted, and the repo does not pin compiler settings. Judgment call: 2, not 3.

Evidence (2)2 verified

Verified
Sourcify returns exact_match for BETH, both verifiers, Staking and both hooks. BETH was compiled with solc 0.8.28 and deployed at block 24436025. Its source equals src/BETH.sol at worm@eab0f53b (2026-02-11); main has since changed the pool-fee logic.
0x5624…9Cf8 on sourcify.dev
0x5624…9Cf8 explorer · Sourcify · block 26153606 · checked 2026-10-09
Verified
foundry.toml pins no solc version or optimizer settings, so the build that produced the deployed bytecode is recorded only in Sourcify metadata.
worm-privacy/worm · foundry.toml
commit eab0f53b11 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Whole stack published

Are the SDK, frontend, backend or API, indexer, and deploy scripts all public? O2

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Contracts, circuits, client, prover/broadcaster server, setup and frontend are all public, and no indexer is needed. The hosted prover at prover-2.worm.cx could not be tied to a specific public build. Judgment call: 2 rather than 3 for that reason.

Evidence (1)1 verified

Verified
The org publishes contracts (worm), circuits (proof-of-burn), the CLI and prover server (worm-miner), the trusted-setup transcript and the frontend that GitHub Pages serves at worm.cx (CNAME worm.cx; worm.cx answers with server GitHub.com).
worm-privacy/worm-privacy.github.io · package.json
commit 5c309e2548 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Can be self-hosted

Can a stranger reach a working deployment from the README? O3

1 Weak

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Build and run instructions exist for the CLI and prover server. Reproduction not attempted, so capped at 1.

Evidence (1)1 verified

Verified
The README gives build steps for the CLI and server (Rust toolchain, apt packages, cargo build) and a Docker option; the Makefile downloads parameters.
worm-privacy/worm-miner · README.md
commit fd23cd8012 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Interfaces and data export

Are ABIs, event schemas, an API schema, and a payee data export in a non-proprietary format all in the repo? O4

2 Partial

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

ABIs and the optional prover API are in the repo. The API is a README list, not OpenAPI. There is no payee export; the CLI writes burn.json and note files for the user. Scored 2.

Evidence (1)1 verified

Verified
BETH, BETHToETH, Staking and WORM ABIs are committed; the prover server's HTTP endpoints (GET/POST /proof, GET /proof/{nullifier}, GET/POST /relay) are listed in the README.
worm-privacy/worm-miner · common/src/contracts/abis
commit fd23cd8012 · checked 2026-10-09

Free

Does the license actually let a third party fork, modify, and run it?

0 FailsPillar rating: weakest of 3
2 of 3 Partial or better

What would raise this pillar

Open-source licences reaching Weak: Source-available (BUSL, SSPL, ELv2, Commons Clause, custom) on a critical repo.

Open-source licences

Does every repository needed to run the product carry an OSI-approved license? F1

0 Fails

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The contracts and circuits repos carry MIT, though the deployed source files say UNLICENSED in their SPDX headers. The proof client a payer or payee needs to settle without the hosted prover, worm-miner, has no licence, and neither do the frontend and trusted-setup repos. Scored 0: a repository needed to run the product has no licence.

Evidence (2)2 verified

Verified
worm-miner, the only published proof-generation client, has no LICENSE file at this commit (top level holds .github, Cargo files, Dockerfile, Makefile, README.md, cli, common, server), and the GitHub licence API returns none. The frontend, trusted-setup and witness repos also have none.
worm-privacy/worm-miner · README.md
commit fd23cd8012 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Verified
The contracts repo LICENSE is MIT, but BETH.sol, Staking.sol and the hooks carry SPDX UNLICENSED headers; the verifiers are GPL-3.0; proof-of-burn (circuits) is MIT.
worm-privacy/worm · LICENSE
commit eab0f53b11 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Protection against relicensing

Can the provider unilaterally relicense future versions, and has it committed not to? F2

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

No CLA and no relicensing event; no written licence-stability commitment.

Evidence (1)1 verified

Verified
The LICENSE file has one commit (9e21f5f7, 2025-06-06); the repo has no CONTRIBUTING or CLA file.
worm-privacy/worm · LICENSE
commit eab0f53b11 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

No proprietary dependencies

Does a production deployment need a proprietary plugin or hosted-only service? F3

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

No proprietary plugin or hosted-only service is needed. The hosted prover is optional. Judgment call: the code supports 3, but with no O3 reproduction we take 2.

Evidence (1)1 verified

Verified
The proving parameters and circuit data come from public GitHub release assets; the CLI needs only an Ethereum RPC.
worm-privacy/worm-miner · Makefile
commit fd23cd8012 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Privacy

What can an observer learn, and did the user knowingly choose it?

0 FailsPillar rating: weakest of 5
2 of 5 Partial or better

What would raise this pillar

Endpoints can be changed reaching Weak: Documented workaround.

Tracking and analytics

Do the SDK, widget, or frontend ship analytics, telemetry, error reporting, or fingerprinting? P1

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Neither the frontend nor the Rust CLI ships an analytics or error-reporting SDK. The wallet-connector libraries may send their own connection telemetry; we did not assess that, and we ran no trace. Judgment call: absence shown only in code is capped at 2.

Evidence (1)1 verified

Verified
The frontend dependencies include no analytics, telemetry, error-reporting or fingerprinting package; wallet connectors (RainbowKit, WalletConnect, @metamask/sdk, @base-org/account) are present.
worm-privacy/worm-privacy.github.io · package.json
commit 5c309e2548 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Data collected beyond payment

Does the flow collect anything beyond addresses, amounts, token, and chain? P2

1 Weak

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The protocol needs nothing beyond the burn and mint data, and the CLI sends nothing elsewhere. The official one-page send flow, however, hands the WORM-run prover the burn key and receiver, which link the payer's burn to the payee. The prover cannot redirect funds, but it learns the payment. The code shows this, but no policy or UI text discloses it. Judgment call: anchor 2 needs the extra data to be clearly optional, and in this flow it is not. Anchor 0 means undisclosed collection, but this is visible in public code. We take 1, the lower of the two remaining anchors.

Evidence (1)1 verified

Verified
The one-page send flow posts the burn key, receiver address, fees and the burn address's account proof to DEFAULT_ENDPOINT (https://prover-2.worm.cx), with no option to change it in this flow.
worm-privacy/worm-privacy.github.io · src/app/wormhole/loading.tsx
commit 5c309e2548 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Payments linkable onchain

What do calldata and events reveal about who paid whom for what? P3

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The chain shows a payer sending ETH to what looks like an ordinary address, and later a mint to the payee. The proof hides which burn funded which mint. Both amounts are plaintext and arbitrary, so the burned amount and the revealed amount, minus fees, can be matched. Partial reveals through spendCoin weaken this. Judgment call: 2, minimal linkage, because amounts are revealed. The size of the anonymity set and any timing correlation are behavioural, so we leave them out of the score.

Evidence (2)2 verified

Verified
mintCoin calldata carries the block number, nullifier, remaining-coin commitment, fees, prover, revealedAmount and revealedAmountReceiver in plaintext. The burn itself is a plain ETH transfer to an address derived from a secret burn key.
worm-privacy/worm · src/BETH.sol
commit eab0f53b11 · checked 2026-10-09
Verified
MINT_CAP is 10 ETH per burn; amounts are arbitrary up to the cap.
0x5624…9Cf8 on sourcify.dev
0x5624…9Cf8 explorer · Sourcify · block 26153606 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Third parties in the payment flow

Which third parties see a request during a payment, and can they be swapped out? P4

1 Weak

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Third parties see the payment in both official clients. The frontend sends the burn address's proof request to a fixed list of public RPCs, and its send flow sends the burn key to the WORM prover. The CLI uses dRPC. All of these are named in public code, but none can be swapped by configuration. Judgment call: anchor 2 needs them to be swappable by config, which they are not; 1.

Evidence (2)2 verified

Verified
The frontend hardcodes twelve public mainnet RPCs (dRPC, merkle.io, LlamaRPC, NodeReal and GetBlock with keys, publicnode, MEV Blocker, Flashbots and others); eth_getProof for the burn address goes through them.
worm-privacy/worm-privacy.github.io · src/components/tools/rainbowkit-root.tsx
commit 5c309e2548 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Verified
The CLI hardcodes https://eth.drpc.org for mainnet, with no flag to override it.
worm-privacy/worm-miner · common/src/contracts/network.rs
commit fd23cd8012 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Endpoints can be changed

Can RPC and indexer URLs be changed, and is the indexer code public? P5

0 Fails

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Both official clients hardcode their RPC endpoints: the CLI uses dRPC, and the frontend uses a fixed list. No indexer is involved. Scored 0: hardcoded.

Evidence (1)1 verified

Verified
Network::url() returns a fixed URL per network (mainnet https://eth.drpc.org).
worm-privacy/worm-miner · common/src/contracts/network.rs
commit fd23cd8012 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Security

Who can cause loss, lock users in, or change the rules?

1 WeakPillar rating: weakest of 6
5 of 6 Partial or better

What would raise this pillar

Audits and bug bounty reaching Partial: Audit pinned to a commit, resolutions not individually linked.

Who holds funds in transit

Who holds funds between payer and payee, and can the provider redirect them? S1

3 Strong

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Between burn and mint, no one holds the value: the ETH is gone, and the right to mint is fixed to the payee by the burn-address commitment. A prover or broadcaster can only collect the fees the payer set. Whoever holds the burn key decides when to mint, but cannot change the recipient. The payee ends up with BETH, not ETH (see C2 and C5).

Evidence (2)2 verified

Verified
The burn address commits to the receiver, fees and hook; mintCoin mints only to those parties, and spendCoin mints remaining value only to the recorded coinOwner. No function lets any role move or redirect value.
worm-privacy/worm · src/BETH.sol
commit eab0f53b11 · checked 2026-10-09
Verified
The verifiers are immutable constructor arguments; proofOfBurnVerifier() returns 0x7c15…434f.
0x5624…9Cf8 on sourcify.dev
0x5624…9Cf8 explorer · Sourcify · block 26153606 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Who can upgrade the code

Who can change the contract code, and with how much notice? S2

3 Strong

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

No one can change the code: every contract in the payment path is non-upgradeable with no admin. Later fixes on the main branch (configurable pool share) would need a new deployment, so they are not in force.

Evidence (1)1 verified

Verified
The EIP-1967 implementation slot is zero on BETH, both verifiers, Staking and BETHToETH; none has an upgrade function or owner.
0x5624…9Cf8 on sourcify.dev
0x5624…9Cf8 explorer · Sourcify · block 26153606 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Token approval scope

How large an allowance does the SDK ask users to grant, and for how long? S3

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The default ETH payment path needs no approval. The ERC-20 path uses Permit2 with a bounded, expiring permit to the router, on top of the standard unlimited approval to Permit2. In mintCoin, BETH approves the hook for the exact hook allowance and resets it to zero. Judgment call: the substance is close to 3, but 3 needs a distributed package or trace, so 2.

Evidence (1)1 verified

Verified
Burning ETH needs no approval. For the ERC-20 path the frontend approves maxUint256 to Permit2 once (permit2.ts L17-L24), then signs a PermitSingle for about 110% of the input with a 30-minute expiry to the Universal Router.
worm-privacy/worm-privacy.github.io · src/lib/core/contracts/uniswap/burn-any-erc20.ts
commit 5c309e2548 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Funds safe if provider disappears Derived

If the provider disappears tomorrow, do payees keep their funds and the ability to keep settling? S4

2 Partial

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Derived from S1=3, C2=3, C3=3 and O3=1. No one can redirect funds (S1). A payee or payer holding the burn key can mint with the public CLI and proving parameters (C2). No hosted service is required (C3). A public frontend build exists, but we did not reproduce it (O3=1). Judgment call: 2, not 3. Two caveats: the CLI's hardcoded dRPC endpoint would need a code edit if dRPC disappeared, and BETH's value depends on market liquidity.

Evidence (1)1 verified

Verified
BETH is immutable with no admin (C1, S2), and mintCoin is callable by anyone with a proof (C2).
0x5624…9Cf8 on sourcify.dev
0x5624…9Cf8 explorer · Sourcify · block 26153606 · checked 2026-10-09

Secrets and webhook handling

Are secrets kept out of client bundles and are webhooks signed and verified? S5

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The bundled keys grant only RPC quota. The user's secret, the burn key, is created and backed up client-side, but the one-page send flow sends it to the WORM prover (P2). That exposes the payment link, not the funds, because the recipient is fixed. Judgment call: 2 (minor issues).

Evidence (1)1 verified

Verified
The frontend source embeds NodeReal and GetBlock RPC keys in URLs and a WalletConnect project ID; there are no merchant API keys or webhooks. The burn key is generated client-side and saved to a local JSON backup (wormhole/rest.tsx L142).
worm-privacy/worm-privacy.github.io · src/components/tools/rainbowkit-root.tsx
commit 5c309e2548 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Audits and bug bounty

Has the code been audited at a pinned commit, were findings fixed traceably, and is there a live bounty? S6

1 Weak

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Two audit reports are linked. The yAudit report predates the February 2026 BETH deployment and is tagged as a circuit review. We could not extract an audited commit from either report, so we cannot tie them to the deployed commit eab0f53b. We found no bug bounty and no SECURITY file. Scored 1: audit reports only.

Evidence (2)1 verified · 1 documented

Verified
The contracts README says BETH was audited by Hashlock (hashlock.com/audits/worm) and yAudit (reports.yaudit.dev/2025-11-Worm).
worm-privacy/worm · README.md
commit b34b507d4d · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Documented
The yAudit page (dated 2025-11-15, tagged zk and circom) embeds the PDF 2025-11-Worm-proofofburn.pdf.
reports.yaudit.dev/2025-11-Worm
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Security audits 2

Published audits and similar reviews of this provider's code, newest first. Context for the Audits and bug bounty rating, which scores them; this list does not change any rating, and an audit of older code says little about what is deployed now.

Date	Auditor	Type	Scope	Covers deployed code	Findings
2025-11-24	yAudit	Audit	Proof-of-burn and spend Circom circuits (ZK circuit security assessment) at `a39690248e` Reviewed commits 0e523748 and a3969024. The deployed verifier contracts changed after the November 2025 audits, and we did not tie them to a circuit commit.	Unknown	2 high, 3 medium, 3 low, 8 informational; one high (coin-lineage privacy leak) deferred
2025-11	Hashlock	Audit	BETH.sol (proof-of-burn mint and spend), WORM.sol and Staking.sol at `0134fb6ca0` Fix review at ca123363. The deployed commit eab0f53b is 36 commits later and changes BETH.sol, Staking.sol, WORM.sol and both verifier contracts.	Partly	2 high, 4 low, 1 QA; both highs and two lows resolved, the rest acknowledged

Compiled from: The READMEs and file trees of github.com/worm-privacy/worm, proof-of-burn and worm-miner (no audits/ folder), the Hashlock and yAudit pages linked from the contracts README, and yAudit's report index. Audited commits were compared with the deployed commit eab0f53b cited in this file. Checked 2026-10-13. Only published reports are listed; private audits a provider mentions without a report are not.

Operational and procurement

Facts an institution's procurement, finance and security functions ask for. Separate from the CROPS ratings and never scored.

Group A: operational facts. Group B: 45 due-diligence controls derived from a UN agency's vendor requirements: 10 evidenced, 0 attested, 6 absent, 27 not applicable, 2 unknown. "Not applicable" means there is no operator to hold the control: it falls to whoever deploys the rail. How to read this.

Group A: operational facts

Fees

Evidenced

Component	Paid by	Amount	Basis
provider	payee	0.5% pool fee on every mint and spend, minted to the Staking reward pool	BETH constant POOL_SHARE_INV = 200, immutable (no owner, no proxy); deducted from the revealed amount, so the payee receives less.
provider	payee	Prover fee and broadcaster fee chosen by the payer at burn time; 0 when the payee proves and submits itself	Bound into the burn-address commitment and paid from the revealed amount; the CLI defaults the prover fee to 0. Fees charged by the hosted prover-2.worm.cx are not published.
network	both	Ethereum gas: the burn is a plain ETH transfer; sample mintCoin 393,690 gas at 0.134 gwei (0.0000527 ETH)	The payer pays the burn transfer; whoever submits mintCoin (payee or broadcaster) pays its gas. Sample tx 0x2d9afb3d…c433 (2026-10-08).
fx	payee	BETH to ETH conversion at the CypherETH pool price through the optional BETHToETH hook; no fixed rate	The payee receives BETH; its ETH value depends on AMM liquidity. Pool fee and slippage not recorded.

Between deployment (2026-02-11) and the reward-pool initialisation (2026-02-23) the pool fee was 0, because the contract skips it while no pool is set.

Verified
mintCoin computes poolFee = revealedAmount / POOL_SHARE_INV (L187; constant 200 at L14) when a reward pool is set, requires proverFee + broadcasterFee to fit in the rest (L201), and mints the fees to the prover and msg.sender and the pool fee to the reward pool (L232-L239). spendCoin applies the same 0.5% (L270).
worm-privacy/worm · src/BETH.sol
commit eab0f53b11 · checked 2026-10-09
Verified
CLI burn takes --broadcaster-fee and --prover-fee; the prover fee defaults to 0 for self-proving.
worm-privacy/worm-miner · README.md
commit fd23cd8012 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Verified
mintCoin (selector 0x64a27e3c) in block 26146294, 2026-10-08 07:50:11 UTC, revealed 0.12 BETH, of which 0.0006 BETH (0.5%) was minted for the reward pool; the transaction used 393,690 gas at 0.134 gwei.
0x5624…9Cf8 on eth.blockscout.com
0x5624…9Cf8 explorer · Sourcify · block 26146294 · checked 2026-10-09

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Custody model

Evidenced

Self-custody

Agrees with S1 (score 3). Between burn and mint no one holds the value; the right to mint is fixed to the payee by the burn-address commitment, and no role can move or redirect BETH. The holder of the burn key decides when to mint.

Evidence shared with CROPS: S1 item 1, S1 item 2

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Licences and registrations

Absent

No operating entity is disclosed, so no register could be searched; no licence is claimed anywhere WORM publishes. The team runs the optional hosted prover and broadcaster at prover-2.worm.cx.

Verified
The worm-privacy GitHub organisation names no company; worm.cx has no terms page (worm.cx/terms returns 404) and the frontend source contains no terms or licence text.
api.github.com/orgs/worm-privacy
checked 2026-10-09

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Cash-out options

N/A: falls to the institution

The payee receives BETH (or ETH through the optional swap hook) at its own Ethereum address; converting to local currency is outside the protocol.

Evidence shared with CROPS: C2 item 1

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

First deployment

Evidenced

2026-02-11 (block 24436025): BETH 0x5624…9Cf8 on Ethereum, tx 0x681f4deb…8516 from 0x8DC7…C0Bb.

Verified
Sourcify creation data (exact match) gives tx 0x681f4debcc8ceb6c905e7f831cbcf48e79a6d09e6df93d1caa57ba68be6a8516 in block 24436025, deployer 0x8DC77b145d7009752D6947B3CF6D983caFA1C0Bb; the block is dated 2026-02-11 20:49:47 UTC.
0x5624…9Cf8 on sourcify.dev
0x5624…9Cf8 explorer · Sourcify · block 24436025 · checked 2026-10-09

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Operating entity

Absent

Searched: the GitHub org profile and repositories (READMEs, frontend source), worm.cx (no terms, imprint or company name; /terms is 404). No legal entity is named.

Verified
The organisation profile has no company field; it links only worm.cx.
api.github.com/orgs/worm-privacy
checked 2026-10-09

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Security incidents

Evidenced

Absence of a found incident is not evidence that none occurred.

No incident or post-mortem found in the repositories or on worm.cx.

Verified
No published security advisories for worm-privacy/worm (worm-privacy/worm-miner also has none).
api.github.com/repos/worm-privacy/worm/security-advisories
checked 2026-10-09

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Product changes affecting users

Evidenced

2026-02-11: BETH deployed with immutable verifiers and a one-time initializer; no reward pool set, so no pool fee. source
2026-02-23: initRewardPool sets the Staking contract 0x03d4…60B7 as reward pool and clears the initializer (tx 0x3c0d39e1…f7dc); the 0.5% pool fee applies from then on. source

The contracts are immutable, so these are the only changes possible. The worm repository's main branch has later, undeployed changes (configurable pool share); they would need a new deployment.

Verified
rewardPool() changes from zero to 0x03d4…60B7 at block 24518725 (bisected with historical eth_call), where tx 0x3c0d39e1…f7dc from the deployer calls BETH with selector 0x1891708b; initializer() reads zero afterwards. Staking itself was deployed at block 24500500 (Sourcify).
0x5624…9Cf8 on sourcify.dev
0x5624…9Cf8 explorer · Sourcify · block 24518725 · checked 2026-10-09

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Volume transacted (verified only)

Not observable

The payer's leg is a plain ETH transfer to an unlinkable burn address (no log). The payee's leg, mintCoin, emits only ERC-20 Transfer logs from the zero address; the sender is an indexed topic, which the volume spec cannot filter, so mints cannot be separated from ordinary BETH transfers and AMM swaps.

A from-topic filter in scripts/volumes.mjs would make mints countable (Transfer from 0x0 on BETH, amount in word 0, including the fee mints to prover, broadcaster and pool). 32 mint transactions in the last 200,000 blocks to 2026-10-09 (read for the gas sample).

UnreviewedAssessed by AI research agent (operational), 2026-10-09

Group B: institutional due diligence

Control	State	What was found
Assurance and certifications
B1.1 ISO 27001, developer organisation Is the organisation that develops the product ISO 27001 certified, and does the certificate name that entity?	N/A: falls to the institution implied from the component list
B1.2 ISO 27001, hosting and support organisation Is the organisation that hosts and supports the service ISO 27001 certified in its own name, with a scope covering the service?	N/A: falls to the institution implied from the component list
B1.3 SOC 2 Type II or ISAE 3000/3402 reports Does the provider undergo periodic SOC 2 Type II or ISAE 3402 Type II assessments and make reports available?	N/A: falls to the institution implied from the component list
B1.4 Independent source-code security review before go-live Was the application reviewed by an independent party before launch, and is the report linked?	Evidenced	The README links audits by Hashlock and yAudit (circuits, 2025-11); neither is tied to the deployed commit eab0f53b. No review of the hosted prover is listed. CROPS S6 · CROPS S6
B1.5 Penetration testing Is the service penetration-tested before go-live and at least every three years, with results available?	N/A: falls to the institution implied from the component list
B1.6 Vulnerability scanning cadence Are the platform and the application scanned for vulnerabilities at least every six months?	N/A: falls to the institution implied from the component list
Vulnerability and patch management
B2.1 Security contact and disclosure policy Is there a published way to report a vulnerability (SECURITY.md, security.txt, or a disclosure page)?	Absent	none of 5 repo(s): worm-privacy/worm ✗ no security policy file; worm-privacy/proof-of-burn ✗ no security policy file; worm-privacy/worm-miner ✗ no security policy file; worm-privacy/worm-privacy.github.io ✗ no security policy file; worm-privacy/trusted-setup ✗ no security policy file source 1 · source 2 · source 3 · source 4 · source 5
B2.2 Patch service levels Does the provider commit to patch timelines for known vulnerabilities (the partner expects 30 days critical, 40 high, 90 medium)?	Unknown	No SECURITY file, disclosure page or patch timeline found.
B2.3 Dependency and vulnerability scanning in CI Do the public repositories run dependency or code scanning automatically?	Absent	none of 5 repo(s): worm-privacy/worm ✗ no scanning config or workflow step found; worm-privacy/proof-of-burn ✗ no scanning config or workflow step found; worm-privacy/worm-miner ✗ no scanning config or workflow step found; worm-privacy/worm-privacy.github.io ✗ no scanning config or workflow step found; worm-privacy/trusted-setup ✗ no scanning config or workflow step found source 1 · source 2 · source 3 · source 4 · source 5
Incident reporting and continuity
B3.1 Incident reporting commitment Does the provider commit to notify customers of security or data incidents within a stated time (the partner expects 24 hours)?	N/A: falls to the institution implied from the component list
B3.2 Backups and restore testing Are customer records backed up daily and restores tested on a schedule?	N/A: no such service implied from the component list
B3.3 Recovery plan Is there an approved and tested recovery plan for the service?	N/A: no such service implied from the component list
B3.4 Status page and post-mortems Does the provider publish service status and post-mortems for incidents?	Unknown	No status page for the hosted prover and no post-mortems found.
Identity and access (operator side)
B4.1 MFA for end users Can or must end users protect accounts with multi-factor authentication?	N/A: no such service implied from the component list
B4.2 MFA and separate accounts for privileged access Is privileged access protected by MFA and kept on separate accounts?	N/A: falls to the institution implied from the component list
B4.3 Periodic access reviews Are user access rights reviewed at least annually and privileged accounts at least six-monthly?	N/A: falls to the institution implied from the component list
B4.4 Segregation of duties and joiner-mover-leaver controls Is there a documented segregation-of-duties model and a joiner-mover-leaver process?	N/A: falls to the institution implied from the component list
B4.5 Session timeout Are idle interactive sessions terminated after a defined period (the partner expects 60 minutes)?	N/A: no such service implied from the component list
API and integration
B5.1 API authentication, browser to server Which standard (OAuth 2.0, OpenID Connect, SAML, JWT) protects browser-to-server API calls?	Evidenced	The hosted prover and relay API (prover-2.worm.cx) takes unauthenticated JSON POSTs; the frontend sends the burn key, receiver, fees and account proof with only a Content-Type header. source 1 CROPS P2
B5.2 API authentication, server to server Are server-to-server calls authenticated with keys or PKI certificates, and are keys scoped and rotatable?	N/A: falls to the institution implied from the component list
B5.3 Token expiry Do API tokens expire, and within what period (the partner caps it at 120 minutes for public data, 30 otherwise)?	N/A: falls to the institution implied from the component list
B5.4 Export controls If an API exports data, does it limit volumes and log exports?	N/A: falls to the institution implied from the component list
Data protection and privacy governance
B6.1 Data classification and encryption Does the provider state a data classification and enforce encryption at rest and TLS 1.2 or better in transit?	N/A: falls to the institution implied from the component list
B6.2 Production data kept out of test environments Does the provider state that production or real personal data is not used in development and testing?	N/A: falls to the institution implied from the component list
B6.3 Data retention and deletion on termination What is retained, for how long, and is customer data removed on termination?	N/A: falls to the institution implied from the component list
B6.4 Data protection impact assessment and roles For systems holding personal data, has a DPIA been completed and are controller and processor defined?	N/A: falls to the institution implied from the component list
B6.5 Data processing or sharing agreement available Can a customer obtain a data processing agreement or equivalent?	N/A: falls to the institution implied from the component list
Logging and monitoring
B7.1 Audit logging Are account changes, logins and activity on important records logged and retained?	N/A: falls to the institution implied from the component list
B7.2 Central monitoring and endpoint detection Are logs sent to a managed SIEM and is endpoint detection running on all platforms?	N/A: falls to the institution implied from the component list
Hosting and network
B8.1 Hardened hosting Are hosts hardened to a recognised benchmark, with only essential ports open, IDS/IPS, a WAF for internet-facing applications and tenant isolation?	N/A: falls to the institution implied from the component list
B8.2 Deployment configuration and infrastructure as code Does the repository ship reproducible deployment configuration (containers, IaC, Helm) that a self-hoster can harden?	Evidenced	some of 5 repo(s): worm-privacy/worm ✗ no deployment configuration; worm-privacy/proof-of-burn ✓ deployment configuration: Dockerfile; worm-privacy/worm-miner ✓ deployment configuration: Dockerfile; worm-privacy/worm-privacy.github.io ✓ deployment configuration: Dockerfile; worm-privacy/trusted-setup ✗ no deployment configuration source 1 · source 2 · source 3 · source 4 · source 5
Engineering practice in public repositories
B9.1 Default branch protected Does the default branch require reviews and passing checks, with no direct pushes?	Absent	none of 5 repo(s): worm-privacy/worm ✗ no branch rules visible (classic branch protection is not readable without push access); worm-privacy/proof-of-burn ✗ no branch rules visible (classic branch protection is not readable without push access); worm-privacy/worm-miner ✗ no branch rules visible (classic branch protection is not readable without push access); worm-privacy/worm-privacy.github.io ✗ no branch rules visible (classic branch protection is not readable without push access); worm-privacy/trusted-setup ✗ no branch rules visible (classic branch protection is not readable without push access) source 1 · source 2 · source 3 · source 4 · source 5
B9.2 CI runs on pull requests Does every pull request trigger automated checks?	Evidenced	some of 5 repo(s): worm-privacy/worm ✓ 1 workflow file(s); worm-privacy/proof-of-burn ✓ 2 workflow file(s); worm-privacy/worm-miner ✗ 1 workflow file(s); worm-privacy/worm-privacy.github.io ✗ 1 workflow file(s); worm-privacy/trusted-setup ✗ 5 workflow file(s) source 1 · source 2 · source 3 · source 4 · source 5
B9.3 Tests run in CI Do the CI workflows run the test suite?	Evidenced	some of 5 repo(s): worm-privacy/worm ✓ test command in a workflow; worm-privacy/proof-of-burn ✗ test command in a workflow; worm-privacy/worm-miner ✗ test command in a workflow; worm-privacy/worm-privacy.github.io ✗ test command in a workflow; worm-privacy/trusted-setup ✗ test command in a workflow source 1 · source 2 · source 3 · source 4 · source 5
B9.4 Coverage reported Is test coverage measured and reported (the partner expects 85%)?	Absent	none of 5 repo(s): worm-privacy/worm ✗ coverage tooling referenced; worm-privacy/proof-of-burn ✗ coverage tooling referenced; worm-privacy/worm-miner ✗ coverage tooling referenced; worm-privacy/worm-privacy.github.io ✗ coverage tooling referenced; worm-privacy/trusted-setup ✗ coverage tooling referenced source 1 · source 2 · source 3 · source 4 · source 5
B9.5 Versioned releases Are releases tagged with immutable semantic versions?	Absent	none of 5 repo(s): worm-privacy/worm ✗ no tags; worm-privacy/proof-of-burn ✗ no tags; worm-privacy/worm-miner ✗ no tags; worm-privacy/worm-privacy.github.io ✗ no tags; worm-privacy/trusted-setup ✗ latest tags: final, circuit_data, 0082_worm-privacy source 1 · source 2 · source 3 · source 4 · source 5
B9.6 Signed tags or commits Are release tags or recent commits cryptographically signed?	Evidenced	some of 5 repo(s): worm-privacy/worm ✗ 2 of 10 recent commits signed; worm-privacy/proof-of-burn ✗ 2 of 10 recent commits signed; worm-privacy/worm-miner ✗ 1 of 10 recent commits signed; worm-privacy/worm-privacy.github.io ✓ 5 of 10 recent commits signed; worm-privacy/trusted-setup ✓ 5 of 10 recent commits signed source 1 · source 2 · source 3 · source 4 · source 5
B9.7 Changelog Is a changelog maintained with the code?	Evidenced	some of 5 repo(s): worm-privacy/worm ✗ no changelog or release notes; worm-privacy/proof-of-burn ✗ no changelog or release notes; worm-privacy/worm-miner ✗ no changelog or release notes; worm-privacy/worm-privacy.github.io ✗ no changelog or release notes; worm-privacy/trusted-setup ✓ 4 release(s) with notes source 1 · source 2 · source 3 · source 4 · source 5
B9.8 Contribution and branching model documented Does the README or contribution guide state how changes are proposed, reviewed and released?	Evidenced	some of 5 repo(s): worm-privacy/worm ✗ none found; worm-privacy/proof-of-burn ✓ contribution section in README; worm-privacy/worm-miner ✗ none found; worm-privacy/worm-privacy.github.io ✗ none found; worm-privacy/trusted-setup ✓ contribution section in README source 1 · source 2 · source 3 · source 4 · source 5
Architecture documentation
B10.1 Architecture documentation Is there a public architecture document covering logical, infrastructure and integration architecture and the components used?	Evidenced	Logical view in the circuit and contract READMEs (burn address, nullifier, coin and commitment design; deployment addresses); integration view in the worm-miner README (CLI and server). No infrastructure view of the hosted prover. source 1 CROPS O3
Commercial and financial
B11.1 Contracting entity Which legal entity would an institution contract with, and in which jurisdiction?	N/A: falls to the institution implied from the component list
B11.2 Funding of ongoing operation How is ongoing operation and maintenance funded (revenue, foundation, grants, fee switch), per a primary source?	Evidenced	The protocol's only fee (0.5% of each mint and spend) goes to the Staking contract for WORM stakers, not to a team address; no other funding source for the team or the hosted prover is published. source 1 CROPS C1
B11.3 Termination terms What happens to customer funds and data on termination by either side?	N/A: falls to the institution implied from the component list
AI components
B12.1 AI in the payment path Does an AI system take part in payment processing or compliance decisions (for example automated transaction screening)?	Absent	No automated screening or AI in the payment path. mintCoin checks only nullifier, mint cap, block hash and proof, and the frontend has no country, sanctions or analytics code. The hosted prover's behaviour cannot be seen. CROPS C4 · CROPS C4
B12.2 AI controls documented If AI is used, are monitoring, validation, override, decommissioning and bias evaluation documented?	N/A: no such service	No AI component in the payment path (B12.1 absent).

Scope of assessment

Components in the payment path

Component	Role	Public	Licence	Operator	Required
BETH contract (proof-of-burn mint and spend)	contracts	Yes	MIT	none (no owner, no proxy; initializer cleared)	Yes
ProofOfBurn and Spend Groth16 verifiers	contracts	Yes	GPL-3.0	none	Yes
Staking reward pool (receives the 0.5% pool fee in mintCoin)	contracts	Yes	MIT	none (no owner)	Yes
Proof-of-burn and spend circuits	other	Yes	MIT	none	Yes
Trusted-setup parameters (GitHub release assets)	other	Yes	none	worm-privacy GitHub org	Yes
worm-miner CLI (local burn, proof and mint)	sdk	Yes	none	user	Yes
Ethereum mainnet and an RPC that serves eth_getProof	ledger	Yes	LGPL-3.0	Ethereum validators; RPC (hardcoded dRPC in the CLI)	Yes
Hosted prover and broadcaster (prover-2.worm.cx, worm-miner server)	relayer	No	proprietary	WORM team	No
worm.cx frontend (GitHub Pages build of worm-privacy.github.io)	frontend	Yes	none	WORM team	No
BETHToETH and BETHToERC20 hooks with CypherETH pool liquidity	contracts	Yes	MIT	none (immutable hooks); liquidity from third parties	No
Public RPCs, WalletConnect and Uniswap Permit2 used by the frontend	other	No	proprietary	various (dRPC, NodeReal, GetBlock, others; WalletConnect; Uniswap)	No

Repositories

Repository	Role	License
worm-privacy/worm	contracts	MIT
worm-privacy/proof-of-burn	contracts	MIT
worm-privacy/worm-miner	sdk	none
worm-privacy/worm-privacy.github.io	frontend	none
worm-privacy/trusted-setup	deploy	none

Contracts

Role	Address	Source verified
BETH (mintCoin, spendCoin)	`0x5624…9Cf8` explorer · Sourcify	sourcify
ProofOfBurnVerifier (Groth16)	`0x7c15…434f` explorer · Sourcify	sourcify
SpendVerifier (Groth16)	`0x5745…02e6` explorer · Sourcify	sourcify
Staking (reward pool credited on every mint)	`0x03d4…60B7` explorer · Sourcify	sourcify
BETHToETH swap hook (optional)	`0xbA5A…52b6` explorer · Sourcify	sourcify

Assessor notes

Unit: BETH on Ethereum mainnet and the contracts it calls. Reads at block 26153606 via ethereum-rpc.publicnode.com. Deployed BETH source = worm@eab0f53b (2026-02-11); main (b34b507d) has later, undeployed changes. The payee receives BETH, an ERC-20 claim on burned ETH whose ETH value depends on market liquidity; the official send flow converts it to ETH through the BETHToETH hook. WORM (the mining token), distributors, ICO and Staking epochs are out of scope except where mintCoin pays the pool fee. No transactions, traces or self-host attempts.