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 cryptographically verifiable. Users must trust the backend operator.

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 08:00 UTC and settle in cash based on the settlement price.

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 included in portfolio margin calculations, allowing capital-efficient hedging strategies.

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.

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. On-chain operations provide verifiability but are slower and more expensive.

See also: