Routon Protocol

1.  Background and Motivation

1.1  The agentic-AI moment

The state of the art in large language models in 2026 makes autonomous AI agents not just possible but credibly economic. Frameworks such as ElizaOS, Coinbase AgentKit and the Model Context Protocol (MCP) ecosystem let any developer assemble an agent that plans, reasons and acts over hours of continuous operation. The agentic-AI market is forecast to compound at over 40% annually through 2034. The number of agents in production rises every month. The number of dollars they manage on behalf of users rises with it.

1.2  Why DeFi is the natural first market for agents

Most markets cannot be operated by software alone. They include legal, regulatory, physical, or social steps that require a human in the loop. On-chain capital markets are the rare exception. Settlement is deterministic and instant. Positions are tokenised primitives. Risk and yield are public on-chain data. There is no clearinghouse, no FX desk, no broker. The full loop of discovery, decision, execution, attribution and rebalancing fits inside a single transaction graph.

DeFi is therefore the natural first market for autonomous agents — and the test case for whether AI can operate capital responsibly when the underlying surface is fully programmable.

1.3  Four structural gaps that block AI agents from DeFi

Today, however, every team building an agent that touches on-chain yield faces the same four gaps. Each is a coordination problem that no individual protocol can solve in isolation.

• No uniform execution primitive. Wiring directly to lending, DEX, AMM and structured-yield protocols costs every agent team weeks of integration work per protocol per chain. The plumbing is rebuilt from scratch by every team.
• No on-chain distribution layer. There is no standard mechanism for one agent to earn on-chain from flow it routes to another. Distribution networks compound when participants are paid; without settlement, growth has no compounding loop.
• Risk lives in closed quarterly PDFs. Specialist risk firms produce parameter recommendations for major protocols on a quarterly human cadence. An autonomous agent cannot consume that programmatically.
• Smart-account incumbents custody. Existing “DeFi for everyone” platforms hold user funds in protocol-owned smart accounts. The April 2026 Brahma console shutdown left over one hundred thousand smart accounts without a non-custodial migration path. The demand exists; the credible non-custodial alternative does not.

1.4  Why now

Three enabling shifts in the twelve months leading up to this whitepaper make the layer described here possible for the first time:

• ERC-8004 (January 2026). The Ethereum standard for autonomous-agent identity and reputation went live, making on-chain agent-to-agent settlement possible without off-chain trust assumptions.
• MCP as the universal assistant interface. Claude, GPT and every serious agent framework now speak MCP. Exposing Routon as an MCP server means every MCP-enabled assistant can call it without writing a line of integration code.
• x402 micropayments. The HTTP-native 402-Payment-Required specification has matured into a usable charging primitive for API calls priced in stablecoins. It removes API-key friction from agent consumption of the network.

2.  Design Principles

Five principles fix the shape of every later design decision in the protocol. Each is binding; conflicts between a proposed feature and any of them are resolved against the feature, not the principle.

2.1  Non-custodial by architecture

Routon contracts never take ownership of user principal. This is not a policy or a best practice; it is an architectural property, enforced by a Foundry invariant test executed on every continuous-integration build with ten thousand or more fuzz iterations per invariant per run. If the invariant ever fails for any path, the build fails. See Section 5 for the formal statement.

2.2  Agents are the primary client

Every API surface is designed for autonomous large-language-model consumption first, and human ergonomics second. Response shapes are predictable and self-describing. Errors carry structured codes and trace identifiers. Cost is metered in stable, machine-readable units (USDC base units, basis points, seconds). Documentation is dense and scenario-driven, not narrative.

2.3  Composition over wrapping

Routon does not fork or wrap Aave, Morpho, Uniswap, CoW Protocol, or any other established primitive. It composes them through allow-listed delegatecall, with the underlying audited contracts performing the actual asset custody and accounting. This concentrates audit budget on a small surface (six core contracts) and inherits the security posture of the external venues for everything else.

2.4  Open standards as the integration surface

The Routon Standard is published as a CC0 open RFC (Section 3). Agent identity uses ERC-8004 (Section 6). Attestation signatures use EIP-712. Cross-chain intents use ERC-7683 (Across). MCP exposes tools to assistants. The integration surface is fully described by published specifications; nothing important to interoperability is proprietary.

2.5  Stateless off-chain layer

The agent-brain service that performs discovery, risk scoring, simulation and execution routing is stateless across requests. Authoritative state lives on-chain. Off-chain storage is a cache and a dashboard layer only; nothing that the user has not already signed for can be changed by an off-chain failure.

3.  The Routon Standard

The Routon Standard is the open machine-readable JSON format describing any DeFi yield opportunity. It is designed so that a single agent, given only Routon-conformant objects, can discover, score and act on every supported strategy with no protocol-specific code.

3.1  Goals and non-goals

• Goal. One JSON object describes a yield opportunity exhaustively enough for an agent to reason about it: identity, routing, yield expectation, risk attestation, execution calldata, slippage curve, audit history and composability.
• Goal. Be the OpenAPI of DeFi yields: stable, semantically versioned, language-neutral, lossless.
• Goal. License-free. CC0 is the canonical choice for an open data format that needs to be adopted by parties that include the protocol’s own competitors.
• Non-goal. The standard does not prescribe how a strategy is executed (that is the implementation layer). It does not prescribe how risk is scored (the schema carries factors and references, not the algorithm). It is not a marketing format.

3.2  Schema overview

A conforming object carries five logical sections: identity, routing, yield, risk, and execution. The TypeScript shape is reproduced below in abbreviated form; the full schema is published in the project repository and tracked as an RFC under semantic versioning.

interface RoutonStrategy {
  id: string;            // keccak256(chain, protocol, asset, version)
  chain: ChainId;        // EIP-155 chain ID
  protocol: string;      // 'aave-v3' | 'morpho-blue' | 'uniswap-v4' | …
  asset: Address;
  expectedApy: { base, rewards, total, confidence };
  risk: { score, attestedAt, attestor, attestationStake, factors };
  execution: { entryCalldata, exitCalldata, gasEstimate, slippageCurve };
  withdrawalDelay: number; audits: AuditRef[]; composable: boolean;
}

3.3  Conformance

An implementation is Routon-Standard conformant if it publishes RoutonStrategy objects matching the schema; includes all required fields; uses checksummed addresses; expresses token amounts in base units rather than human-readable decimals; and refreshes the risk attestation no less frequently than every hour for actively-routed strategies.

3.4  Licensing rationale

The schema is licensed CC0 1.0 Universal — placed in the public domain. Adoption of a data format that needs to be implemented by competing protocols cannot tolerate licensing friction. The format itself is not where Routon captures value; value is captured at the execution router, the risk-attestation layer, and the agent-to-agent attribution flow, all of which remain proprietary in the reference implementation.

3.5  RFC submission

The schema will be submitted as a draft ERC to the Ethereum Magicians forum and the ethereum/EIPs repository for public review. A 30-day RFC window precedes any normative changes to the schema.

4.  Architecture

The system is organised into six layers. The client layer originates intents. The distribution layer formats them and meters x402. The edge layer enforces the HTTP boundary. The brain layer performs off-chain intelligence. The data layer caches and indexes. The smart-contract layer is the on-chain authority, and the external layer is where user funds actually live.

4.1  Layer responsibilities

