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`	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.

Dashboard Receipt Statuses

Account dashboard, action history, Pakt detail, and receipt detail reads share the same lowercase receipt status vocabulary.

An expired receipt records the client's hyperliquid_expired_unreconciled completion: the exact signed request's submission deadline has passed, but its execution outcome is unconfirmed. It does not prove that the order never filled before the deadline. Check the venue before placing a replacement order. The dashboard shows the deadline as an expiry time, not an order ID. No-fill receipts link to the Hyperliquid account history when the account address is available; they do not imply that an order ID was recorded.

Confirmed client-reported fill, no-fill, and cancellation outcomes remain completed. A signed request without a completion report remains authorized; dashboard reads do not infer execution outcomes from the current clock. The MCP completion tool's uppercase COMPLETED result means that the annotation was recorded; it is distinct from the dashboard receipt's execution status.

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 starts with the first failed rule, or generic text when Pakt cannot match its explanation to the verified proof. For a Hyperliquid refusal from rule evaluation, later lines can list every evaluated rule result. They include committed thresholds, the authenticated snapshot, earlier still-live signed reservations and expiries, and projections with and without this order. These values describe the historical decision; they are not a live account read. The proof commits the refusal verdict, not each host diagnostic or rule result individually. Preserve the reason and receipt ID. Do not present a guessed constraint as the proved diagnosis or a correction as guaranteed approval. Dashboard lists return only the first policy-refusal line; receipt-detail reads and MCP refusal/replay results retain the complete historical reason.

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 authorization was released. For Hyperliquid, send the corrected order with a fresh nonce.
`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.
`not_found`	This account has no such record under the named root. Foreign and unknown records return the same answer; check the root and id you were given rather than retrying.
`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.

The public Hyperliquid input validator rejects noncanonical sizes and sizes not representable at the positive 1e8 fixed-point scale with an invalid_argument fault before proving or storing a receipt. Canonical sizes within that range that exceed the authenticated market's size precision, and invalid reduce-only requests that reach the binder, remain proved REFUSED_NOT_SIGNED outcomes. Their explanations are persisted with the refusal and replayed unchanged on identical requests, without a new attestation or proof. After the evaluator authenticates its inputs and its journal matches the verified refusal, the reason can include corrective host observations: market size precision, a flat or wrong-direction reduction, or an oversized aggregate close. These observations are not individually committed by the proof and are not a promise that fixing one input makes the order admissible. Binding failures happen before the freshness/expiry gates, so refresh venue state before changing the order. An oversized reduce-only aggregate must be reduced using the current market's valid size precision; the diagnostic does not supply an executable maximum. A new attempt needs a fresh nonce; exact replay is historical.

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.

Hyperliquid nonce rule. A nonce together with the order legs identifies one proposal; the deadline is not part of it. If the outcome is unknown (lost response, timeout, internal, or account_proof_in_progress), resend the same order unchanged: Pakt returns the stored result, including its original deadline, or decides it once. If the outcome is known and you want another attempt (refused, invalid_argument, or the signed order expired), use a fresh nonce, the current Unix time in milliseconds; a refused nonce returns the same refusal. After recovery_required, do not resend or replace the order until it is reconciled. Hyperliquid executes at most one action per nonce.

Hyperliquid perpetual price precision. Non-integer limit prices must have at most five significant figures and at most 6 - szDecimals fractional digits. Integer prices are exempt from the significant-figure limit. New requests with invalid price precision return invalid_argument before signing only after a verified Allow and an exact match to the selected evaluator's full journal. Every proved policy, authentication, or binding refusal takes precedence: it retains its stored reason and exact-request replay instead of being replaced by price advice. Pakt does not round or rewrite the price.

Hyperliquid minimum order value. Hyperliquid rejects an order worth less than 10 units of the market's quote asset (USDC for core perpetuals; the dex's quote asset for HIP-3 perpetuals). Hyperliquid does not document whether that value uses the limit price or a reference price, so Pakt computes each leg's value exactly as the higher of its limit price and the attested mark price, times size. A leg below 10 returns invalid_argument before signing, under the same rule as price precision: only after a verified Allow, and never in place of a proved refusal. Pakt signs one action for all legs, so one undersized leg refuses the whole order. Send a new attempt with a fresh nonce and a larger size. Reduce-only legs are exempt, so Pakt never blocks an exit from a small position; Hyperliquid does not document whether it accepts small reduce-only orders, so the venue may still reject one.

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.