The Pakt Artifact

A Pakt is a fixed set of typed constraints. Pakt encodes them with Simple Serialize (SSZ) so the same constraints always produce the same bytes and root. The root is the identifier used by owner approval, proofs, and receipts.

The readable data model is Rust. Natural-language intent, template names, and agent explanations help humans review it; the canonical SSZ artifact is authoritative.

A Hyperliquid Pakt in Rust

This is the readable Rust representation of the balanced Hyperliquid perpetuals Pakt. It allows BTC, ETH, and PAXG perpetuals with USDC margin, caps an action at $100 and leverage at 3×, and requires the projected account to remain at or above its liquidity, health, and equity floors.

Pakt {
    version: 1,
    valid_until: u64::MAX,
    constraints: vec![
        // The owner-approved delegated agent and its owner/master authority.
        IdentityConfig {
            agent_key: HL_AGENT_KEY,
            master_key: Some(HL_MASTER_KEY),
        },

        // The authenticated evidence this Pakt accepts.
        OracleConfig { pubkey: HL_ATTESTOR_KEY },
        StateSourceConfig {
            pubkey: HL_ATTESTOR_KEY,
            state_source_id: 1,
        },
        HeartbeatConfig { max_staleness_secs: 15 * 60 },
        ExpiryConfig { delta_secs: 20 * 60 },
        MarginMode { required_mode: Cross },

        // Guards over the exact proposed order.
        AllowedAssets {
            assets: vec![
                AssetRef::hyperliquid_mainnet(0),
                AssetRef::hyperliquid_mainnet(1),
                AssetRef::hyperliquid_mainnet(187),
            ],
        },
        TradeSizeCap { max_usd_micro: usd(100) },
        RateLimit { max_actions: 10 },
        EffectiveRateCollar {
            min_rate_micro: 996_000,
            max_rate_micro: 1_004_000,
        },
        CollateralMovement { max_out_usd_micro: usd(50) },

        // Invariants over the authenticated projected post-trade state.
        LeverageCap { max_centi_x: 300 },
        LiquidityReserve { min_bps: 2_000 },
        HealthFloor { min_bps: 11_500 },
        EquityFloor { floor_usd_micro: usd(50) },
    ],
}

This Rust value shows the data model developers reason about. Through MCP, an agent supplies a strict JSON draft and receives the canonical bytes and root.

Venue-Native Asset Identity

Every allowed asset commits three facts directly:

For example, the first allowed market above is committed in a strict JSON draft as:

{
  "chain": { "kind": "hyperliquid_mainnet" },
  "asset": { "kind": "venue_index", "index": 0 },
  "oracle": { "kind": "hyperliquid_mark" }
}

Index 0 is the identity Pakt checks, not a key into a Pakt-owned mapping. The example commits Hyperliquid mainnet indices 0, 1, and 187 for BTC, ETH, and PAXG perpetuals. The names are review labels; the indices are the execution identities. Changing the chain, asset identifier, or oracle changes the Pakt root.

This is not a closed market list. list_hyperliquid_perp_markets reads the live Hyperliquid registry and returns draft-ready AssetRef objects for default and HIP-3 perps. Default perps retain their native index. A HIP-3 perp uses Hyperliquid's global id 100000 + dex_index * 10000 + local_index; Pakt commits that exact integer and the attestor resolves it through the live DEX registry. Catalogue support describes market metadata. The account's current margin mode is not part of this public read and is checked separately during authorization. The current authorization path supports active, cross-margin-compatible, USDC-collateralized perps and fails closed for isolated-only, non-USDC, or delisted markets. Spot assets are outside this path.

How One Order Is Evaluated

Suppose the approved agent proposes a single BTC perpetual immediate-or-cancel (IOC) buy. IOC means the venue fills available liquidity immediately and cancels any unfilled remainder. The numeric asset in the wire request is Hyperliquid's venue index; the adapter reads authenticated metadata at that index for precision and price, then checks the exact index against the Pakt. Pakt does not translate it through another asset-id table.

{
  "kind": "prepared_hyperliquid_order",
  "order": {
    "legs": [{
      "asset": 0,
      "is_buy": true,
      "limit_px": "60000.0",
      "sz": "0.25",
      "reduce_only": false,
      "order_type": { "limit": { "tif": "ioc" } }
    }],
    "grouping": "na",
    "nonce": 1787000000000,
    "vault_address": null,
    "expires_after_ms": 1787000120000
  }
}

Pakt bases its decision on authenticated Hyperliquid marks and account state. It decodes the order and evaluates each applicable term:

Every applicable check must allow. One refusal means the secure approver releases no stamp and the wallet provider produces no signature.

Canonical Identity

Pakt sorts constraints by (kind, scope), rejects duplicates, encodes the result as canonical SSZ, and calculates its SSZ hash_tree_root. The balanced Hyperliquid example above produces this root:

00e4d8b2e21a38fc683c6cdd87076c99845ea2aa79c326baa0b580b362c3a3da

Changing a key, bound, scope, expiry, or constraint changes that root.

draft_pakt returns the complete review bundle:

• the strict source draft;
• canonical SSZ bytes;
• the Pakt root;
• ALLOWED / NOT ALLOWED — a human-readable summary of every rule;
• comprehension examples — sample actions with Pakt's allow/refuse result.

Keep those fields together. The root identifies the artifact; owner approval binds that root to an account and environment.

How Agent Identity Relates to the Artifact

IdentityConfig records the delegated agent and owner/master identities. The proof does not evaluate it as an order limit. Instead, the owner approves the delegated agent at the wallet or venue boundary, and the signing boundary enforces that approval. The other constraints decide which actions from that agent may be signed.

The example also commits CollateralMovement, but the approved Hyperliquid agent has no withdrawal or transfer path: those actions require the owner's master authority. The constraint is therefore committed but inert in this execution surface. Its presence must not be presented as the mechanism that prevents withdrawals.