your keys. your funds. our code, in the open.

Because the service is non-custodial, you never depend on us to get your money back. You can leave an open cluster, clear a closed one, claim after clearing and revoke a mandate by calling the contracts directly, for example from the “Write contract” tab on Blockscout, even if this website is offline.

The contracts have had an internal review, carried out by our own engineers and tooling (with AI assistance): a line-by-line read of every contract, proofs of concept as Foundry tests (offline and on a fork of Robinhood Chain mainnet against the deployed bytecode), fuzzing of the safety properties and a Slither pass. No independent third-party audit has been completed. We will publish the auditor, scope and full report here when one is.

The review found a critical issue and three high-severity issues in the first Pons-curve contracts (v1). They had no activity and held no funds, so they were retired rather than patched, and the fixes ship in the V2 contracts listed above. The main findings:

The review also covers lower-severity and informational items (chain-time deadlines, rounding dust, gas cost of stock clears, ERC-20 edge cases). Until an independent audit, treat the contracts as experimental and only commit amounts you can afford to lose.

No admin powers

• BlockClearingV2 and MandateVaultV2 have no owner, no admin role, no pause switch and no upgrade proxy.
• The venue (the VenueRouter), the fee recipient and the price guard (300 bps) are set in the constructor and are immutable. The fee is a constant 10 bps; fees accrue in the contract and are sent to the fee recipient (the deployer’s address) when anyone calls withdrawFees.
• The VenueRouter has no admin: a market is a stock if its code is the canonical Robinhood Stock Token proxy, a Pons market if the Pons factory records it, and anything else is rejected. Nobody can re-point a market.
• The StockV3Adapter’s ownership has been renounced, so its table of stock routes (which pool each stock trades in) is frozen.
• Nobody, including us, can move escrowed ETH, change a deployed contract’s rules or freeze it. The flip side: a bug cannot be patched in place and funds cannot be rescued by an administrator. Fixes ship as new deployments, and the legacy deployment stays readable.

Known limitations

• Ceiling plus a price guard. Capacity comes from the venue’s price in the clearing transaction. On top, V2 fills only within the ceiling plus a 3% guard of the best quote seen while the cluster was open. A fill outside that reverts, so the clear can be retried; 15 minutes after close anyone can clear it as a full refund. The 3% slack is still room a sandwich could use.
• Stock token issuer powers. Robinhood Stock Tokens are upgradeable by their issuer, which can pause trading, block wallets (transfers to and from them fail) and burn tokens, including tokens the clearing contract holds between a clear and your claim. If your claim’s token transfer fails, your ETH refund is still paid and the tokens are held for you to retrieve later.
• Deadlines are chain time. Windows, the grace period and mandate expiry use the sequencer’s block timestamp, which can differ slightly from your clock.
• Clearing is permissionless but not automatic. After a window closes, escrow stays in the contract until someone calls clear. We run a crank; anyone else can too.
• Venue failure refunds everyone. If the venue can’t quote or can’t fill within the guard (for example a stock is paused or a Pons curve graduated), clearing is retryable until 15 minutes after close, then the cluster settles at zero and every wallet claims its full contribution back.
• Claims are pulled, or pushed by anyone. Each wallet calls claim, or anyone can call claimFor to send a wallet its own claim. Rounding dust of a few wei per wallet stays in the contract.
• Mandate executions are bounded. At most 64 mandates per execution, in strictly increasing id order. A mandate contributes nothing if it is revoked, expired, names a different originator, its ceiling is stricter than the execution’s, it is bound to another market, or spot is above its price cap. An unbound mandate without a price cap still trusts the originator’s judgment within its caps.
• Third-party code. The venues and the tokens they issue are not ours and may have their own admin powers, fees and risks.
• Local agent limits are not enforced onchain. Spend limits in the nofomo-mcp signer are software on your machine; mandates are the enforced limit.

The risk disclosure covers the wider risks in plain language.

If you find a vulnerability in the contracts, the website, the API or the MCP server, please tell us privately first at [to be completed: contact email]. If the issue could put funds at risk, say so in the subject line.

What to include

• the affected component (contract address, URL or endpoint) and version or commit if known;
• a description of the issue and its impact;
• step-by-step reproduction, ideally a proof of concept against a local fork, not mainnet;
• how you would like to be credited, if at all.

Our goals

• acknowledge your report within 3 business days;
• give an initial assessment within 7 days;
• keep you updated until it is resolved, and credit you publicly if you wish.

Safe harbour

We will not pursue or support legal action against you for good-faith research that follows these rules: you avoid privacy violations, data destruction and service disruption; you test only against your own accounts, wallets and local forks; you do not exploit an issue beyond what is needed to demonstrate it and never move other people’s funds; and you give us reasonable time to fix the issue before disclosing it publicly. Social engineering, phishing, physical attacks and denial-of-service testing are out of scope.

A formal bug bounty programme is being prepared. Until it launches, valid reports that follow the rules above will be credited and considered for a reward once the programme exists, at our discretion.