Security and risk
What Hoodium can do with your funds, what it cannot, which keys exist, what has and has not been reviewed, and the risks that remain after all of it. Read this before you arm anything.
Custody
Hoodium is non-custodial in the strict sense: it never holds a private key, a seed phrase, or a session key of yours, and there is no deposit address. Your positions stay in your wallet, as NFTs you own, the entire time.
Three kinds of permission exist, and it is worth knowing which is which:
| What you grant | To what | What it enables |
|---|---|---|
| Nothingconnect only | The site | Reading. Connecting a wallet is a signature, not a transaction, and grants no spending or transfer rights. |
setApprovalForAll | The claim router | Collecting fees to you. The router acts only for msg.sender, re-checks ownerOf per token, pays only msg.sender, and can reach no verb but collect. |
setApprovalForAll + a signed order | The automation contract | Exactly the action named in the order, on the position named in the order, within the limits in the order. Proceeds go to the owner. |
Revoking. Every approval above is a standard ERC-721 operator approval and is revocable from your wallet or any approval-manager tool, without Hoodium’s cooperation and without warning it. Revoking stops every rule on that venue at once.
What the contracts cannot do
- Send a position anywhere but back to its owner. There is no recipient parameter for a relayer to fill in and no path that transfers a position out.
- Act on an order you did not sign. The signature is verified against the position’s current owner at execution.
- Exceed the fee cap. 5% is a revert in the automation contract’s code; the exit and rebalance tiers are pure functions of the pool’s fee tier and governance cannot widen them at all.
- Be upgraded out from under you. The contracts are not proxies. A change means a new deployment, a new EIP-712 domain, and every existing order refusing to execute until its owner re-signs.
- Withdraw a graduated launchpad position. The locker has no withdrawal path, for anyone.
The keys that do exist
Governance
Sets the executor, the allowlisted swap router and the platform fee within its coded cap; can pause relaying; can hand governance on. It cannot move, close or touch a position. Its key is never present in a server environment.
Executor
A dedicated wallet whose key lives in the worker’s environment and pays gas to relay. Compromising it buys an attacker the ability to submit orders users already signed, at a time of their choosing, within those orders’ own limits, and nothing else. This split is what makes a server-resident key acceptable.
The platform fee recipient is currently an externally owned account rather than a multisig. That is a known gap, recorded as a requirement before third-party funds scale, and moving it is a single governance call.
Audit status
No Hoodium contract has been audited by an external firm. Stated plainly because the alternative is letting a test-suite count imply something it does not.
What does exist:
- Automation: its own
forgesuite plus a harness suite, including a round trip that takes a signature built by the real app builder, signs it with a real wallet, and verifies it against the real contract. Every deployment is checked on chain afterwards: venue managers, router allowlists, pause state, executor, governance, and runtime bytecode compared byte for byte against the artifact of the commit it was built from. - Claim router: deliberately minimal. No governance, no executor, no fee switch, no pause. There is no key to lose and nothing to configure after deployment.
- Launchpad: a unit suite, a fork suite against the real Uniswap deployment on Robinhood Chain, an internal audit pass whose findings were fixed, and a full graduation rehearsed on mainnet for three dollars with real USDG, real gas and real irreversibility, then re-asserted against the mined result rather than the simulation. 33 checks, 0 failures.
The deployments were made for the owner’s own funds first, consciously, without an audit. Opening them further is a separate decision that revisits that question.
Risks that remain
Using the LP app
- Smart contract risk. Unaudited code holding approvals is a real risk, and no test suite retires it.
- Impermanent loss. A concentrated range converts into the falling side. Hoodium measures this and shows it; it does not prevent it, and no automation can.
- Execution timing. A trigger can be met and then unmet before a relay lands. The time buffer narrows the window; it does not close it. A relayer outage or a congested chain means a rule fires late or not at all.
- Thin pools. On a pool with little depth, a price read is easy to move and a fee balance can be worth far less than it appears. Hoodium refuses to value fees at more than the pool could actually absorb, and marks unpriceable tokens rather than guessing. A thin pool is still a thin pool.
- Derived numbers. Everything on the board is reconstructed from chain events. Bugs in that derivation change what you see, not what you own.
Using the launchpad
- Locked liquidity is not a safe token. Locking guarantees the pool cannot be pulled. It guarantees nothing about the token, the creator, or the price.
- Graduation cannot be un-run. The USDG that reaches the pool is permanently locked liquidity. Trading fees are collectable forever; the principal is not recoverable by anyone, including the creator.
- USDG is freezable by its issuer, like any regulated stablecoin. Hoodium’s contracts are pull-based throughout partly because of this: a push to a frozen address inside graduation would break graduation permanently.
- A curve is a curve. Before graduation the only price is the curve’s own. Selling back is always possible until the target is reached, minus the 1% fee in each direction.
Reporting a vulnerability
Write to hello@hoodium.app with enough detail to reproduce. There is no bug bounty programme yet; there is a maintainer who reads that address and will act on a real report. Please do not open a public issue for something exploitable.
Operational transparency
Live health for every service is at status.hoodium.app. The app carries a kill switch that halts writes and shows a banner rather than failing quietly, and it says when the backend is unreachable instead of rendering stale numbers as current.