ORCHES RESEARCHWP-001REV 1.0OPEN RESEARCH

Executable Intent

Coordinating agent demand, provider selection, and request-level settlement

What an agent decides and what a network will execute are separated by a layer nobody has specified. This note specifies it.

Abstract

Compute scales. Reasoning scales. The coordination layer that would turn either one into an executable financial workflow does not exist yet. This note specifies it.

Two prior readings converge on it from opposite ends. Oxford Sustainable Finance Group treats payments as the floor rather than the ceiling, and puts capital, credit, insurance, risk management, identity, and legal accountability above it. Fabric Ventures names the same territory a machine economy, thrown up by accelerated compute, reasoning models, and programmable settlement arriving together.

  • [1] Oxford Sustainable Finance Group
  • [3] Richard Muirhead, Fabric Ventures

Today an agent plans, calls tools, and drives a workflow end to end. What it cannot do is select a provider, price the call, spend against a budget, settle at the level of the request, and carry a verifiable outcome forward as reputation. No standard covers that path.

The architecture proposed here is deliberately unglamorous. It grants no open-ended access to capital. It specifies bounded economic agency: permissions cut narrow, service terms published as data, settlement priced per request, receipts that can be checked, and risk logic sitting inside the transaction path instead of in a policy document beside it.

When Reasoning Starts Spending

The interesting threshold is not model quality. It is the point where a system stops emitting information and starts committing resources.

An assistant answers. An economic agent buys market data, rents compute, ranks providers, farms work out to other agents, settles terms, fires a transaction, watches what comes back, and moves the money again.

That difference is structural, not cosmetic. Anything that spends, picks counterparties, and signs transactions is already an economic actor, whatever the law says about where liability lands.

Oxford frames the consequence as a financing problem, and the historical pattern is consistent. Industry needed equity and credit. Consumer markets needed card rails and scoring. Derivatives needed collateral, margin, clearing, and reporting. Every expansion of economic activity has arrived with its own supporting machinery, and agent-mediated activity will be no exception.

  • [1] Oxford Sustainable Finance Group

Skip that step and one of two things happens. Agents stay penned inside human accounts and subscriptions, or the activity routes around the gap through unsupervised delegation, informal credit, pooled funds nobody has mapped, and risk transfer nobody priced. The second route is quicker and far harder to see into.

A Rail Is Not a Market

Hold the two apart. A payment discharges an obligation that already exists. Finance does the rest of the work: shifting value across time, pricing risk, rationing capital, supplying liquidity, absorbing uncertainty, transforming maturities, and underwriting what goes wrong.

Fractions of a dollar for a data call are a payments problem. Borrowing into an opportunity, insuring against a failed fill, funding a sub-agent, or posting collateral against future performance is a finance problem.

Payments come first because a payment is narrow, deterministic, and auditable the moment it lands. Credit is not, and the unresolved parts are concrete.

  1. Who is the borrower?
  2. Which principal is ultimately liable?
  3. Can an agent enter an enforceable obligation?
  4. How is its creditworthiness measured?
  5. Does reputation earned by one software version transfer to the next?
  6. What happens when borrowed capital is recursively delegated?
  7. How are correlated failures across agents built on similar models stress-tested?

None of these is an API design question. They are identity, authorization, liability, prudential control, and systemic risk. Oxford is exact about the mechanism: exchange resources often enough, defer settlement, delegate recursively, and a financial relationship exists whether or not anyone set out to create one.

  • [1] Oxford Sustainable Finance Group
The target is not open-ended autonomous finance. It is bounded economic agency: room to transact, with scope, duration, counterparties, and exposure all machine-checkable and governable from outside.

The Gap Between Intent and Execution

Fabric reads the machine economy as three systems meeting. Accelerated compute supplies capacity. Models and agents supply reasoning and initiative. Programmable networks supply settlement and coordination.

  • [3] Richard Muirhead, Fabric Ventures

Drop any one and the remainder stalls. Models and compute without programmable money yield capable software still wired to human accounts and billing cycles. Chains and compute without agents yield rails with nothing autonomous demanding them. Agents and chains without compute run out of the resources to keep running.

Even complete, that trio is not yet a network. Every purchase presupposes answers: the capability exists, the price is known, the authority is held, the provider survives selection, the outcome is verifiable, and failure has a defined consequence.

Those answers are the coordination layer, and it sits between agent intent and anything a network will actually execute. What ships today covers a stage or two of the sequence below. Nothing covers the sequence.

  1. 01Intent formation
  2. 02Service discovery
  3. 03Capability and price evaluation
  4. 04Counterparty verification
  5. 05Policy checks
  6. 06Payment authorization
  7. 07Service execution
  8. 08Receipt validation
  9. 09Reputation update
Figure 1The nine stages of a complete machine-native transaction. Existing standards cover fragments. The coordination layer is what joins them.

