Security

1. In brief

2. Security by product

The Hood ships more than one product, and they do not share a security position. Stating one for the platform would flatter the surfaces that hold nothing and understate the one where money is actually at risk, so each answers for itself below — what has been reviewed, what the deployed code guarantees, and what is known to be wrong with it.

Nothing in this section says “secure”. Status is a fact about deployment, not a judgement about quality: live means deployed and holding value, built means the code exists and is tested but nothing is deployed, and not built means there is nothing to review yet.

3. Reporting a vulnerability

If you have found something, we want to hear it before anyone else does. Email security@thehood.markets. That mailbox is monitored on the commitments in section 3.5.

3.1 Read this first: a contract bug cannot be patched

The launchpad contracts are immutable, and audited by Claude Fable 5. There are no proxies and no upgrade path. A vulnerability in deployed contract code therefore cannot be fixed in place, ever. Only three responses exist:

• Pause new launches on the factory, so no further projects are created under the affected code. By construction this can never block a claim, a sell or a graduation already owed to someone — an unaffected user is never trapped by our response.
• Deploy a new factory and point this site at it. Projects created under the old one keep running under the old one, on chain, unchanged.
• Warn holders publicly, as loudly and as specifically as we can.

This changes what a report achieves, so it is stated up front rather than discovered during triage. The value of an early report is that people can be warned and can exit while a curve is still trading. Speed genuinely matters here in a way it does not on a normal web product.

3.2 In scope

• The website — thehood.markets and everything it serves.
• The API routes — /api/quote and /api/upload.
• The launchpad contracts on Robinhood Chain (chain 4663): the launch factory, the curve deployer, the bonding curves, the launch tokens, the graduation adapter and the liquidity locker. The factory this site currently reads is 0x72eD73A6c7218B1864AaF2d688355edA93422D30; every other contract in the system is reachable from it.

The findings we care most about, in order: anything that can move value that is not yours, anything that can remove or reduce locked liquidity, anything that can redirect or steal creator or holder fees, anything that lets a curve or pool be manipulated at another trader’s expense, and anything that lets a project be launched impersonating a contract or address it does not control.

3.3 Out of scope

• Robinhood Chain itself, its RPC endpoints and its block explorer — report those to their operators.
• Uniswap V4, its PoolManager and periphery — report those to Uniswap.
• IPFS gateways and pinning providers, and third-party wallet software.
• Volumetric denial of service, and any test that degrades the site for other people. Do not run one.
• Missing security headers, missing SPF/DMARC records, weak TLS ciphers, cookie flags and similar configuration observations with no demonstrated impact.
• Raw output from an automated scanner with no proof of concept, and reports whose entire content is a CVSS score.
• Social engineering of anyone, physical attacks, and phishing sites impersonating The Hood — those are worth telling us about, but they are abuse reports, not vulnerabilities.
• Economic outcomes that are how the system is designed to work: a token going to zero, a creator selling their own allocation, a curve never reaching its target, price impact on a large trade, ordinary MEV. See the risk notice.

3.4 How to report

Email security@thehood.markets with, as far as you can:

• the exact contract address or URL affected, and the chain it is on;
• steps to reproduce — a failing test, a script or a transaction hash beats a description;
• the impact: what an attacker gains, whose funds are at risk, and how much;
• any preconditions the attack needs;
• how you would like to be credited, or that you would rather not be.

We publish no PGP key, so do not assume the email is encrypted in transit beyond ordinary transport security. If a finding is severe enough that this matters, send a short message with no detail and ask for a channel — or reach us on X at @thehoodmarkets and we will come back to you. Do not post the detail publicly to get our attention.

3.5 What we commit to

• Acknowledgement within 3 business days — from a person, not an autoresponder.
• An assessment and a plan within 10 business days, stating plainly which of the three responses in section 3.1 we are taking, and why.
• Keeping you updated until it is resolved, and telling you when we disagree that something is a vulnerability rather than going quiet.
• Credit in the public disclosure if you want it.

There is no funded bug bounty. We would rather say so than imply a payment that does not exist. Rewards, if any, are discretionary and case by case. Report it because a broken launchpad hurts real people, not because a payout is promised.

3.6 Safe harbour

We will not pursue or support legal action against anyone who researches in good faith within the scope in section 3.2, and we will say so publicly if a third party misreads your work as an attack. That protection applies as long as you:

• access only your own accounts and data — never another user’s funds, keys or personal information;
• take only the minimum needed to prove the finding. Prove that value can be extracted; do not extract it. Any value taken must be returned in full.
• avoid degrading the service for other people, and stop the moment you have your proof of concept;
• give us a reasonable chance to respond before disclosing publicly — 90 days, or sooner once a fix or warning is out. If we go silent past the commitments in section 3.5, publish; that is on us.

If in doubt about whether something is in scope or whether a test crosses a line, ask first. We would much rather answer a question than argue about it afterwards.

4. The security audit

