Intent Systems Prototypes

Intent Systems Prototypes is a bounded record of experiments in turning a user's desired outcome into an authorized, constrained execution that another actor can coordinate and perform.

Mandates as executable constraints

A mandate represents the conditions under which a sponsor is willing to let another actor act on committed resources. It is more precise than a plain-language goal but less prescriptive than a fixed transaction path.

In the strongest retained model, the mandate binds details such as:

• the recipient and asset expected from the fill;
• an expiry that limits when the request remains valid;
• a minimum acceptable amount;
• fee-sensitive amount parameters;
• a salt used in the signed data; and
• the chain and contract context in which the authorization applies.

The mandate is attached to a resource commitment and signed as structured data. A solver can choose a route, but it cannot silently change the signed result boundary. An arbiter derives hashes from the commitment and mandate, rejects an expired or already-used claim, derives the permitted amounts, checks the fill, records the disposition, and invokes the settlement-specific directive.

This distinction is the core design idea. The mandate says what an acceptable outcome is. The solver payload says how a candidate executor proposes to reach it. Keeping those two objects separate lets routing evolve without changing the sponsor's authority.

The prototypes do not establish one final mandate schema for every use case. General mandate types, hook-specific intent types, resource-lock data, and limit-order conditions coexist. The useful result is the boundary they reveal, not a claim that all of those models have converged.

Authority and constraint boundaries

Intent execution distributes responsibility across actors and contracts. The retained work explored the following boundaries:

1. Sponsor authority. The resource owner or sponsor authorizes a commitment and its conditions. A solver's ability to propose calls does not give it unrestricted control of the sponsor's assets.
2. Allocator authorization. An allocator protects the integrity of a resource lock and helps prevent the same committed balance from being promised more than once. The retained allocator path is incomplete, so this remains a design and prototype boundary.
3. Arbiter judgment. An arbiter checks mandate expiry, hashes, disposition, amount rules, and fill conditions before processing a claim. The base directive-processing extension point is not a complete settlement implementation.
4. Solver discretion. A solver chooses and encodes an execution path within the mandate. That freedom is security-sensitive: targets, calldata, value, token flow, and failure behavior must be constrained by the caller and settlement context.
5. Protocol entrypoint. Hook callbacks, limit-order interactions, and destination-settler adapters each impose their own caller and state assumptions. Passing one local test does not validate all entrypoints.
6. Resource custody. Resource locks and maker-authorized funds can make assets available to a valid execution path. They do not remove infrastructure, RPC, operating, or transaction-gas costs, and they do not by themselves prove correct settlement.

Replay protection appears in more than one place: signed nonces, derived claim hashes, recorded fill or cancellation dispositions, and hook storage. The layers are not interchangeable. A system must define which state is authoritative, when it becomes final, how it is cleared, and what happens after partial failure.

Intent lifecycle

The experiments support a partial lifecycle:

express outcome and constraints
  -> commit or authorize resources
  -> expose the request to an executor
  -> find and simulate a route
  -> submit a bounded execution payload
  -> verify authority, time, replay, and amounts
  -> execute atomically or revert
  -> transfer or claim the result
  -> record disposition and reconcile

Several stages have concrete source:

• structured intent, mandate, compact, claim, call, and swap types;
• signed commitment and allocator-signature surfaces;
• arbiter fill, cancellation, quotation, hash derivation, and disposition logic;
• a hook path that stores a delayed swap request and accepts a solver payload;
• flash and multi-protocol routing experiments;
• limit-order interactions with oracle-calculated conditions and resource handling; and
• local Solidity tests around selected contracts and flows.

Other stages are deliberately incomplete. The general intent manager and solver abstraction contain placeholder behavior. The hook's create and solve paths exist, while later execute, sweep, cleanup, and recovery behavior is unfinished. The destination adapter delegates into arbiter logic but does not complete every settlement directive. Solver discovery, auctioning, reputation, and off-chain coordination are not implemented as a coherent network.

That mixed state matters editorially. The prototypes show how lifecycle pieces can meet at explicit boundaries. They do not show a completed end-to-end service in which every request can be discovered, authorized, executed, settled, recovered, and reconciled.

