Security

Trust assumptions, what the contract cannot do, known limitations and how to report an issue.

Trust model

• No privileged roles. The contract has no owner, operator or upgrade admin. Nobody — including the deployer — can pause it, change fees (there are none), freeze a campaign or move funds without a valid claim signature.
• Immutable. There is no proxy. The bytecode at the address is final.
• No external calls except the BNB transfer to the claim recipient, which happens after all state updates.
• Minimal dependencies. OpenZeppelin EIP712 and ECDSA only.

Invariants

A stateful fuzzing handler (256 runs × 500 random donate / claim calls) enforces address(this).balance == Σ campaign.balance — the treasury always equals the sum of unclaimed balances. A property test additionally checks that a claim can never exceed the campaign balance for arbitrary donated / requested amounts.

Unit tests cover every revert path, pagination order, partial claims submitted by a third party, replay rejection, tampered recipient or amount, wrong key and overdraw, claiming from a closed campaign, rotation invalidating previously signed messages, a rejecting recipient reverting atomically, and the EIP-170 runtime size limit.

Known limitations

Amount correlation

Claimed emits the amount and campaign id. A unique amount claimed into a fresh wallet can be matched by an observer. Mitigation is behavioural: claim round, partial amounts.

Creator wallet is public

The campaign stores and exposes its creator. The design assumes the creator is willing to be publicly associated with the cause but not with the money. If even the association is sensitive, create from a wallet with no history.

Claim-code custody

The code is a bearer secret. Loss means the creator wallet must rotate; theft means the thief can claim until the creator rotates. There is no time-lock or second factor.

Gas linkage

The collector wallet must be funded. If it is funded from the creator wallet, the link is re-established off-protocol.

Shared treasury

Pooling all campaigns in one balance is what hides which campaign a claim came from, but it also means the contract holds everyone's unclaimed BNB. The invariant above is the guard; the small code surface is the audit strategy.

Audit status

The contract has been reviewed internally by the project team and is covered by unit and invariant tests. It has not been audited by an independent third party. Treat it as new code and size your exposure accordingly.

Reporting a vulnerability

Send a direct message to @AnonFund_Four with a description and, if possible, a proof of concept against a local fork. Please do not test against campaigns holding real funds. There is no formal bounty programme at this time.