Architecture (conceptual)

Single consensus stack: HyperCore owns the book; HyperEVM sits inside the same universe but is not part of official HIP-4 settlement.

┌─────────────────────────────────────────────┐
│              HyperBFT Consensus             │
│           (L1 blocks every ~0.07s)          │
├─────────────────────────────────────────────┤
│                 HYPERCORE                    │
│   Order book · Perps · Settlement · State   │
│                                             │
│   HIP-4 prediction markets (native L1):     │
│   - registerTokensAndStandaloneOutcome      │
│   - CLOB pair minting (YES+NO = 1.00)       │
│   - VoteGlobalAction (auto-settlement)      │
│                                             │
│   ┌───────────────────────────────────┐     │
│   │           HYPEREVM                │     │
│   │   (not used by official HIP-4)   │     │
│   │   Third-party parimutuel only     │     │
│   └───────────────────────────────────┘     │
└─────────────────────────────────────────────┘

Lifecycle

Three phases from creation to payout — all on L1.

[1] CREATE
    registerTokensAndStandaloneOutcome
    → mints YES/NO token pair
    → strike ≈ markPx at creation
    → markets open ~50/50

[2] TRADE
    Standard CLOB in USDH
    → pair minting: BUY YES @ 0.40 = mirror ASK NO @ 0.60
    → trade until expiry

[3] SETTLE
    VoteGlobalAction
    → system wallet reads price at expiry
    → all positions in one block
    → winner 1.00/token, loser 0 — instant balance credit

Pair minting

A BUY on YES is mirrored on the NO book so YES + NO always prices to 1.00. Collateral locks on both sides until settlement.

Observed book mirror

#22430 (Yes):  ASK 0.5 × 835  (1 order)
#22431 (No):   BID 0.5 × 835  (1 order)

Minimum notional (community formula): size × min(markPx, 1 − markPx) ≥ $10 USDH — feeds in Info endpoint.

L1 operator cluster (testnet)

We traced eight linked system addresses on HyperCore testnet that appear to operate the prediction-market admin surface together. Two roles are mapped from on-chain activity; the other six remain unmapped (validators, bridge, fee routing, or other Core roles — hypotheses only).

0xc25c… — HIP-4 operator

Observed actions (explorer labels — JSON payloads in docs often use lowercase variants such as registerTokensAndStandaloneOutcome and VoteGlobalAction):

• Create markets — RegisterTokensAndStandaloneOutcome, RegisterOutcome
• Settle markets — SettleOutcome (settlement in API research as VoteGlobalAction)
• Create questions — RegisterQuestion
• Change copy — ChangeOutcomeDescription, ChangeQuestionDescription
• Register named outcomes and related tokens

0xe92d… — Oracle

Holds oracle / on-chain price-feed duties. A historical settlement from this wallet was observed (same tx often cited for VoteGlobalAction discovery); more recent settlement traffic has been attributed to 0xc25c… in our trace — roles may shift on testnet.

Separation from HyperEVM parimutuel

None of the eight L1 cluster addresses overlap the third-party parimutuel deployer 0xe21c78037329d06fe0d6fefc4221aaa67cb0d135. Official HIP-4 CLOB flow and the EVM contest contracts are operated or owned by distinct entities on testnet.

Full table + proof link: API & data — system wallets. On mainnet, duties would likely be distributed across validators — not guaranteed here.

Open questions

Research gaps — not failures of the doc, just unknowns as of the last research pass.

• Collateral redistribution across multiple outcomes at settlement
• Whether HyperEVM parimutuel deployer is team-adjacent or third-party (funding trace)
• Mainnet: validator settlement, permissionless creation
• HIP-3-style feeds for subjective resolution (food, races)