• Client. Originates intents — ElizaOS plugins, Claude or GPT integrations, Coinbase AgentKit agents, custom code.
• Distribution. TypeScript SDK, Python SDK, MCP server with x402, command-line tool. Stateless; format-converts intents; charges per call.
• Edge. FastAPI HTTP boundary running on managed infrastructure. Authentication, rate limiting, OpenTelemetry tracing.
• Brain. Off-chain intelligence with four engines: strategy discoverer, risk scorer, composition engine, execution router. Stateless across requests.
• Data. Cache for dashboard, indexed reads via Envio HyperSync and Goldsky subgraphs, Pyth Network and Chainlink Data Streams for price feeds.
• Smart contracts. Six core contracts deployed identically on each EVM chain; equivalent Anchor program on Solana; equivalent Move package on SUI. Section 4.2 below.
• External. Aave, Morpho, Uniswap V4, CoW Protocol, Across, Pendle, and other audited DeFi venues — accessed through allow-listed delegatecall.

4.2  Smart contract inventory

The on-chain core consists of six Solidity contracts deployed identically to each EVM chain in the supported set, with chain-specific allow-list entries for external primitives. Equivalent programs exist as a single Anchor program for Solana and a Move package for SUI.

PrimitiveExecutor is the single most security-critical contract: it is the only one that delegatecalls into externals. The non-custodial invariant (Section 5) must hold here under all paths.

4.3  Funds flow

User funds never touch a Routon-controlled balance. The PrimitiveExecutor delegatecalls into the chosen external primitive, which executes in the user’s address-space context — meaning the underlying tokens belong to the user wallet throughout, and the user is the depositor of record at the external venue.

User wallet  ——(signs)——›  PrimitiveExecutor  ——(delegatecall)——›  External venue

The external venue sees msg.sender = PrimitiveExecutor, but the underlying tokens remain owned by the user. Routon never takes ownership; it only orchestrates the call. Withdrawal follows the same path in reverse; the user is always the asset owner.

4.4  Off-chain brain

The agent-brain is a stateless Python service exposing four engines:

• Strategy Discoverer. Continuously discovers and registers Routon-conformant strategies across the supported chains. Lives at the boundary between curated venue lists and on-chain primitives.
• Risk Scorer. Runs an 8-factor risk model against each discovered strategy on a 30-minute cadence: oracle health, TVL stability, audit recency, slippage shape, liquidation history, protocol governance footprint, asset correlation, and circuit-breaker state.
• Composition Engine. Assembles multi-step strategies from registered primitives to satisfy higher-order intents — e.g. lend-leverage-loop, basis trades, structured yield positions.
• Execution Router. Encodes the optimal calldata payload for a given intent, including venue choice for swaps, gas estimation, and order splitting for slippage minimisation.

4.5  Distribution layer

Three primary surfaces deliver Routon to agents:

• SDKs. @routon/sdk (npm, TypeScript) and routon-sdk (PyPI, Python) — both shipped via OpenID Connect trusted-publisher flows. Both expose the same primitive set.
• MCP server. Hosted at mcp.routon.xyz. Tools include find_best_yield, simulate_deposit, build_deposit_calldata, build_withdraw_calldata, get_positions. Charges per call via x402.
• Command-line tool. routon CLI for scriptable agent operations and quickstart workflows.

5.  The Non-Custodial Invariant

Non-custodial operation is the single most important security property Routon guarantees. The protocol’s contracts must never, at any point in any execution path, hold user principal. This section states the invariant formally and describes how it is enforced.

5.1  Formal statement

INV-1 (Non-custodial). For every external function entry to and exit from the PrimitiveExecutor contract, and for every storage write performed during execution, the ERC-20 balance of the PrimitiveExecutor address for every token in the global allow-list shall be zero.

Formally: ∀ t ∈ AllowedTokens . IERC20(t).balanceOf(PrimitiveExecutor) == 0 must hold at every observable state transition.

5.2  How the invariant is enforced

The invariant is enforced architecturally rather than operationally. Three mechanisms compose:

• Delegatecall, not call. PrimitiveExecutor delegatecalls into external primitives. The external code executes in PrimitiveExecutor’s address-space, but the underlying token balances and approvals belong to the user’s externally-owned account. Routon never receives custody.
• Foundry invariant fuzz. A dedicated invariant test handler in test/invariant/NonCustodial.t.sol executes ten thousand or more fuzz iterations per continuous-integration build, asserting INV-1 after every randomly-generated state transition.
• Audit scope inclusion. The competitive audit engagement specifies INV-1 as in-scope. Any path that violates the invariant is a finding regardless of severity rating.

