System Architecture
How venue adapters, attestors, policy programs, the prover, and the enclave authorize an exact action.
Pakt separates preparing an action, proving that it follows your rules, and authorizing a signature. The policy program defines the rules. The prover runs that program and produces evidence of its result. The enclave verifies the proof before permitting the restricted execution signer to sign.
The diagram shows the authorization path. The client supplies the proposed action and submits the signed result to the venue. Pakt does not submit it.
Components and Responsibilities
| Component | Responsibility |
|---|---|
| Agent and venue client | Prepare a complete action, request authorization, and submit the signed request unchanged |
| Pakt host | Authenticate the account, load its active Pakt and signer binding, coordinate work, and retain operations and receipts |
| Venue adapter | Translate the prepared action into the exact wallet-provider request and gather the required venue inputs |
| Attestors | Authenticate external account and market facts, their request context, and freshness |
| Policy program | Verify the evidence, reconstruct the exact request, apply the approved rules, and produce a decision with its request commitment |
| Prover | Execute the selected policy program and produce a cryptographic proof of its result |
| Enclave | Verify the Pakt approval, program identity, proof, request binding, and freshness and replay checks before releasing authorization |
| Restricted execution signer | Enforce its policy-limited permission and sign the exact authorized request |
| Venue | Accept or reject the submitted request and determine its execution outcome |
Follow One Action
1. Prepare the Request and Evidence
The client selects one active Pakt and supplies a complete venue request. The adapter gathers the inputs needed to evaluate it: for example, positions, balances, prices, margin requirements, fees, and account nonces.
Attestors authenticate those facts and bind them to the request context and a freshness challenge. They do not decide whether an action complies with a Pakt. That decision belongs to the policy program, so there is one authoritative interpretation of the venue's rules.
2. Execute the Selected Policy Program
The approved Pakt commits both its rules and an exact policy-program ID. The Hyperliquid program checks perpetual-order semantics; the Gateway program checks the Ethereum approval or order transaction and its Bitcoin destination.
The program verifies the signed evidence and reconstructs the exact wallet-provider request. It then evaluates every applicable Pakt rule. Caller-supplied fields such as asset, side, amount, route, destination, nonce, and expiry must be bound to the request being proved.
The prover executes this program and returns a proof with a journal: the public result that commits to the Pakt root, decision, exact request, freshness challenge, and policy-state continuity. Proving currently uses RISC Zero. The prover can be replaced without giving it permission to choose another Pakt or release a signature.
3. Verify Inside the Enclave
The enclave receives the canonical Pakt, its Pakt signer approval, the proof, and the exact request. It recomputes the Pakt root and verifies that the approval matches the account's Pakt signer and environment.
It checks the proof against the program ID committed in that Pakt and checks the journal's root, request commitment, challenge, freshness, replay state, and continuity. A valid proof for a different program, Pakt, Pakt signer, or request cannot authorize this action.
The enclave does not parse venue orders or reimplement leverage, pricing, or asset rules. Those semantics live in the policy program. Its job is to verify the shared proof result and bind authorization to the exact bytes being signed.
4. Sign or Refuse
For an allowed action, the enclave releases an approval stamp over the exact wallet-provider request. The restricted execution signer checks that authorization and produces the venue-valid signature. The client receives the signed request and submits it unchanged.
A proved refusal produces a receipt without an approval stamp or wallet signature. Validation, proving, or signing errors are separate from policy refusals. If an error occurs after authorization was released, the client must reconcile the existing operation before starting another one.
Both allowed and refused receipts can be verified in the browser. Venue execution is a separate event; a verified receipt alone does not establish a fill or settlement.
Why Program Identity Is Part of the Pakt
A rule is meaningful only together with the program that interprets it. The canonical Pakt therefore commits its envelope version, program ID, and policy payload. Changing the evaluator or any committed rule changes the root and requires a new Pakt signer approval.
For the envelope, typed payload, and canonical encoding, see The Pakt Artifact.
A compatible policy-program release can add or change venue rules while preserving the common proof and journal contract. It needs prover support and new Pakt approvals, but does not by itself require a new enclave. Changes to the enclave's verifier, identity, signing, or key boundary require a measured runtime release. See Runtime Upgrades for what these changes mean for existing Pakts and signer permissions.
Trust and State Boundaries
The enclave runs in an attested hardware-isolated environment. Its signing authority is bound to the measured runtime, the Pakt signer, and the environment. The underlying wallet's private key remains with the wallet provider, and the owner retains recovery, withdrawal, and signer-management authority.
The current staging host and database are trusted to supply the latest signer binding and lifecycle state. Verifying an activation signature does not prove that the host has disclosed a later disable. Hardware attestation also does not establish that only one runtime instance exists or provide durable replay coordination across restarts or clones.
The deployment assumes one authoritative enclave for each approver key. It serializes proof acceptance and advances its policy frontier before releasing an authorization; a same-key clone is outside the trust model. The backend then atomically retains the accepted receipt, successor state, exact operation, and any Gateway wallet nonce before provider signing. PostgreSQL is the durable recovery record, not a parallel authorization gate. Clients must still follow the retry rules.
These boundaries explain the current limits on stateful policies. Account thresholds project still-live Hyperliquid risk increases, while per-request batch budgets do not become daily or rolling limits. See Rules and Limits for the precise behavior and Security and Trust for the broader trust assumptions.