Echo Protocol

1.1 Three forces converging

1.2 The cost of the missing layer

1.3 Market size

The DeFi market cap reached $98.4 billion in 2025. 42% of crypto users are active traders whose strategies benefit most from automation. If even 1% of DeFi capital is managed by AI agents with permissioned execution, that represents nearly $1 billion in assets requiring a safety layer. As agent adoption grows — which it demonstrably is — this percentage will rise. The permission layer for agentic finance is a standard-layer opportunity. Echo is building it before anyone else.

2.1 No safe way to delegate on-chain authority

2.2 Why CEX API keys are not the answer

3.1 Core insight: enforcement belongs on-chain

Today, agent permissions live in configuration files, API settings, and user agreements — all off-chain, all mutable, all dependent on trusting the software stack. One compromised component breaks the boundary.

3.2 Trust model: bounded trust, not blind trust

Echo operates on a principle of bounded trust rather than complete trustlessness. Two distinct layers provide safety:

This is the same trust model used by MetaMask, Safe, and every major DeFi frontend. Complete trustlessness is a theoretical ideal; Echo is transparent about where trust exists and ensures its scope is minimal and auditable.

4.1 Echo Gateway — the central component

Echo Gateway is a locally-deployed service that is the heart of the entire system. It serves two audiences simultaneously: the user (via Dashboard) and the AI agent (via MCP). Everything flows through the Gateway.

4.2 Five-layer stack

4.3 Headless, local-first, framework-agnostic

Echo is designed around three principles that distinguish it from every other agent permission solution:

4.4 Dual-mode operation with two-stage pre-validation

Echo operates in two modes and applies two independent pre-validation checks before any UserOperation reaches the chain. Pre-validation is a UX layer — fast failure with human-readable errors. The on-chain Validator is always the final authority.

User → OpenClaw: 'Buy 100 USDC of ETH'
OpenClaw → Echo MCP: echo_submit_intent({
  tool: uniswap-v3, action: swap,
  tokenIn: USDC, tokenOut: WETH, amount: 100
})

Pre-validation #1 (intent layer):
  Policy active? Token in limits?
  Amount ≤ maxPerOp? Daily cap OK?
  → PASS

Echo → Uniswap Tool: execute intent
Uniswap Tool → Echo: returns calldata

Pre-validation #2 (transaction layer):
  target == Uniswap SwapRouter?
  selector == exactInputSingle?
  recipient == AccountERC7579?
  decoded amount matches intent?
  → PASS → UserOp → Pimlico → Validator

User: 'DCA into ETH, 50 USDC/day, 7 days.'
OpenClaw → echo_create_session
  → SessionPolicy stored on-chain
User confirms once (~10 seconds)
Session Key issued to OpenClaw

Each day (OpenClaw scheduler triggers):
  OpenClaw → echo_execute_session({
    sessionId, intent
  })
  Pre-validation #1 + #2
  → PASS → UserOp with session sig
  → swap executes
  → session.totalSpent updated on-chain

Day 8: sessionExpiry reached.
All ops rejected. Task complete.

4.5 Action Builder — intent to calldata

The Action Builder transforms an agent's intent declaration into protocol-specific calldata. This is a critical security design: agents declare what they want to do, not how to do it.

The Action Builder queries the Tool Registry (a curated JSON maintained by Echo) for protocol contract addresses and ABIs. It calls Uniswap's Quoter contract for optimal routing before constructing exactInputSingle calldata. Every built transaction has recipient = AccountERC7579 — hardcoded, non-overridable by any agent or tool.

4.6 Permission model: per-token limits

MetaPolicy defines limits at the token level, not as a global whitelist. Each token the user authorises has its own independent limit configuration:

MetaPolicy:
  tokenLimits:
    WETH:  { maxPerOp: 1000 USDC, maxPerDay: 3000 USDC }
    WBTC:  { maxPerOp: 1000 USDC, maxPerDay: 3000 USDC }
    TRUMP: { maxPerOp:  100 USDC, maxPerDay:  300 USDC }

  explorationBudget: 50 USDC   // any unlisted token
  explorationPerTx:  10 USDC   // per-operation cap for exploration

  globalMaxPerDay:   5000 USDC // aggregate daily cap across all tokens
  globalTotalBudget: 20000 USDC // lifetime cap
  expiry: 90 days
  paused: false