19 findings9 fixed10 open

Dated 15 August 2026, and performed by Claude Fable 5 across six surfaces — smart contracts, the prediction market, frontend, API, database and performance. Every Critical and High finding is fixed with executable exploits and regression tests: the five contract findings, the prediction market’s settlement and census findings (fixed before those contracts deployed on 15 August 2026), and the database migration drift. The remaining application findings (frontend, API, performance) are reported here and still open. The contracts were reviewed at commit 11d8d75 and the fixes landed in 32b5fec, so the reviewed commit still contains the vulnerable code and the later one does not.

Read the full report — the whole document as a page, or download the PDF.

4.1 Findings

4.2 What is still open

Four contract findings were accepted rather than fixed, because fixing them would cost more than they take. They are real, and you should know them before you trade:

• The anti-snipe cap can be defeated by splitting a buy across several wallets. The early-window cap is per wallet, and nothing on chain can tell one person with ten wallets from ten people.
• Owner test launches can obtain most of a supply cheaply under the development graduation target. This is a deployment-configuration risk, not a bug in the curve.
• Curves can be deployed without going through the factory. Only launches the factory registered are authentic — always check a token against the factory rather than trusting a link.
• Graduation is visible to MEV. The transaction that graduates a curve is public before it lands, and can be traded around.

The six open application findings in the table above — report retention, the unauthenticated ingest limits, the RPC-URL disclosure, the redaction label, and the two performance items — are queued for fixes rather than accepted. None of them can move funds.

4.3 What would change this

A review by an established firm. It is warranted before this platform holds meaningful value. The contracts are immutable, so a review that finds something serious means redeploying rather than patching — which is part of the risk you take.

The exploits and regression tests are in the public repository, so any reader can run them rather than taking the table above on trust.

5. Who holds which key

A contract with no admin key is safe from its author. Most of ours are that, and the rest are not — so this section says which keys exist, what each can reach, and what none of them can do. It is written because “the contracts are immutable” is a true sentence that answers a narrower question than the one people are asking.

5.1 Two multi-signature wallets, and the division between them is the point

Control is split between two separate multi-signature wallets at two separate addresses, and the split is by kind of decision rather than by convenience:

Neither can complete the path alone. Redirecting protocol revenue to an address of somebody’s choosing takes acts from both wallets — registering a source, arming it, whitelisting a destination and repointing the treasury are deliberately not all in one place. That is the property worth having, and it is why the two exist rather than one.

It is not a guarantee about people. Two wallets are two sets of signers, and this states what the contracts require rather than making a claim about who holds what.

5.2 Keeper keys do bounded jobs and cannot move your money

A handful of single-purpose operating keys exist because some things have to happen on a schedule: opening and closing a promotion window, collecting fees that have accrued, sampling a pool’s price, settling a market whose deadline has passed, posting a price. They are separate keys, one per job, so a compromise of one does not reach another — and the deploy scripts refuse a configuration where a keeper is also the owner, the treasury or the attestor, rather than trusting somebody to remember.

What a keeper cannot do matters more than what it can. None of them can take a balance, redirect a payout, change a fee, or stop a claim. Where a keeper opens a window, it supplies no amounts, no recipients and no rates — every figure is read from the contract’s own state — and closing one is permissionless, so nobody can hold a creator’s money by declining to act.

One was added on 21 September 2026, and it exists to remove a hot key rather than to add one. The posted price feed can now be written by its owner or by an appointed keeper. A multi-signature wallet cannot run a cron every fifteen minutes, so the alternative was keeping that feed’s owner on a single hot wallet permanently. The keeper is appointed by one transaction after deployment, and the owner can replace it.

Be clear about what that feed is trusted for. Its answer is whatever was last posted to it, and it prices dollar-denominated figures — a creation fee, a market’s opening stake, prize sizing. It is deliberately not what decides custody of anything: the contract that gates currency listing reads its own feed for exactly that reason. A compromised price key misprices a one-dollar fee. It cannot take anything.

5.3 The boundary that is not a key at all

Some facts this platform writes on chain are not chain facts. Whether an account is enrolled, and whether its X subscription is live, are statements about an off-platform account, so something trusted has to assert them — and what asserts them here reads our own database.

Write access to that database is therefore equivalent to holding the attestation key. Separate keys imply a stronger guarantee than exists, which is why this is stated rather than left to be discovered. It is inherent to bridging an off-chain fact on chain rather than a defect: the alternative is putting a third party’s login response on chain, which is worse in every respect. Section 2.2 carries it as an open risk against the product it affects.

6. Verifying us

Anyone can create a token with any name, including ours, and phishing sites copy launchpads closely. Check the domain in the address bar, check that the factory address in section 3.2 matches what your wallet is about to interact with, and treat any message asking for a seed phrase or a “validation” transaction as theft. We will never ask for either.

The Hood’s contracts are immutable, audited by Claude Fable 5. Nothing on this site is financial, investment, legal or tax advice.