Security
Security review
An internal review of the contracts' source code. No third party has audited the contracts yet, and this page does not replace that.
What was reviewed
The source code of the Exchange and its admin module, the libraries it links, the order, payout and liquidation logic, deposits and withdrawals, session keys, the batch executor, the deposit proxies, staking, the token and its rewards. The code was read as it stands at commit e456c4d (2026-11-06). The off-chain services, the apps and the deployment scripts were outside the scope.
Result
The review found no critical or high-severity defect in the contract code. Every path that moves funds was read line by line and held. The code added most recently (staking, the token and the wallet close) has had the least review; it was read in full, and the staking accounting was also tested as described below.
What held
- Access control. Every state-changing function checks its caller before it changes anything. The admin module cannot be used on its own. Ownership cannot be renounced, and only the owner can upgrade a contract.
- Signatures. Typed messages carry the chain and the verifying contract, reject malleable signatures, use each nonce once and only after the signature checks out, and expire. A session key cannot sign a message meant for the wallet, the wallet cannot sign a trade, and revoking all keys at once works.
- Value flow. The accounting between the pool’s cash, the tracked pool, the payout queue and the side bucket stays consistent. There is no unchecked arithmetic, narrowing conversions are checked, and every rounding goes in the direction the design fixes. Fees are capped, and a withdrawal lowers the balance before the Hyperliquid action is sent.
- Reentrancy. Every function that moves funds is protected against re-entry, and state is written before external calls. The token hook runs on a fixed gas allowance, so a caller cannot force it to be deferred.
- Deposit addresses. A deposit proxy can send HyperCore actions only through the Exchange, and its owner can move only EVM tokens and native HYPE out of it. The derivation of the address is unchanged.
- Code patterns. No
selfdestruct,tx.origin,.transfer,.sendorcallcode. The only delegate calls go to the admin module and the linked libraries. - The burning token. BACK is staked the moment it is minted and burns 7 days later, at the next midnight UTC. Nothing counts down until the tracked LP first reaches $500,000. Each batch’s expiry day, the lazy walk over an account’s batches, the global schedule, replayed mints and the start of the countdown agree with this design, which Rewards & claims describes.
How the staking accounting was tested
A separate model was written from the published rules alone, without reading the contract’s arithmetic. Random sequences of mints (late replays included), the start of the countdown, distributions, claims and jumps in time (to one second before midnight, to exactly midnight, by days, and up to 150 days idle) ran against the contract and the model and were compared after every step. Across 76,800 calls, and 38,400 more with long idle gaps, there was no difference: live balances and supply matched exactly, rewards matched within rounding dust, no account could claim more than was set aside, and every claim paid exactly what was pending. Two bugs added on purpose were caught.
Findings
| Severity | Finding | Status |
|---|---|---|
| Medium (assurance) | The static analysers and fuzzers (Slither, Aderyn, Medusa, Echidna, Halmos, Gambit) last ran before the token was rewritten. The new code has the test suite, the invariant campaign at its default length and the model above. | To be re-run before the external audit. |
| Medium (design, disclosed) | At launch every on-chain price guard is off: fills use the midpoint of Hyperliquid’s raw best bid and offer, at high leverage. Protection comes from the relayer’s limits, the keepers and the sentinel, all off-chain. | Disclosed; see Risk. |
| Low | A session key’s builder-fee consent is not cleared when the key is registered again with the older signature type, or when it is revoked, so a builder named later could earn up to the rate consented to before. The ceiling on builder fees bounds it. | To be fixed before the production deployment. |
| Low | The queue of deferred token mints has no way to skip an entry. If one entry failed on every replay, later mints would wait behind it. A change in gas costs on HyperEVM, or a bug in a future upgrade, could cause that. | Recovery is an upgrade through the timelock. |
| Medium (economic, disclosed) | Since 2026-11-08 a loss mints on its whole mint basis: wins are not netted against later losses and no cap limits an account. A trader can hold offsetting positions and mint on the losing leg whatever the market does. This review read the code before that change. |
Disclosed. The fees, the burn after the countdown and the share other live tokens take of each distribution are the only brakes; see Risk. |
| Low | The guardian can pause trading, retire a market for good, replace the market keeper and the off-hours keeper, authorize or remove relayers, and raise the gas allowance for price reads. It cannot move funds or unpause. | By design; see Risk. |
| Info | The token’s balance and supply are exact at all times, but the event for a burned token is logged only when the account is next touched, so tools that add up events show burned tokens as live. | Read balances, not events. |
| Info | Reward timing: a mint just before a distribution takes a pro-rata share, the first holder takes whatever was unallocated, and after a long idle spell the expired batches share the distributions made meanwhile. Never more is paid out than was distributed. | Documented; solvent in testing. |
| Info | The Exchange’s version string reads older than its interface version. | To be fixed before the production deployment. |
| Info | One function of the deposit proxy is never called. | Kept, because the proxy’s code fixes every deposit address. |
| Info | The owner can credit an account from Hyperliquid surplus that nobody has claimed. | A trust assumption; behind the timelock in production. |
Not covered
- The read-only lens contracts, the market-admin library and the bounds library were skimmed, not reviewed line by line.
- The full test suite, and the checks on storage layout, interface, contract size and deposit-proxy code, were not run again for this review. The results of the last full run were relied on.
- Fork tests against Hyperliquid, the deployment scripts beyond their role checks, the off-chain services and the apps.
- The token’s mint rule after the change of
2026-11-08(no netting of wins, no cap), the gas behaviour of the token hook, and whether Hyperliquid’s precompiles behave as the tests assume.
Keeping this page honest
This is one review at one point in time. It says nothing about changes made to the contracts after the commit above. The contracts are upgradeable behind a timelock, so what is deployed at any moment must be checked against the contract addresses.