What the Existing Standards Already Cover

Four standards each take a slice. Stacked, they sketch an architecture and leave one conspicuous hole, which is the hole Orches occupies. Clauses §4.1 to §4.4 take them in turn.

StandardLayerQuestion it answersExplicitly out of scope
MCPCapability interfaceWhat can this service do, and how is it invoked?Silent on price, settlement, provider reliability, and liability.
x402Machine-native paymentHow is the service paid for, inside one request cycle?Does not judge provider reliability, output correctness, or authority to buy.
ERC-8004Identity, reputation, validationWho provides it, what did prior counterparties observe, how is output checked?Evolving standard. An interoperability direction, not a fixed dependency.
ERC-4337Programmable authorizationWhat exact authority has the principal delegated to this agent?Enforces the envelope. Does not decide which services are worth buying.
Figure 2Separation of concerns across the agent-commerce stack. Each layer answers one question and is explicitly silent on the others.

4.1MCP: Describing the Capability

The Model Context Protocol standardizes how an AI application reaches external data, tools, and workflows. An agent inspects what a service offers and calls it in a structured form.

  • [4] Model Context Protocol

One question, answered well: how is an external capability described and invoked? Economic discovery, pricing, settlement, provider standing, guarantees, and liability all fall outside it. MCP surfaces the tool. Deciding whether buying it makes sense belongs somewhere else.

4.2x402: Settling the Request

x402 puts HTTP 402 Payment Required back to work as a payment mechanism. The server states scheme, price, network, and destination in the response. The client authorizes, replays the request carrying a payment payload, and gets settlement back inside the same request cycle.

Nothing about that shape fights an agent. No signup, no subscription talks, no API key in storage, no invoice waiting on a human. Terms publish at the moment of demand, and the wallet plus policy engine rules on the purchase.

Paid APIs, market data, simulation, inference, compliance checks, and execution all sit naturally on it. The scope stays tight by design: x402 has no opinion on whether the provider performs, whether the answer is right, or whether the buyer was entitled to buy.

4.3ERC-8004: Naming and Checking the Provider

ERC-8004 sketches three thin registries for agent economies that cross organizational lines. Identity issues a portable on-chain handle. Reputation carries feedback in and out. Validation hosts independent checks: re-execution, zero-knowledge proofs, trusted execution environments, other validator schemes.

  • [6] Ethereum Improvement Proposals

The division of labour is tidy. MCP: what the service does. x402: how it is paid. ERC-8004: who stands behind it, what previous buyers saw, and how a given output can be checked by someone else.

The standard is still moving, so treat it as a direction of travel rather than a pinned dependency. The requirements underneath outlast any particular draft: portable identity, reputation scoped to capability, validation performed independently.

4.4ERC-4337: Bounding the Authority

Handing an agent a general-purpose wallet is not a design. ERC-4337 pushes validation logic into contract code, which is what makes an account capable of judging an action before it executes.

  • [7] Ethereum Improvement Proposals

The principal writes the envelope: daily ceiling, per-call ceiling, permitted assets, approved contracts, allowed operation classes, thresholds that escalate to a human, session expiry. Autonomy stops being a switch and becomes a shape.

The safety question was never whether an agent holds a wallet. It is whether that wallet can state, enforce, and evidence the precise authority it was given.

Provider Selection Becomes the Unit of Work

The first machine-native network will not be agents drawing large unsecured loans. It will be agents selecting providers for small, sharply scoped work: market and asset data, risk scores, portfolio analysis, simulation, compliance checks, oracle validation, liquidity discovery, routing, execution protection, specialist inference, on-chain monitoring.

All of it exists already, scattered over dashboards, developer portals, subscription tiers, documentation sites, and billing threads. It was shaped for a human engineer wiring up an application meant to run for years.

Agents want the opposite. One call, one market state, inside a workflow that did not exist a minute ago. Fabric describes the wider drift the same way: durable applications giving ground to interventions assembled for a single moment.

  • [3] Richard Muirhead, Fabric Ventures
Monthly software subscriptionsIndividually priced capabilities
Permanent integrationsDynamically discovered services
Account-based billingRequest-level settlement
Static reviewsVerifiable execution history

At that point the marketplace stops being a catalogue people browse. It becomes the surface where provider selection and settlement happen in the same breath as the call.

Verifiable Outcomes, or None

