FxIntent

Update log

• 7 September 2026 - First edition. Drawn from the intent and envelope specifications, the semantic context's implemented scope, the architecture programme's intent chapter, the Yellow Paper's claim family and effect algebra, and the White Paper's grammar of organs. Object names and relationships are given; field lists of planning schemas are not.

Short answer

FxIntent is the second organ and the first one a participant writes. Its promise is to declare meaning before execution. A conventional transaction is a payload the network runs to discover what it does; an FxIntent is a signed claim that states what it asks, what it will touch, what constraints bind it and when it expires - so that the protocol can judge it before anything runs.

What exists today is the canonical core of that idea: an intent is sealed locally from a canonical body. The body is encoded canonically and hashed under the intent's own domain to derive the intent's identity; sealed objects are built through one builder, and the low-level constructor that skips the identity check is reserved for primitives and tests. Conformance vectors pin sample bodies and their derived identities. Around this core sit planning and inspect-only artifacts - a versioned envelope schema, an admission-boundary projection, effect-declaration sidecars, mirror reports that expose facts without deciding anything - each documented as exactly that.

The direction elevates the intent into the general case. Every input to FxChain becomes a member of one claim family judged by one grammar; every executable claim declares its effects from one closed, versioned taxonomy; the envelope carries commitments and bounded attachments rather than a whole dossier; and replay protection becomes a scoped coordinate rather than a global lock. The White Paper's line for the organ is the refusal that defines it: no blind payloads, no hidden effects.

What is established, what is in development, what is not claimed

Where FxIntent sits

   [1] FxWire -> [2] FxIntent -> [3] FxCore -> [4] FxCell -> [5] FxDAG
                     ^                                       -> [6] FxVM
                     |                                       -> [7] FxState
   after FxWire (decoded input), before FxCore (judgment)    -> [8] FxBlock

Figure 1 - Step two of eight. FxIntent turns a decoded input into a typed claim; FxCore judges it.

The native semantic: a claim, not an order

The refoundation of the papers derives FxIntent from the axiom in one line: a transaction is a claim, not an order - constraints and effects are declared before any power to execute exists. Two native laws carry the derivation.

Claim before power makes the intent the universal input. Not only user transactions: access declarations, effect declarations, capability requests, settlement requests, assertions about external rails, solver fills and finality requests are all claims of the same family, judged by one grammar rather than by a zoo of per-organ objects.

One effect algebra makes the intent legible. Every executable claim declares its effects from a closed, versioned taxonomy - value, authority, state, time, privacy, external, risk, economic and compliance effects, each with a small set of named variants and bounds. From that declaration the protocol derives, deterministically, what capabilities the claim requires, which finality plane it belongs to, which fee dimensions apply, which denial invariants guard it, and what shape its receipt will take. An unknown or free-form effect class is refused deterministically. A construct that cannot state its effects in the algebra cannot exist in FxChain.

   a classic transaction              an FxIntent
   +-----------------------+          +-----------------------------------+
   | to                    |          | who asks, and under which          |
   | data (opaque)         |          |   constitution                     |
   | gas                   |          | what action, on what target        |
   | nonce (global)        |          | declared access . declared effects |
   +-----------------------+          | constraints . authority refs       |
   effects discovered by              | valid until . replay domain        |
   running it                         | budget . lane                      |
                                      +-----------------------------------+
                                      effects declared before it runs

Figure 2 - What the two envelopes say about themselves. The classic payload is opaque until executed; the intent is legible before it is judged.

What exists today

The local line implements the canonical core precisely and documents the rest as planning.

Sealing from a body. An intent is sealed from a canonical body. The body is canonically encoded and hashed under the intent domain to derive the intent identity - a domain-separated hash, so that the same bytes hashed as some other object can never collide with an intent. Canonical sealed-object construction goes through one builder; a low-level constructor that does not verify that the identity matches the body exists, and is reserved for primitive construction, tests and already-verified inputs. The sender is a native account identity root, not a display address.

   FxIntentBody
        |  canonical encoding
        v
   bytes  --- hash under the intent domain --->  FxIntentId
        |
        v   builder (verifies identity = hash(body))
   FxIntent (sealed)

Figure 3 - Sealing on the local line. The identity is derived, never assigned; the builder refuses an identity that does not match its body.

Decoding and normalisation, in that order. FxWire decodes canonical body bytes only; FxCore normalises and seals the decoded body into an intent after an optional expected-network check. Account validation, signature validation, nonce storage and replay protection are explicitly out of scope of this local path. The line proves canonical construction and auditability before any live behaviour exists.

A versioned envelope, as a plan. A version-one envelope exists as a planning schema for future admission. It names the things an admitted intent will carry - sender, target network, a sender-scoped lane, a lane nonce, creation and validity bounds, a fee-planning placeholder and a reserved authorisation marker - and it is not the object the local pipeline normalises. An explicit projection from the envelope to the body marks the boundary, and admission-boundary conformance vectors pin it.

Facts before rules. Effect-declaration sidecars, composed and mirror ingress reports, and an evidential-ingress surface expose deterministic, non-authoritative facts derived only from artifacts already read. The specification's own words: facts are not authority, facts are not rules, facts are not capability; facts become visible before rules become expressible. Nothing on this surface decides admission, enforces policy, executes, mutates state, orders cells or grants capability.

The direction

