Propose an Action
How an owner-approved agent selects an active root, proposes one exact venue action, and handles the result.
Only an owner-approved agent should enter this workflow. Activating a Pakt does not authorize every MCP caller: agent identity and venue authority are approved separately, and the active Pakt constrains what that agent may do.
Use One Current Context and One Operation
Propose one complete venue request, poll the same operation to completion, and submit an allowed result unchanged. Pending, refusal, signature, and venue execution are different states.
1. Read the Execution Context
The agent calls get_execution_context and selects exactly one returned active
root. This response contains fully revalidated artifacts, supported venue
request formats, and applicable allowlists for the authenticated account.
Always begin from the current execution context; remembered roots, template
identifiers, and list_pakts do not establish execution readiness.
2. Construct the Exact Venue Request
The approved agent's existing venue client supplies every caller-controlled field in the complete request. Pakt validates and proof-binds that request exactly as supplied.
For Hyperliquid, the prepared form is one exact unsigned immediate-or-cancel (IOC) order. For the Ethereum BOB Gateway path, the prepared form carries the complete finite USDT approval and order plan, and each phase is proved separately.
3. Start Authorization
The agent calls propose_execution with the selected pakt_root and strict
intent. A successful start returns:
{
"status": "AUTHORIZATION_PENDING",
"operation_id": "<64 lowercase hexadecimal characters>",
"poll_after_ms": 5000,
"effects": {
"proof_created": false,
"signature_released": false,
"submitted": false
}
}Pending means the authorization job is still working; every returned effect is
still false.
4. Poll Without Restarting
Call get_execution_status for the same operation no faster than
poll_after_ms until it reaches a terminal result:
SIGNED_NOT_SUBMITTED: submit the returned typed object unchanged with the existing venue client;REFUSED_NOT_SIGNED: report the named constraint and stop; or- a fault: follow its recovery guidance without presenting it as a policy refusal.
The operation ID is bound to the authenticated account. Keep polling that same operation while proving completes.
5. Record the Observed Terminal Result
A signature proves authorization of the committed action, not venue execution.
After the submitting client verifies a filled Hyperliquid IOC or successful
Ethereum receipt, call record_execution_completion with the exact Pakt root,
signed receipt ID, and supported typed venue result.
This adds a client-reported completion annotation for dashboard display. It does not create another proof, release a signature, submit anything, or independently confirm settlement. The receipt remains the independently verifiable account of what Pakt proved and authorized.