4.7 Policy Templates and Instances

To reduce first-time setup friction and minimise gas costs, Echo separates what-is-common (PolicyTemplate) from what-is-personal (PolicyInstance). Templates are reusable parameter sets stored once on-chain. Each user deploys a lightweight PolicyInstance that references a template and overrides only the fields they need to change.

struct PolicyTemplate {
  bytes32   templateId
  string    name
  // 'Conservative DCA'
  // 'Standard', 'Active'
  address[] defaultTokens
  uint256   defaultMaxPerOp
  uint256   defaultMaxPerDay
  uint256   defaultExplorBudget
  uint256   defaultExplorPerTx
  uint256   defaultGlobalMaxPerDay
}

struct PolicyInstance {
  bytes32   templateId
  address   owner
  bytes32   executeKeyHash
  address[] allowedTargets
  bytes4[]  allowedSelectors

  mapping(address => TokenLimit)
            tokenLimits
  uint256 explorationBudget
  uint256 explorationPerTx
  uint256 explorationSpent

  uint256 globalMaxPerDay
  uint256 globalTotalBudget
  uint256 globalTotalSpent

  uint64  expiry
  bool    paused
}

Echo ships three official templates for MVP. The template system is also the foundation for a future Policy Marketplace where strategy authors can publish and monetise validated configurations.

4.8 Phase 1: Transaction Flow Sequence Diagram

Phase 1: Transaction Flow Sequence Diagram

Expand

5.1 Threat model

5.2 Three non-negotiable on-chain rules

Regardless of what any agent or tool attempts, these three rules are enforced by EchoPolicyValidator and cannot be bypassed:

5.3 Attack surface analysis

5.4 Acknowledged limitations

6.1 Two integration interfaces

echo_get_available_tools()
echo_submit_intent(params)
echo_create_session(params)
echo_execute_session(params)
echo_list_sessions()
echo_revoke_session(sessionId)
echo_get_activity_log()

6.2 How Uniswap V3 is integrated

There is no 'Uniswap Skill' that OpenClaw installs. Uniswap V3 is an internal Tool module inside Echo Gateway. OpenClaw declares what it wants to do; Echo builds how to do it.

// OpenClaw's perspective — simple intent declaration:
const result = await mcp.echo_submit_intent({
  tool: 'uniswap-v3',
  action: 'swap',
  tokenIn: 'USDC',
  tokenOut: 'WETH',
  amount: 100
})

// Echo Gateway's internal work (invisible to OpenClaw):
// 1. Pre-validation #1: check Policy limits
// 2. UniswapV3Tool.buildCalldata({
//      tokenIn, tokenOut, amountIn,
//      recipient: AccountERC7579  ← hardcoded, not from OpenClaw
//    })
// 3. Call Uniswap Quoter for optimal amountOutMinimum
// 4. Encode exactInputSingle calldata
// 5. Pre-validation #2: verify calldata matches intent
// 6. Build UserOp → submit to Pimlico

// result: { txHash, amountOut, status: 'success' }

Adding a new protocol in Phase 3 means writing a new Tool module inside Echo Gateway — not asking OpenClaw developers to install a new skill.

6.3 Pre-validation — two stages

Pre-validation #1 saves a Tool call on obviously invalid requests. Pre-validation #2 independently verifies the calldata the Tool returned — Echo does not trust the Tool's output. Even if a Tool module contains a bug or is tampered with, pre-validation #2 catches any calldata that does not match the declared intent.

6.4 Developer integration

// 1. Add Echo MCP to openclaw_settings.json
{
  "mcpServers": {
    "echo": {
      "command": "npx",
      "args": ["@echo-protocol/openclaw-mcp"],
      "env": { "ECHO_GATEWAY": "http://localhost:3000" }
    }
  }
}

// 2. OpenClaw uses MCP tools to submit intents
// Echo Gateway handles all protocol interactions internally

An OpenClaw developer unfamiliar with Echo can complete integration and execute their first on-chain swap in under 15 minutes, following only the README.

7.1 How existing solutions fall short

7.2 Echo's relationship with the ecosystem