5.3  Why architectural enforcement matters

A protocol that operates non-custodially as a matter of policy — by promising to forward funds, by promising not to retain — is not the same as a protocol that cannot custody by construction. The first can be compromised by a single privileged signer, a bug in a privileged code path, or an upgrade that introduces a custody-enabling code path. The second cannot. INV-1 makes Routon the second kind.

5.4  Adjacent invariants

Five additional invariants are maintained alongside INV-1, addressing the surface around it:

Each invariant has a dedicated Foundry handler exercising it independently. Severity ratings reflect the loss class on violation: Critical implies potential principal loss; High implies risk-decision corruption; Medium implies financial-loss accrual outside principal; Low implies display or auxiliary corruption only.

6.  Agent Identity and Attribution

Routon’s distribution layer assumes that any agent which routes flow should be paid for that flow, on-chain, automatically, in proportion to the value it generates. This requires three primitives: agent identity, attribution at execution time, and settlement at harvest time. Each is implemented against an open standard.

6.1  ERC-8004 — the agent identity standard

ERC-8004 went live in January 2026 as the canonical Ethereum standard for autonomous-agent identity and reputation. Each agent is identified by an ERC-8004 token ID, controlled by the agent’s signer. The standard defines an identity registry, a reputation registry, and a validation registry deployed on supported chains.

Routon’s contracts integrate with the canonical ERC-8004 registries: builder codes are bound to an ERC-8004 identity at registration time, and rebate payouts route to the payout address controlled by the identity owner. The protocol itself owns an ERC-8004 identity, used to post and sign its own risk attestations.

6.2  Builder codes

A builder code is a short on-chain identifier bound to an ERC-8004 identity and a payout address. When an agent constructs an intent through Routon’s SDK or MCP server, the builder code is included in the signed calldata that the user wallet authorises. The PrimitiveExecutor records this attribution to the BuilderCodeVault on every successful execution.

BuilderCodeVault.registerBuilderCode(
  bytes32 code,
  address payoutAddress,
  uint256 erc8004IdentityId
)

Registration is permissionless. The caller must control the ERC-8004 identity (proven by signature) and may change the payout address only after a timelock. Codes are unique per chain.

6.3  Rebate settlement

On every harvest of a Routon-routed strategy, the FeeCollector collects ten percent of the yield accrued since the last harvest. Forty percent of that performance fee is paid on-chain to the builder code attributed to the routed flow; sixty percent is paid to the treasury. Both transfers are in USDC; reward tokens generated by the underlying primitive are auto-swapped to USDC through CoW Protocol where available.

Settlement emits a RebatePaid event with a trace identifier correlating to the execution that earned the rebate. Agents can subscribe to the event stream for their builder code to track revenue accrual.

6.4  Reputation graph

ReputationOracle aggregates per-agent activity into a numeric score, derived from attestations posted by allow-listed attestors and from on-chain history of executed flow. The score is read-only externally, but is consumed by Routon’s own free-tier rate limiter, allowing higher free-tier limits for agents that demonstrate reliable on-chain history. Reputation is a public good — protocols and users can read it to inform their own routing decisions.

7.  Risk Attestation

Risk in DeFi is conventionally communicated through closed quarterly PDFs produced by specialist firms. An autonomous AI agent cannot consume such a document. Routon’s risk layer reformulates the same function as a live, on-chain, programmatically-readable feed.

7.1  The attestation cycle

For every active strategy, an attestor — initially Routon’s own agent-brain — computes a risk score on a 30-minute cadence, signs the computation with an EIP-712 attestation under its ERC-8004 identity, and posts the attestation to ValidationRegistry. The registry verifies the signature against the attestor’s identity, checks attestor stake, and stores the latest attestation per strategy.

