Pakt Docs
MCP Tools

propose_execution

Synchronously authorize one exact action under one active root.

FieldMeaning
Side effectsReturns a signed, refused, or recovery-required result. Venue submission remains with the client.
Next stepSubmit a signed result unchanged, stop on refusal, or follow the fault’s recovery guidance.

Arguments

ArgumentTypeRequired
intentobjectyes
pakt_rootstringyes

Exact bounds, accepted values, and nested fields are in Full JSON Schema below.

Example

selectedPakt comes from get_execution_context. The order is a complete unsigned order from your venue client. This call can lead to signing. Obtain the user’s instruction before calling it; it never submits.

With an authenticated MCP client:

await client.callTool({
  name: "propose_execution",
  arguments: {
    pakt_root: selectedPakt.pakt_root,
    intent: {
      kind: "prepared_hyperliquid_order",
      order: {
        legs: [{
          asset: 0, // BTC; from list_hyperliquid_perp_markets
          is_buy: true,
          limit_px: "100000",
          sz: "0.0001",
          reduce_only: false,
          order_type: { limit: { tif: "ioc" } },
        }],
        grouping: "na",
        nonce: Date.now(), // current Unix milliseconds
        vault_address: null,
        // expires_after_ms omitted: Pakt sets the deadline
      },
    },
  },
});

Returns

Important fields in the decoded result; this is not a complete response schema.

FieldMeaning
statusSIGNED_NOT_SUBMITTED or REFUSED_NOT_SIGNED; recovery-required is returned as a fault.
receipt_idReturned with a signed or refused result. Keep it for inspection and completion.
submission_type / submissionSigned results only: the exact venue-ready payload. Submit unchanged through the venue client.
reasonRefused results only; can be generic and need not identify the violated constraint. Do not invent a diagnosis or route around the refusal.

For error handling and retry rules, see Statuses and Errors.

Supported Requests

Set intent.kind to one of:

  • prepared_hyperliquid_order: one IOC perpetual-order batch in order; mainnet, no vault.
  • prepared_erc20_approval: finite USDT allowance and Ethereum transaction parameters in approval.
  • prepared_gateway_order: Gateway order ID and prepared Ethereum transaction in order.

For Hyperliquid, order.legs contains between one and ten legs. Each asset is the current venue index, limit_px and sz are canonical positive decimal strings, and order_type.limit.tif is "ioc". Use grouping: "na" and vault_address: null. Set nonce to the current Unix time in milliseconds; Hyperliquid rejects nonces more than two days old or one day ahead. Retries follow the single nonce rule in Statuses and Errors. Omit expires_after_ms: Pakt then sets the venue deadline to the latest instant the selected Pakt allows, counted from its own attested decision time, so the time your agent spends preparing the call does not consume the window. Submit the signed result promptly. A supplied expires_after_ms must be an absolute future Unix timestamp in milliseconds, not a duration. Spell 4470 as "4470", not "4470.0". Passing the JSON schema alone does not establish valid venue precision, current metadata, freshness, or a permitted order.

Gateway approval and order creation are separately authorized. Confirm a successful finite approval before obtaining and authorizing a fresh order plan.

On this page