Claim codes

A claim code is a private key wrapped in a human-readable string. This page documents the format, how a claim is signed and verified, and how to keep the code safe.

Format

anonfund-claim-<chainId>-<campaignId>-<0x + 64 hex chars>

anonfund-claim-56-12-0x4f3c…e1a9

`chainId`	56 for BNB Chain. The claim page refuses codes from a different chain.
`campaignId`	Sequential id of the campaign. Lets the page load the campaign without asking you which one.
key	A 32-byte secp256k1 private key, hex encoded. Its address is what the contract stores as `claimKey`.

Why a key and not a password

A hash pre-image scheme (reveal a secret, contract checks its hash) would expose the secret in the mempool, letting anyone front-run the claim and redirect the funds. A signature scheme has none of those problems: the secret never leaves the browser, the message binds the recipient and amount, and a nonce prevents replay. It also allows partial claims and key rotation.

Signing

The claim page builds and signs an EIP-712 typed message:

Domain
  name:              "AnonFund"
  version:           "1"
  chainId:           56
  verifyingContract: 0xEdF59883C7A4c67A368E465BFa4ED7a962546c09

Claim(uint256 campaignId, address recipient, uint256 amount, uint256 nonce)

nonce is read from nonces(campaignId) right before signing. The contract exposes the exact digest via claimDigest(campaignId, recipient, amount, nonce), so independent clients can never drift from what the chain verifies.

Verification

claim() recovers the signer with ECDSA.tryRecover. The call reverts with InvalidSignature unless the signer equals the stored claim key, with InsufficientBalance if the amount exceeds the campaign balance, and with InvalidRecipient for the zero address. On success the nonce is incremented and the BNB is sent with a low-level call; a rejecting recipient reverts the whole transaction (TransferFailed), so funds are never stuck or lost.

Partial claims

Any amount up to the balance can be claimed, and claims can be repeated. Each claim consumes one nonce. Spreading a large balance across several claims of round amounts to different wallets weakens amount-correlation attacks.

Rotation

The creator wallet can call rotateClaimKey. The new key becomes active and the nonce is bumped, which instantly invalidates any signature produced with the previous key — even one already broadcast but not yet mined. Use this if a code is lost, exposed, or was shared with a collaborator who should no longer have access.

Storage recommendations

Treat the code like a seed phrase. Whoever holds it can take the funds.
Store it offline or in an encrypted password manager. Do not keep it in chat logs, email or screenshots.
Do not store it in the same place as the creator wallet's seed; the two together fully de-anonymise the campaign.
If in doubt whether a copy leaked, rotate. It costs one transaction.

← Campaigns Donor privacy →