Skip to main content

Architecture

Hypercall uses a hybrid execution model: off-chain matching for speed, with on-chain settlement and account management for security.

Backend ArchitectureSingle Options Market, Multiple Order SourcesOther RoutersAdditional integrationsHypercall FrontendMM/Pro UI + MobileOrders / CancelsHypercall SDK / API Gateway• Auth / Keys• Order + Cancel• Market data + risk streamHypercall Options LayerOff-chainOrderbook& MatchingPricing /Vol SurfacesRisk EngineIM/MM, liquidationsSettlement /State SyncOracleIndex pricesSettlement TWAPDelta exposure /hedging flowsHyper EVMSettlement layerHIP-3 PerpsDelta hedging venueHyperCoreBase layer infrastructureLive integrationAdditional partners

Trust Boundaries​

Off-Chain (Hypercall Backend)​

Responsibilities:

  • Order matching and execution
  • Orderbook management
  • Pre-trade margin checks
  • Liquidation orchestration
  • Market data and pricing
  • WebSocket streams

Trust assumption: Users trust the Hypercall backend to:

  • Match orders fairly (price-time priority)
  • Enforce margin checks correctly
  • Monitor accounts and trigger liquidations when needed
  • Provide accurate market data

Limitations: Off-chain operations are not fully cryptographically verifiable in Mainnet Alpha. Users must trust the backend operator for matching, market data ingestion, margin checks, and RSM command issuance.

Path forward: Hypercall is working toward RSM decentralization and stronger trustlessness guarantees. The roadmap will specify how state commitments, signer roles, dispute paths, and operator controls become more verifiable over time. Mainnet Alpha is the constrained first phase, not the final trust model.

On-Chain (Smart Contracts)​

Responsibilities:

  • Account ownership and manager control
  • Deposits and withdrawals
  • Liquidation auctions (position transfer)
  • RSM commands (risk management operations)
  • Settlement price posting
  • Hyperliquid integration (perp orders via ActionCaster)

Trust assumption: On-chain operations are cryptographically verifiable. Users can verify contract code and state.

Security: Account ownership cannot be changed without on-chain transaction. Liquidation requires on-chain auction.

Order Execution Flow​

1. Order Submission​

User action: Submit order via POST /order with EIP-712 signature.

Backend validation:

  • Signature verification (EIP-712)
  • Pre-trade margin checks (scenario-based)
  • Order admission (tier, expiry, rate limits)

Result: Order is accepted (ACKED) and queued for matching, or rejected with reason.

2. Order Matching​

Process: Orders are matched on the orderbook using price-time priority.

Execution: When orders match, fills are created and positions are updated in the backend database.

Not on-chain: Individual order matches are not recorded on-chain. Account state is synced via margin root updates.

3. Position Updates​

Process: Positions are tracked in backend database and updated in real-time.

User access: Query positions via GET /portfolio or WebSocket portfolio channel.

On-chain sync: Margin root (cryptographic commitment to account state) is updated on-chain periodically and on critical events.

4. Settlement​

Expiry settlement: Options expire at the contract expiry time and settle in cash based on the settlement price. Mainnet SPCX expires at 4:00 PM ET; testnet currently expires at 08:00 UTC.

Settlement price: 30-minute TWAP of Hyperliquid Oracle index price, posted on-chain via SimpleOracle.setExpiryPrice().

Process:

  1. Oracle computes 30-minute TWAP ending at expiry
  2. Settlement price posted on-chain
  3. Intrinsic value calculated for each position
  4. Cash balances updated
  5. Positions closed

Account Management​

Account Creation​

Process: Accounts are created on first deposit or when explicitly requested.

On-chain: Account contract deployed as a BeaconProxy (gas-efficient minimal proxy pattern).

Manager: Each account has a manager (EOA) who controls the account and can authorize agents.

Deposits and Withdrawals​

Deposits:

  • USDC: Transferred to Exchange via HyperCore
  • Option ERC20s: Deposited via Exchange contract

Withdrawals:

  • Must pass off-chain risk checks (sufficient margin post-withdrawal)
  • Executed on-chain via Account contract
  • Manager signature required

Trust boundary: Deposits and withdrawals are on-chain and verifiable.

Liquidation​

Liquidation uses a state machine with a grace period before auction:

StateDescriptionDuration
HealthyEquity > MM required-
PreLiquidationEquity < MM, grace period active60 seconds
InLiquidationDutch auction in progressUntil filled
LiquidatedPositions transferred-

Partial vs Full Liquidation​

TypeConditionBehavior
Partial≤ 5 positionsLiquidate specific positions until healthy
Full> 5 positionsLiquidate entire account

Auction Mechanics​

Solvent auction (Equity > 0): Starting price = equity × (1 - penalty), decreasing over time. Liquidators bid to take positions.

Insolvent auction (Equity < 0): Insurance fund provides bonus to incentivize liquidators to absorb underwater positions.

On-chain: Auction execution and position transfer happen on-chain via Exchange contract.

See Liquidation for full details.

Hyperliquid Integration​

HIP-3 Perps​

Hypercall accounts can execute perp orders on Hyperliquid via ActionCaster:

Flow: Account contract → ActionCaster → Hyperliquid L1

Use cases:

  • Delta hedging options positions
  • Cross-venue margin (perp positions count toward portfolio margin)

Cross-Margin​

HyperCore perp positions are designed to be included in portfolio margin calculations, allowing capital-efficient hedging strategies. Portfolio Margin is disabled for general users in Mainnet Alpha.

RSM Commands​

RSM (Risk & Settlement Manager): Backend component that issues on-chain commands for risk management.

Commands include:

  • Reduce-only orders (force position closure)
  • Debt repayment (force withdrawal to cover negative balance)
  • Settlement execution

On-chain: RSM commands are signed by the RSM signer and executed via Account contract. Users can verify the RSM signer address and all command executions on-chain.

Decentralization roadmap: The current RSM signer is operator controlled. Future roadmap work will publish how this role is decentralized or otherwise made more trust-minimized.

What You Can Verify​

On-Chain (Verifiable)​

  • Account ownership (manager address)
  • Account contract deployment
  • Deposits and withdrawals
  • Liquidation auctions and results
  • Settlement prices (oracle posts on-chain)
  • Hyperliquid orders (on-chain execution)
  • RSM commands (on-chain execution)

Off-Chain (Trust Required)​

  • Order matching fairness
  • Margin calculations
  • Position tracking accuracy
  • Market data accuracy
  • Liquidation trigger timing

Security Model​

Key principle: Critical operations (account ownership, deposits, liquidation, settlement prices) are on-chain and verifiable. Operational efficiency (matching, margin checks) is off-chain.

Trade-offs: Off-chain matching provides speed and efficiency but requires trust in the backend operator today. On-chain operations provide verifiability but are slower and more expensive. The RSM decentralization roadmap is the path from this Mainnet Alpha model toward stronger trustlessness.

See also:

Last updated on