ValidationRegistry.postAttestation(
  bytes32 strategyId,
  uint16  score,       // 0-100, lower is safer
  bytes32 factorsHash, // JCS-canonicalised factor vector hash
  bytes   signature    // EIP-712, ERC-8004-bound
)

Posting requires attestorStake[msg.sender] >= MIN_STAKE. An attestation that loses a challenge slashes the attestor’s stake; challenges require a posted bond.

7.2  Risk factors

Each posted attestation includes a canonicalised vector of factor inputs (hashed using JCS, RFC 8785), allowing third parties to reproduce the score. The factor set is intentionally small and interpretable:

• Oracle health. Pyth/Chainlink agreement, last-update recency, deviation from time-weighted reference.
• TVL stability. 30-day standard deviation of routed and total TVL.
• Audit recency. Days since the last published audit covering the relevant primitive.
• Slippage shape. Slope of the slippage curve at relevant fill sizes for the strategy.
• Liquidation history. Recent on-chain liquidation events for the underlying market.
• Governance footprint. Outstanding governance proposals that could materially change strategy parameters.
• Asset correlation. Cross-asset correlation in the strategy’s underlying basket relative to the chain’s stablecoin or quote asset.
• Circuit-breaker state. Whether the strategy or its primitives are currently in a guarded state on-chain.

7.3  Auto-execute on parameter breach

Where authorised by a client (treasury, protocol, sophisticated deployer), an attestation that crosses a pre-agreed threshold can trigger an automatic rebalance through the PrimitiveExecutor along a path that the client has pre-approved. The client signs the rebalance policy in advance; the auto-execution remains constrained to those pre-approved paths. This is the operational point of departure from the human-paced incumbent risk model.

7.4  Challenge and slashing

Any party may challenge an attestation by posting a bond and submitting evidence to ValidationRegistry. The challenge process executes off-chain through governance, with the verdict written back on-chain. Losing a challenge slashes the attestor’s stake to the challenger; successful defence returns the bond and a small fee. The mechanism is the same as third-party economic-security primitives such as EigenLayer.

8.  Multi-Chain Execution

Routon targets eight chains. The EVM chains share a single Solidity implementation; SUI and Solana each have a dedicated implementation in their native runtime. The execution API exposed to agents is the same across all eight: one method, eight destinations.

8.1  The chain set

8.2  Per-runtime implementation

The EVM implementation is byte-identical across all six EVM chains; the Solidity sources compile once and deploy with chain-specific configuration files for allow-listed external addresses. The Solana implementation is a single Anchor program with the same logical contract set, adapted to Solana’s account model and compute-unit constraints. The SUI implementation is a Move package with typed compiled-in venue adapters and a 24-hour governance timelock on venue enable.

8.3  Cross-chain execution

Each chain’s execution is independent: the user signs a transaction on the chain where the strategy lives. Cross-chain bundling is delivered through ERC-7683 intents (Across canonical) as an opt-in feature in subsequent releases. The Routon Standard schema is transport-neutral; cross-chain intents reuse the same RoutonStrategy objects with a destination override.

8.4  Adding a new chain

Adding a new chain to the network is a contract-deployment and audit task, not a protocol-redesign task. The reference implementation ships per-chain configuration as a small JSON file declaring the chain ID, the allow-list of external primitives, and the chain-specific attestor address. New chains beyond the initial set — Aptos, Sei, Monad, Hyperliquid, others depending on TVL and demand — are evaluated on a quarterly cadence post-mainnet.

9.  Autonomous Strategy Generation

Most strategies on a yield aggregator today are hand-curated: a human writes the integration code, registers the strategy, and updates parameters by hand. Routon’s brain layer closes that loop: the system discovers candidate strategies from live on-chain data, simulates them, risk-scores them, and registers the ones that pass automatically.

