Statuses and Errors

Each status describes what Pakt has completed and which effects have occurred. Read the full status name to distinguish approval, signing, and submission.

Read the Entire Status

Staged is not approved, signed is not submitted, and submitted is not settled. A proved refusal is a normal result; an infrastructure fault is not a refusal.

Authoring and Pakt Signer Approval

Status	Meaning	Authority changed?
`DRAFT_NO_SIDE_EFFECTS`	Canonical draft and review artifacts were produced	no
`BROWSER_WALLET_APPROVAL_REQUIRED`	Activation is staged for Pakt signer review in the dashboard	no
`BROWSER_WALLET_DISABLE_REQUIRED`	Terminal disable is staged for Pakt signer review in the dashboard	no
`ACCOUNT_AUTHORIZATION_LIFECYCLE`	Verified account Pakt summaries were read	no

Browser completion activates or disables the exact root. Confirm the resulting lifecycle_status with list_pakts; do not treat a staged challenge as the completed lifecycle change.

Authorization Results

Status	Proof	Wallet signature	Submitted
`SIGNED_NOT_SUBMITTED`	yes	yes	no
`REFUSED_NOT_SIGNED`	yes	no	no

Signed results include receipt_id, submission_type, and submission. Refused results include receipt_id and reason. Both are successful MCP tool results. A recovery-required fault includes the retained receipt and is an explicit do-not-retry result.

Other Successful Results

Status	Meaning
`CATALOGUE_NO_SIDE_EFFECTS`	Shipped authoring templates were listed
`HYPERLIQUID_PERP_MARKET_CATALOGUE`	Live market metadata was read; this is not account readiness or authorization
`ACCOUNT_EXECUTION_CONTEXT`	Active roots and adapters were revalidated; wallet readiness is checked on proposal
`COMPLETED`	A client-reported terminal outcome was attached to a signed receipt

get_portfolio returns independent balance sections rather than this status envelope. Inspect null, per-section errors, freshness, and completeness instead of assuming every field is available.

Refusal Versus Fault

A refusal is a normal, proved policy result returned as a successful MCP tool result. A fault is a validation, dependency, persistence, or infrastructure failure returned as an MCP error. Do not report a fault as though the Pakt evaluated and refused the action.

The refusal's reason can be generic: it does not currently guarantee the violated constraint or its numeric threshold. Preserve the reason and receipt ID; do not present a guessed constraint as the proved diagnosis.

If a fault reports that signing authorization was already released, Pakt may already have authorized a wallet signature. Do not restart the operation. Reconcile the receipt and external venue state first.

Faults and Retry Safety

MCP tool faults set isError: true. Their decoded data includes outcome: "error", kind, and message. Recovery faults additionally identify the receipt and set authorization_released: true; retain the full fault rather than discarding those fields. Transport or authentication errors can occur outside this tool envelope.

Fault or condition	Required handling
`invalid_argument`	Correct the named input against the current schema. No policy verdict was produced.
`waitlist` / `live_execution_not_enabled`	Resolve account access; reconnecting or retrying does not upgrade it.
`hyperliquid_setup_required`	Complete the browser's venue setup before proposing.
`pakt_not_active`	Re-read this account's execution context; do not substitute a different root without the user's choice.
`execution_not_integrated`	The deployment has no hosted authorization path. No proof or signature was produced; this is not a transient policy refusal.
`account_proof_in_progress`	Another operation for this account is proving or signing. This call started no additional proof or signature. Wait for the active operation to finish; retry an uncertain request exactly unchanged so durable replay returns its result, or refresh execution context before building a new proposal. Bundle related Hyperliquid trades instead of submitting them concurrently.
`authorization_pending`	Another account authorization, lifecycle approval, or replacement cooldown must finish or be reconciled before this operation can proceed. Follow the returned message rather than retrying concurrently.
`recovery_required` or `authorization_released: true`	Do not re-propose, re-sign, or generate a replacement order. Reconcile the retained receipt and venue state.
`internal`, a disconnect, or a client timeout	The outcome may be uncertain. Keep the exact request; inspect history and venue state before retrying. Absence of an authorization flag is not proof that signing never happened.

After a lost or ambiguous response, the server supports re-proposing the identical request under the same root, account, and environment so the durable backend can return the existing signed result or require recovery. Do not change the nonce, expiry, or any order field for this recovery attempt. Never use it to override a known recovery_required result or to repeat a submitted order.

An Ethereum token approval has no generic wall-clock expiry. Only consume or supersede its nonce through the appropriate wallet/venue process; do not treat a client timeout as permission to obtain another approval signature.