Architecture overview

Contracts (HyperEVM)

• Exchange: the trading contract. It keeps every balance, opens and closes positions, settles results, runs the payout queue and holds the LP and the fee accounts. A thin entry point delegates to four libraries (trading, queue, funds, admin). Opens and closes arrive only through the BatchExecutor; withdrawals and the maintenance calls can come from anyone.
• BatchExecutor: the relayer’s only way in. It accepts batches only from the configured relayer keys and forwards each signed call, to a fixed list of functions only.
• SessionKeyManager: registers session keys, verifies every signature and nonce for the Exchange, and handles revocation. Registration arrives through the relayer; revocation can also be a direct call from your wallet.
• Token, Staking, Tokenomics: the TOKEN token (transfers disabled at launch), the staking contract with its reward accumulator, and the contract that computes and mints TOKEN for losses and tracks the LP.
• BuilderRegistry: the approved builders and the one builder fee rate, capped at 15%. Not upgradeable: replacing it is a new deployment that the SessionKeyManager is pointed at.
• DepositProxyFactory and DepositProxy: derive each account’s deterministic deposit address and deploy the small contract behind it, which can send USDC on HyperCore only to the Exchange. Neither can be upgraded: a deposit address must never change.
• Lenses and PriceOracle: read-only views over the Exchange and HyperCore, and a price helper, for apps and services. The Exchange reads the precompiles directly, not through them.

Addresses are on contract addresses.

Precompiles (HyperCore)

• BBO 0x000000000000000000000000000000000000080e: the best bid and best offer; their midpoint is the execution price.
• Mark 0x0000000000000000000000000000000000000806: Hyperliquid’s mark price, read by the dormant price guards and as a fallback when a market is retired.
• Oracle 0x0000000000000000000000000000000000000807: Hyperliquid’s oracle price, the same uses as the mark.
• CoreWriter 0x3333333333333333333333333333333333333333: the system contract that sends actions to HyperCore. Deposit proxies use it to send USDC to the Exchange’s HyperCore account, and the Exchange uses it to pay withdrawals to your HyperCore account.

Balance precompiles let the Exchange check that a deposit really arrived before it credits it (Deposits: CREATE2 proxies).

A trade end-to-end

You sign an intent with your session key and the app sends it to the relayer, which checks it and queues it. The relayer packs queued intents into a batch and sends it to the BatchExecutor, which calls the Exchange once per intent. The Exchange verifies the signature through the SessionKeyManager, reads the BBO for the execution price, opens the position or settles the close against the LP, updates your balance and, on a loss, has Tokenomics mint TOKEN to you. Intents from many accounts share one transaction, but each is settled on its own: the relayer marks every call as allowed to fail, so one failing intent does not stop the others.

Frontends

Every open and close is submitted by our relayer. Another frontend can produce the same signatures and send them through the relayer’s API (intents API), but it cannot submit opens or closes to the contracts directly.

Off-chain services

Service	Job
Relayer intake	Accepts signed intents, checks them and reserves balances.
Relayer engine	Schedules queued intents and submits them in batches.
Indexer	Follows the chain block by block, checks the accounting invariants every block, and streams account updates.
Read API and stream	Serve market state, history and the live account stream to the app.
Keepers	Liquidate, harvest the queue, distribute staking rewards, move the open-interest caps, switch the payout curve on its schedule, replay deferred mints.
Sweeper and funding worker	Sweep deposits and move withdrawals on to other chains.

None of these services can sign for you or move your funds without your signature. If they stop, trading stops, but your free balance stays withdrawable from your wallet.

Governance

The owner of every upgradeable contract is a timelock: an upgrade or parameter change is scheduled by the governance multisig and can execute only after 2 days. A second timelock, with a delay of 7 days, controls who holds the first one’s roles. A guardian multisig can act at once in an emergency, within the narrow limits listed on Risk.