9.1  The pipeline

• Discoverer. Consumes a curated venue list, queries DeFiLlama for current TVL, APY and stability metrics across the supported chains, and emits candidate RoutonStrategy objects.
• Simulator. Runs each candidate against a recent mainnet-fork to estimate gas, slippage, and realised yield under representative fill sizes.
• Risk Scorer. Computes the 8-factor risk score (Section 7) against current oracle and on-chain data.
• Signer. An isolated signing worker (key never shared with the public API surface) produces an EIP-712 attestation byte-matched against the live ValidationRegistry domain.
• Registrar. Submits the strategy plus its first attestation to StrategyRegistry on-chain. Idempotent: re-submissions for the same logical strategy short-circuit.

9.2  Closed-loop self-improvement

Outcomes from registered strategies feed back into the risk model. Strategies that under-deliver against simulated APY receive an automatic risk-score bump; those that over-deliver and remain stable receive higher confidence ratings. The loop is closed: every discovered strategy produces an artifact (the attestation), every artifact feeds back into the brain, every cycle has a measurable metric (registered strategies × confidence score × TVL routed).

9.3  Current state

The autonomous strategy-generation pipeline is operational on testnet as of this whitepaper’s publication. The first end-to-end self-discovered strategy was registered on Base Sepolia by an autonomous instance of the pipeline; subsequent strategies are being registered in batches as the venue catalogue expands across the supported EVM chains.

10.  Business Model

Routon captures value through three on-chain revenue lines. No subscriptions. No mandatory accounts. Every revenue line is per-event and either fully on-chain or settled through stablecoin micropayments. All rates are governance-tunable behind a seven-day timelock — no silent fee changes.

10.1  Performance fee

On every harvest of a Routon-routed strategy, the FeeCollector collects ten percent of the yield generated since the last harvest, in USDC (reward tokens auto-swapped through CoW where available). Forty percent of the fee is rebated on-chain to the calling agent’s builder code; sixty percent flows to the treasury. The fee accrues only on positive yield — a strategy that loses pays nothing.

10.2  B2B Risk-Operator-as-a-Service

Specialist risk firms today sell quarterly closed-PDF risk parameter recommendations to protocols and DAO treasuries for one to two million dollars per year per client. Routon delivers the equivalent service through the same risk-attestation pipeline used for retail flow, but with three differentiators: every attestation is signed and published on-chain; the methodology is open and auditable; and policy-bound rebalances can auto-execute through PrimitiveExecutor on parameter breach. Pricing tracks the incumbent benchmark.

10.3  Slippage Savings

For institutional flow — DAO treasury rebalances, fund position moves, market-maker inventory shifts — Routon’s execution router benchmarks the realised execution price against a Chainlink time-weighted reference over the same window. Routon takes twenty-five percent of any measured improvement; if execution does not beat the benchmark, the fee is zero. Every attestation of the improvement is posted on-chain, so the treasury committee or the fund LPs can verify the saving without trusting Routon’s reporting.

10.4  No token at launch

Mainnet ships without a protocol token. Investors hold equity in the operating entity that owns the protocol and its on-chain revenue lines. A token remains a possible future addition for governance and risk-attestation staking, but is not necessary to capture value at this stage.

11.  Security Posture

Routon’s security posture rests on three legs: a small, audited, invariant-checked on-chain surface; layered operational controls around privileged actions; and continuous third-party scrutiny through an open bug bounty.

11.1  Audit scope

The pre-mainnet audit programme covers the six core EVM contracts in scope as a competitive engagement (Code4rena, Sherlock, or Cantina), plus a separate Rust/Anchor audit for the Solana program and a Move-prover engagement for the SUI package. The Foundry invariant suite is in-scope on every engagement.

11.2  Threat model summary

