The Pakt Artifact

A Pakt artifact is the machine-readable object you approve. It commits both the rules and the exact program that interprets them. Human-readable summaries help you review it; the canonical bytes are authoritative.

For the behavior of individual rules, start with Rules and Limits. This page explains the technical representation and how to inspect it.

Envelope and Policy Payload

The artifact has two layers:

Pakt envelope
├─ format version
├─ policy-program ID
└─ policy payload
   ├─ policy schema version
   ├─ valid_until
   └─ constraints[]
      ├─ kind
      ├─ scope: venue class + instance
      └─ typed parameters, encoded as bytes

The enclave understands the envelope, not the venue's constraint language. The selected policy program decodes the payload and owns its semantics. Current Hyperliquid and Gateway programs use the typed policy model shown here.

The current inner policy contains a u16 schema version, a u64 valid_until timestamp in Unix seconds, and at most 128 constraints. Each constraint has a numeric kind, a scope, and at most 2,048 parameter bytes. The kind selects the parameter type; the scope identifies its venue class and instance. The outer format version and inner schema version are separate.

A new compatible policy program can interpret different rules while retaining the envelope and shared proof contract. It still changes the artifact's root and requires Pakt signer approval. See System Architecture.

A Hyperliquid Pakt in Rust

The current Rust authoring model separates pakt_seal::Policy (typed rules) from pakt_ssz::Pakt (the complete envelope). This library-level example loads the unchanged balanced template and checks its canonical round trip; it is not a standalone SDK installation or an activation:

use pakt_authoring::presets::load_preset;
use pakt_ssz::{Pakt, Ssz};

let example = load_preset("perps-balanced")?;
let compiled = example.compiled;

let artifact = Pakt::from_ssz_bytes(&compiled.ssz_bytes)?;
assert_eq!(artifact.ssz_bytes(), compiled.ssz_bytes);
assert_eq!(artifact.hash_tree_root(), compiled.root);
assert_eq!(artifact.policy_payload(), compiled.policy.ssz_bytes());

That template includes BTC, ETH, and PAXG perpetuals, a $100 opening-trade cap, a 3× leverage threshold, a 20% liquid reserve, a 1.15× maintenance-margin health floor, and a $50 equity floor. Hyperliquid account conditions include the worst-case still-live signed exposure described in Rules and Limits. These are example values, not a personalized recommendation.

Through MCP, call draft_pakt with preset_id: "perps-balanced" to inspect the same kind of complete result without Rust tooling. Use the returned source.draft_json to edit a draft; use pakt.canonical_ssz for activation preparation.

Reading Typed Values

The source spells kinds and venues by name. Compilation resolves those names and encodes each constraint's typed parameters:

Omitting a required selector does not mean "any". A named rule also cannot enable a venue or action the program does not support. For projected account checks, batch scope, and reduce-only exceptions, use Rules and Limits.

Venue-Native Asset Identity

An AssetRef commits three coordinates: the chain namespace, its native asset identifier, and the valuation source. For example:

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

The index is the venue identity Pakt checks; a symbol such as BTC is a review label, not an authorization identifier. For HIP-3 markets, the committed index is Hyperliquid's global asset ID. Copy the exact asset_ref from list_hyperliquid_perp_markets rather than maintaining a separate symbol-to-ID mapping.

Changing the chain, asset identifier, or oracle changes the root. The oracle coordinate identifies the price source; the accepted attestor public key is committed separately in the data-source configuration.

Canonical Identity

Compilation validates the supported kinds, parameter types, required selectors, and venue combinations. It sorts constraints by (kind, scope) and rejects duplicates. Strict decoding rejects non-canonical bytes instead of repairing them. A source draft and an imported artifact pass through the same semantic validation before Pakt presents a trusted readback.

The envelope and current payload use Simple Serialize (SSZ). The Pakt root is the envelope's SSZ hash_tree_root, not a hash of the JSON text and not a plain SHA-256 hash of the serialized file. It commits the format version, program ID, and exact payload, including the payload's length.

Reordering valid source constraints or changing JSON whitespace does not change the compiled artifact. Changing a committed limit, destination, data source, scope, validity, or program does. A preset name alone does not pin a root across program releases; retain the bytes and root returned by the compilation you reviewed.

From Artifact to Authority

The artifact does not contain a private key or establish current account authority by itself. Two accounts can compile identical rules; each still needs its own Pakt signer approval and account binding. Keep the editable source, readable review, canonical bytes, and root together. To inspect a decision later, follow Verify a Receipt; for the assumptions behind that verification, read Security and Trust.