The intent model. The architecture programme keeps the existing intent as the starting point and deepens it without replacing it. The target separates a compact canonical body from optional evidence material. An intent will say who is asking and under which constitution, what action on what target with which parameters, which access and effects it declares, which constraints and authority references bind it, which obligation or profile it invokes, how long it is valid, in which replay domain it lives, what budget it carries and on which lane it travels. The network envelope carries commitments and bounded attachments rather than an institutional dossier; large proof bundles live in authenticated evidence services and are referenced by commitment.

The claim family. The Yellow Paper's formal objects list eight claims judged by one grammar.

   IntentClaim      user-facing semantic intent (FxIntent)
   AccessClaim      declared reads, writes and namespaces
   EffectClaim      the declared effect set
   CapabilityClaim  a request to hold or exercise a capability
   SettlementClaim  a request that a value movement become final
   RailClaim        an assertion about an external financial rail
   SolverClaim      a proposed fill for an open intent
   FinalityClaim    a request for a plane assignment
   -------------------------------------------------------------
   one judgment grammar; one verdict order; one denial model

Figure 4 - The claim family. FxIntent is the first member; the others share its grammar so that FxCore judges everything the same way.

The core object. In the same formal vocabulary an intent is a signed claim bundle: body, constraints, effect set, lane, expiry, constitution binding and fee ceiling. The constitution binding is what lets the next organ check an account's own rules alongside the protocol's; the fee ceiling is what lets a signature bound a consequence, not merely name an action.

The nonce mesh. Replay protection becomes a scoped claim coordinate rather than a global lock. Independent intents from one account can flow through FxWire and FxCore without a single strict nonce stream. The specification is a draft and is stated as planned.

Constitutional accounts. The organ inversion the papers call constitutional accounts turns the account into a jurisdiction: an intent is admissible only if it satisfies both the protocol constitution and the account's own - admission policy, nonce scope, session grammar, spending and denial set, recovery law - enforced by consensus rather than by wallet software. The intent carries the binding; FxCore performs the check.

The refusal that defines it

The White Paper's grammar of organs gives the refusal in three words: blind payloads; hidden effects. An FxIntent refuses four things.

• Open-ended power. A claim that does not bound what it may cause has no place in the algebra and is refused before it is judged.
• Missing constraints. Validity, replay domain and budget are not optional metadata; a claim without them cannot be scoped, so it cannot be admitted.
• Expired instructions. An intent past its validity is refused deterministically, by every node in the same way.
• Unauditable meaning. A claim whose effects cannot be stated in the closed taxonomy cannot be audited before execution, and so cannot exist.

What FxIntent does not do

• It does not execute anything. It declares; FxCore judges; FxVM executes.
• On the local line it does not validate accounts or signatures, store nonces or protect against replay. These are stated out of scope and are not claimed.
• Its envelope schema is a plan. The object the local pipeline normalises is the canonical body.
• Its inspect-only surfaces expose facts. They admit nothing, enforce nothing and grant nothing.
• No intent is submitted to any network; there is none.

Verdict

FxIntent is the organ where FxChain's first law becomes a data structure. What is implemented is the canonical core - a body, a derived identity under its own hash domain, and one builder that refuses a mismatch - proven by vectors and surrounded by planning surfaces that say plainly what they are. What is designed is the general case: one claim family, one closed algebra of effects, an envelope that carries commitments rather than dossiers, and an account that is a jurisdiction. The distance between the two is stated line by line above, and none of it is hidden behind the word "transaction".

Frequently asked questions

Is an FxIntent a smart-contract call?

No. A call is executed to discover its effects. An intent declares its effects, its constraints and its expiry before it is judged, so that refusal can be principled. Contracts, in the direction, are actors with linear resources and declared effects - and even their calls are claims.

What is a domain-separated hash, and why does it matter here?

A hash computed under a label specific to the kind of object being hashed. The same bytes hashed as an intent and as something else produce different identities, so an intent cannot be mistaken for, or substituted by, another kind of object with the same content.

Does the effect taxonomy exist today?

As a design in the Yellow Paper, and as continuity with an effect-declaration surface that is already sealed on the local line. The general algebra - nine classes, closed and versioned - is research, and the table above says so.

What happens to an intent with an undeclared effect?

In the direction, a cell whose execution touches an undeclared resource is aborted deterministically and its receipt records the observed access, so that the claimant can resubmit with a widened, correct declaration. The declaration is the contract; the abort receipt is the evidence.

Where do a wallet's rules come in?

Through the constitution binding. In the direction, an intent is admissible only if it satisfies both the protocol's constitution and the account's own. That check is FxCore's, and it is the subject of the next dossier.

Sources and methodology

Drawn from the intent, envelope, evidential-ingress and nonce-mesh specifications in the protocol repository, the semantic context's implemented scope, the architecture programme's intent and admission chapter, the Yellow Paper's chapters on native laws, the effect algebra and formal objects, and the White Paper's grammar of organs. Implementation claims are limited to what the specifications describe as implemented or inspect-only; design claims are attributed and carry the status research or planned.

The specifications and papers are not published on this portal and are not reproduced here; field lists of planning schemas are described, not enumerated. Figures shown anywhere on this portal come from a single dated snapshot; none are introduced by this dossier.

Related reading: FxWire, the organ before; FxCore, the organ after; Technology for the full sequence.