A STRIDE-style threat model is maintained in the project repository and updated against every architectural change. The classes of adversary considered include: a compromised signing key; a malicious delegatecall target attempting to escape the allow-list; a malicious attestor; a flood adversary attempting denial-of-service; a front-running adversary attempting MEV; and a phishing adversary attempting to substitute a copycat surface. Mitigations are enumerated per class.

11.3  Operational controls

• Hardware wallets only for privileged signing keys; no software keys for any production owner role.
• 2-of-3 guardian multisig for parameter changes (allow-list updates, governance-tunable rates), with mandatory 24-hour timelock on every owner action.
• Pause switch via guardian multisig allows immediate suspension of new intents while existing positions remain user-owned and withdrawable directly from the external venue.
• Oracle disagreement breaker — Pyth and Chainlink prices must agree within 1%; disagreement triggers a circuit breaker that reverts new intents until resolved.
• Per-strategy TVL caps bound the maximum loss attributable to any single primitive failure.
• EIP-712 with nonce and deadline on every signed action prevents replay across chains and across time.

11.4  Bug bounty

An Immunefi bug bounty programme is opened on mainnet. The bounty scales with TVL routed through the protocol — bounty caps double at documented TVL thresholds.

11.5  Residual risks

Routon does not insure against, and explicitly accepts the following residual risks, which are inherent to non-custodial DeFi protocols:

• Underlying protocol risk. If an external primitive (Aave, Morpho, Uniswap, …) is exploited, user positions in that primitive can be lost. The user is the depositor of record; Routon does not insure third-party venues.
• Oracle risk. Pyth and Chainlink prices may be manipulated or stale. The two-oracle disagreement breaker mitigates but does not eliminate this risk.
• Routon contract risk. Routon’s own contracts may contain bugs not caught by audit and bounty. The initial TVL cap and the pause switch bound the worst-case loss before mitigation.
• Regulatory risk. Future regulatory action may restrict access to Routon for users in some jurisdictions. The dashboard surface at app.routon.xyz applies jurisdictional geofencing at mainnet; the protocol contracts themselves are permissionless.

References

• Routon Standard. Open RFC under CC0. Project repository.
• ERC-8004 — Autonomous Agent Identity. Ethereum Improvement Proposal, finalised January 2026.
• EIP-712 — Typed structured data hashing and signing.
• ERC-7683 — Cross-chain Intent Standard.
• x402 — HTTP-native payment specification. Coinbase Developer Platform reference implementation.
• MCP — Model Context Protocol. Open specification for assistant-tool integration.
• RFC 8785 — JSON Canonicalization Scheme (JCS). Used for deterministic factor-vector hashing in attestation payloads.
• Foundry. Solidity testing and invariant fuzzing framework by Paradigm.

Glossary

• Attestation. An EIP-712-signed assertion about the risk properties of a strategy at a point in time, posted to ValidationRegistry under the attestor’s ERC-8004 identity.
• Builder code. A short on-chain identifier bound to an ERC-8004 identity and a payout address; carried in execution calldata for agent-to-agent attribution.
• Composability. The property of a strategy that allows it to be a primitive inside another, larger strategy.
• Custodial / non-custodial. A protocol is custodial if it can move user principal without the user’s transaction-time signature. Routon is non-custodial by architecture (Section 5).
• delegatecall. An EVM call type that executes target bytecode in the caller’s address-space context. PrimitiveExecutor uses delegatecall to externals so that token ownership remains with the user wallet.
• Harvest. Permissionless on-chain function that realises accumulated yield and triggers the performance-fee split.
• Invariant. A property that must hold across every reachable state of the contracts. Asserted by fuzz tests in Foundry.
• JCS. JSON Canonicalization Scheme (RFC 8785) — deterministic serialisation of JSON used for hashable factor vectors.
• MCP. Model Context Protocol — open standard for connecting assistants to external tools and data sources.
• Routon Standard. CC0 open machine-readable JSON schema for DeFi yield opportunities (Section 3).
• x402. HTTP 402 Payment Required-based protocol for charging small stablecoin payments per API call.