Pakt Technical Documentation
How Pakt turns human-approved constraints into proof-gated authority for an approved agent.
A Pakt is a typed list of machine-checkable constraints for an agent. The owner approves the exact constraints and the agent that may use them. For every request, Pakt checks the proposed action against those constraints before a wallet signs it.
Every Signature Is Policy-Gated
An approved agent receives a signed request only when its exact action satisfies the exact Pakt the owner approved. A refusal returns a receipt and no wallet signature.
Terms Used Throughout These Docs
- A Pakt artifact contains the typed constraints.
- A Pakt root is the cryptographic hash that identifies one exact artifact. Changing any constraint creates a different root.
- Authenticated state is signed account or market data that Pakt verifies before using it in a decision.
- A receipt records the action, proof, and result so another verifier can check them later.
The MCP client is the software connection to Pakt. The approved agent is the actor using that connection to propose actions. The agent can receive a signed request, but it never receives a wallet private key. The wallet provider holds that execution key and signs only after Pakt authorizes the exact payload.
What the Owner Approves
- Approve the agent. The owner chooses which agent may act for the account. An arbitrary MCP client cannot nominate itself or switch the account, wallet, or approved identity.
- Approve the Pakt. The owner generates or imports a Pakt, reviews both its ALLOWED and NOT ALLOWED faces, and approves the exact committed root.
Both approvals are required. Approving an agent does not let it change or bypass the Pakt. Approving a Pakt does not let an unapproved agent use it.
The owner-approved action agent may then propose actions. It cannot approve its own identity, change the active root, provide trusted account state, or bypass a proved refusal.
What Happens to One Action
Propose
The approved agent selects one active root and sends one complete venue
action through propose_execution. Pakt validates the action exactly as the
agent supplied it.
Prove and Authorize
Pakt obtains authenticated venue evidence, evaluates the committed constraints, produces a proof, and re-checks the proof and payload at the secure approval boundary.
Sign or Refuse
An allowed action receives a wallet signature and returns to the MCP client for unchanged submission. A refusal receives no signature. Both paths produce a receipt.
Verify
The dashboard runs Pakt's Rust verifier as WebAssembly in the browser. It checks the receipt against pinned trust anchors instead of trusting a server badge.
Read the Technical Documentation
The Pakt Artifact
Read a complete Hyperliquid Pakt in Rust and follow it from constraints to a committed root.
Keys and Authority
See which keys the owner, secure boundary, wallet provider, and state services hold.
Authorization Pipeline
Follow an approved agent's exact request through proof, refusal, or signature release.
Use Pakt Through MCP
Draft, review, activate, authorize, and verify from an MCP client's perspective.
MCP Reference
Browse every hosted tool, schema, status, and execution surface.
Product Setup Lives on the Product
Passkey enrollment, wallet connection, and owner approval are browser ceremonies. Continue to Get started when you need to perform them; the technical docs do not duplicate that flow.