Coordination and execution responsibilities

The coordinator and executor answer different questions.

A coordinator determines whether a request is eligible to proceed: is the authorization valid, are the resources committed, is the request still live, has it already been consumed, and which actor may attempt it? Depending on the design, those responsibilities may be split among an allocator, arbiter, relayer, hook, order protocol, or off-chain service.

An executor determines how to satisfy the request: which venues to use, which calls to make, in what order, and whether the simulated result remains inside the mandate. The executor must then submit a payload through an entrypoint that can enforce the relevant authority and settlement invariants.

The prototypes tested both sides without resolving them into one production topology:

• arbiter logic made expiry, claim identity, disposition, amount derivation, and fill transfer explicit;
• resource-lock work explored how committed assets and allocator authorization could support a claim;
• delayed-hook work explored storing an intent during a swap callback and allowing a later solver path;
• flash-routing work explored an execution backend spanning protocol-specific callbacks;
• limit-order work explored maker-authorized assets, post-interactions, oracle conditions, and a swap executor; and
• adapter work explored a standard destination-settler entrypoint.

Atomic reversion is helpful but not sufficient. A failed call can roll back on-chain state while still consuming RPC, infrastructure, and gas expenditure. A successful local transaction can still leave unanswered questions about off-chain request delivery, conflicting executors, monitoring, recovery, finality, and operational ownership.

Prototype scope

The retained public history supports a direct, commit-scoped account of John's work on the prototype repositories. It includes Solidity design and implementation across arbiter mechanics, mandate and intent types, hook experiments, routing integrations, resource management, limit-order interactions, and tests. The commits and source trees provide stronger evidence than roadmap prose alone, but the work remains mixed in maturity.

What the prototypes establish:

• mandates can bind outcome constraints separately from solver-selected calls;
• commitment, authorization, arbitration, and execution are distinct trust boundaries;
• claim hashes and dispositions can make replay state explicit;
• hook and order-protocol entrypoints can carry intent-specific execution data;
• locked or maker-authorized resources can be made available to a bounded atomic flow; and
• partial implementations reveal concrete settlement, recovery, and coordination gaps.

What they do not establish:

• one canonical intent model across the experiments;
• a deployed solver marketplace or reliable discovery network;
• completed allocator, directive, hook cleanup, fallback, and recovery behavior;
• end-to-end cross-chain settlement and finality;
• validated protection against arbitrary or malicious solver payloads;
• current production deployment, independent security audit, customer use, commercial validation, sustained volume, or profitable operation.

No new build, live deployment, fork test, or benchmark was run for this editorial rewrite. Technical statements are limited to the retained committed sources and the existing source review.

Experimental limitations

• The codebase combines active mechanics, placeholders, disabled tests, demonstrations, and future-work notes. Their presence in one repository does not give them equal maturity.
• General intent and hook-specific intent models overlap and have not been shown to form one canonical lifecycle.
• Base settlement directive handling is incomplete; an adapter or arbiter entrypoint is not a complete settlement proof.
• Solver payloads are powerful and security-sensitive. Final authorization of call targets, calldata, value, token custody, and recipient behavior remains unresolved.
• Hook execute, sweep, cleanup, fallback, and recovery paths are unfinished in the retained evidence.
• The allocator path and some signature/domain behavior remain prototype-grade.
• Flash and external execution integrations have incomplete or disabled validation in the retained snapshot.
• Off-chain discovery, auctioning, reputation, conflict resolution, monitoring, incident recovery, and reconciliation are not evidenced as one operated system.
• Third-party protocols and libraries retain their own licenses, assumptions, audits, and risks; none transfer a maturity guarantee to this work.
• No production, customer, partner, audit, revenue, profitability, or security-outcome claim is made.

Related research and architecture

• Read Intent-Based Execution for the evidence question behind authority, solver participation, and execution.
• Read Intent Execution Boundaries for the reusable lifecycle, trust, and failure model.

Those pages answer different reader questions. Research evaluates what the evidence supports. Architecture describes reusable boundaries. This Work page remains the account of what the prototypes actually explored.