Security and Trust
What Pakt verifies, which components you trust, and where its guarantees stop.
Pakt is designed to constrain an agent you do not trust with unrestricted wallet access. The agent may propose an action, but cannot change your approved rules or obtain an arbitrary wallet signature. A proof binds the decision to the exact Pakt and request; the enclave verifies that proof before permitting signing.
That guarantee depends on the approved policy program, authenticated inputs, wallet permissions, and the trust boundaries below. It is not a claim that every part of the system is trustless.
MCP Access Is Not Signer Control
An authenticated MCP client can read account information, draft rules, stage browser review, and propose actions. It cannot approve activation or disable, change signer permissions, export a private key, or recover the underlying wallet. It can receive an exact authorized request and submit it through a venue client.
Your Pakt signer approves lifecycle changes. It is implemented as a recoverable wallet, but Pakt presents it as a signer because lifecycle approval is its role. Each approval binds the operation, account, environment, Pakt root, signer identity, nonce, and expiry. Activation and disable are distinct operations; a signature for one is not approval for the other. The root alone identifies rules, not an account's signing or wallet authority.
For Hyperliquid, the master wallet separately approves or revokes the execution wallet's venue-level trading permission. See Signers, Wallets, and Control.
Trust Boundaries
| Boundary | What you trust it for |
|---|---|
| Account authentication and Pakt signer | Correct identity and lifecycle approval |
| Hyperliquid master wallet | Granting and revoking venue-level agent permission |
| Authenticated data sources | Accurate account and market facts, bound to the request context and freshness checks |
| Approved Pakt and policy program | The intended rules and their correct interpretation |
| Measured Nitro verifier and protected key material | Verifying approval, program identity, proof, exact request, freshness, and runtime replay state before releasing authorization |
| Wallet provider | Protecting underlying keys, supporting recovery, and enforcing Pakt signer and restricted execution signer permissions |
| Pakt host and database | Supplying the current account-to-signer binding and lifecycle state, and retaining operation recovery records |
| Venue | Enforcing the signed request and determining fills, transaction execution, and settlement |
Agents, orchestration, and proof computation are not trusted to decide policy compliance. Their outputs are checked. A valid proof for another program, Pakt, account context, or request must not authorize the selected operation. The Pakt signer approval binds lifecycle authority to the account and environment, preventing a substituted signer from borrowing another account's execution authority.
Proof Integrity Is Not Data Privacy
The remote prover is untrusted for the correctness of its returned result: the proof is verified against the exact program and committed inputs. A prover cannot simply claim that a refused action passed.
It is nevertheless trusted for witness confidentiality and availability. The witness includes the rules and account or market evidence needed for the check. The proving service and infrastructure that handles that data can see it; verifiable computation does not imply those inputs are hidden from the prover. An unavailable prover can prevent authorization, even though it cannot forge a valid result.
Similarly, a valid signature from a data source establishes who attested the facts—not that those facts are economically correct. Incorrect but properly authenticated evidence remains a trust risk.
Current Limits
Latest lifecycle state. The current staging design trusts the host and database to disclose the latest activation or disable state. Verifying a valid activation signature does not prove that the host has disclosed a later disable. The signer binding does not independently authenticate the whole database inside the enclave.
Single authoritative enclave. Hardware attestation identifies enclave code; it does not prove uniqueness. The deployment therefore assumes exactly one authoritative enclave for each approver key. That enclave serializes requests and advances the proof-owned policy frontier before releasing authorization. Running a same-key clone violates the trust model. A restart takes longer than the maximum 30-second Hyperliquid order lifetime, while Gateway additionally binds the wallet nonce.
The hosted backend atomically retains the accepted receipt, successor policy state, exact operation, and (for Gateway) wallet nonce before provider signing. PostgreSQL supplies durability and recovery evidence; it does not decide which proof may receive an enclave authorization.
Policy scope. For Hyperliquid, account thresholds check the fresh snapshot projected with the current batch and every still-live prior risk increase. Risk- reducing legs are assumed not to fill. Per-request trade and action budgets still do not become daily or rolling limits. See Rules and Limits.
After signing. A receipt establishes authorization or refusal, not a fill or settlement. Disabling a Pakt does not revoke a signature already released. The client must reconcile uncertain outcomes with the venue before retrying.
For the end-to-end component flow, read System Architecture. For what you can check yourself, follow Verify a Receipt.