Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.sudont.xyz/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

An intent envelope is the small, typed contract an agent attaches to every transaction it asks Sudont to judge. It is the agent’s stated answer to the question “what outcome am I willing to accept?” — expressed as a handful of bounds rather than as prose. The Cage runs the transaction against live state, and the Judge compares the simulated reality against the envelope. If reality stays inside the envelope, the verdict trends to Allow; if reality drifts outside, the verdict is Deny with a reason code that names the violated bound. The envelope is intentionally narrow. It is not a description of the trade — that is the job of the Cortex, which extracts intent deterministically from calldata. The envelope is the acceptance criteria: the bounds the agent pre-commits to before signing.

​
What the Envelope Carries

A typical envelope expresses three classes of bound:
  • min_out — the minimum output amount the agent is willing to receive. The Cage’s simulated post-state must produce at least this much; anything less surfaces as SUDONT_SLIPPAGE_EXCEEDED or SUDONT_INSUFFICIENT_LIQUIDITY.
  • max_slippage_bps — the maximum tolerable slippage, in basis points, between the agent’s reference price and the simulated execution price. Routes that cross this ceiling are denied before egress.
  • Recipient allowlist — the explicit set of addresses the agent expects to receive value. Any simulated outflow to an address outside this set is the canonical SUDONT_UNAUTHORIZED_RECIPIENT signature — the Mythos / trojan-swap case where calldata looks routine but the state diff hides a hostile branch.
Additional fields (recipient lamport caps, max input, expected program targets) round out the envelope for SVM transfers and EVM contract calls. The full per-VM schema lives alongside the RPC request payload in the method reference.

​
Envelope vs. Constitution

The envelope and the Constitution are two layers of the same check, applied in sequence:
LayerSourceScopeFailure mode
Intent envelopeThe agent, per requestThis transaction’s acceptable outcomeReality fell outside what the agent itself signed up for.
ConstitutionThe operator, compiled at policy loadEvery transaction the fleet ever submitsReality violated a fleet-wide policy bound — slippage ceiling, recipient allowlist, program allowlist.
The Constitution is the AOT-compiled, memory-aligned ruleset that evaluates line-rate with the RPC. The envelope is the per-request narrowing on top. A transaction must satisfy both: the agent’s own acceptance bounds and the operator’s standing policy. Sudont surfaces whichever violation it hits first as the canonical reason_code. This separation is what lets the ReAct loop self-correct safely. The agent can relax its envelope on a retry — accept a worse min_out, widen the slippage band — but it cannot relax the Constitution. The operator’s bounds always dominate.

​
Why Bounds, Not Prose

The envelope is structured precisely so the Judge can dereference it without parsing strings, allocating, or walking trees. Every field maps to a pre-aligned bucket the Constitution Compiler already laid out at policy load. At verdict time the hot path performs hash-set membership for recipients and program targets, and integer comparison for the numeric bounds — the same O(1) dispatch that keeps the Cage indistinguishable from zero next to bare-metal simulation. The agent gets the same shape back on a non-Allow verdict: the violated bound is named in data.sudont.violations[].rule_id and the actionable_feedback field tells the loop which field to widen, narrow, or substitute. No prose; no ambiguity. The envelope is the only piece of agent-supplied input that touches the hot path, and it stays small for exactly that reason. For the loop semantics that consume an envelope-violation verdict, see the ReAct Error Payload reference.