Safety written in a document nobody parses is not safety. Risk logic belongs on the path itself: discovery, provider selection, authorization, settlement, and the outcome that comes back. The clauses below are normative, and MUST and SHOULD carry their RFC 2119 force.

  1. R-01

    Bounded delegation

    MUST Every agent and sub-agent runs inside declared limits on capital, counterparties, assets, actions, and time.

  2. R-02

    Verifiable provenance

    MUST An agent can resolve the origin of a datum, its generation time, the transformations applied to it, and whether it has been altered since.

  3. R-03

    Linked receipts

    MUST Request, authorization, provider response, and settlement bind into one auditable record, serving monitoring, dispute resolution, and reputation alike.

  4. R-04

    Contextual reputation

    MUST Trust signals are scoped to capability and to value at risk. A record on cheap queries certifies nothing about expensive execution.

  5. R-05

    Independent validation

    SHOULD High-value output clears simulation, a redundant provider, cryptographic attestation, or re-execution before capital moves.

  6. R-06

    Observable recursion

    MUST When an agent hires another agent, the originating principal keeps sight of the resulting chain of authority and spend.

  7. R-07

    Declared failure semantics

    MUST Freshness, confidence, assumptions, quote expiry, rollback behaviour, and known failure states ship as machine-readable fields, not as expectations.

None of this deletes risk. It turns risk into something measurable, boundable, and inspectable, which is the objective actually on offer.

Why Robinhood Chain

Robinhood Chain presents itself as a permissionless, AI-native L2 aimed at financial services and tokenized real-world assets, with trading, lending, yield, and agents transacting against tokenized assets on its stated surface.

That makes it a workable environment to study machine-native services in. Public chain infrastructure hands over properties an API marketplace has to fake: shared settlement, composable assets, deterministic contracts, programmable authorization, public receipts, wallet identity, state that crosses applications, open provider entry.

None of which retires regulation, liability, data protection, suitability, or governance. Tokenizing an asset does not make it fit for autonomous hands. What it does buy is one place where identity, payment, permission, execution, and verification speak the same standards.

ParameterMainnetTestnet
Chain ID466346630
NetworkRobinhood ChainRobinhood Chain testnet
ArchitectureArbitrum Orbit L2 settling to EthereumL2 settling to Sepolia
Gas assetETHSepolia ETH
Explorerrobinhoodchain.blockscout.comexplorer.testnet.chain.robinhood.com
Settlement assetUSDG 0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168Pending published deployment
Settlement decimals66
Table 1Deployment parameters used by the Orches reference implementation. Values verified against the network's own explorer and public chain registry.

What Orches Coordinates

The position is narrow on purpose. Before an agent can be trusted with a serious market, there has to be a dependable market for the services that inform it, fence it in, and check its work.

Orches is the coordination layer that turns agent intent into executable financial workflows on Robinhood Chain. Agents find financial APIs, MCP tools, data feeds, risk engines, and execution services; weigh structured metadata, price, performance, and trust signals; pay through x402 (§4.2); execute inside wallet policy (§4.4); take receipts they can verify; and return the outcome to reputation that travels.

No autonomous bank at the end of this, and no unbounded agent credit. Transaction-level infrastructure, on which the more ambitious constructions can later be attempted.

  1. Discovery
  2. Payment
  3. Execution
  4. Evidence
  5. Reputation
  6. Risk pricing
  7. Capital allocation
Figure 3The cumulative sequence. Each stage is a precondition for the next. None can be skipped.

Payments are the entry point, not the endpoint.

Closing Position

Intelligence on its own produces no agentic economy. Agency needs resources, counterparties, permissions, settlement, and trust. Once a system moves from advising to committing capital, what surrounds the model counts for as much as the model.

Oxford arrives from finance, Fabric from infrastructure, and both land in the same place: agents will need a financial system built on machine-readable identity, programmable constraint, settlement priced per request, reputation that ports, and execution somebody can be held to.

  • [1] Oxford Sustainable Finance Group
  • [3] Richard Muirhead, Fabric Ventures

Whether agents transact is settled. What remains open is whether the rails they transact on are legible to the people who will eventually have to supervise them, or whether the volume shows up first somewhere nobody can see.

Those rails are being laid now. Orches is one layer of them.

References

  1. [1]Oxford Sustainable Finance Group. Financing the agentic economy. https://sustainablefinance.ox.ac.uk/news/financing-the-agentic-economy/
  2. [2]Ben Caldecott. Financing the agentic economy: An emerging future for finance and the financial system. https://bencaldecott.substack.com/p/financing-the-agentic-economy
  3. [3]Richard Muirhead, Fabric Ventures. The Emergence of the Machine Economy. https://www.fabric.vc/writing/the-machine-economy
  4. [4]Model Context Protocol. What is the Model Context Protocol?. https://modelcontextprotocol.io/docs/getting-started/intro
  5. [5]x402. HTTP 402. https://docs.x402.org/core-concepts/http-402
  6. [6]Ethereum Improvement Proposals. ERC-8004: Trustless Agents. https://eips.ethereum.org/EIPS/eip-8004
  7. [7]Ethereum Improvement Proposals. ERC-4337: Account Abstraction Using Alt Mempool. https://eips.ethereum.org/EIPS/eip-4337
  8. [8]Robinhood. Robinhood Chain: Built for on-chain finance. https://robinhood.com/us/en/chain/