Investor Readiness Document

Intent Execution Layer (IEL)

Investor Readiness & Context

This document answers the most common “is this real / what's live / why now / what's next” questions investors have when evaluating IEL.

“IEL is a verification-first execution layer for DeFi automation—apps/agents sign intents, on-chain policy verifies them, and authorized executors run only valid work (no relayer lock-in).”

Live on Base SepoliaPre-seed stageNo token required for v1

1. How IEL Works

IEL separates decision, verification, and execution into distinct phases.

Single Mental Model
Intent
App/Agent signs
Verify
IntentManager
+ policy constraints
Execute
Authorized executor
Complete
On-chain tx

Technical detail

┌────────────┐
│ App / Agent│
└─────┬──────┘
      │ 1. Build + sign intent
      ▼
┌──────────────────────┐
│ IntentManager        │
│ (on-chain)           │
│                      │
│ • Verify constraints │◄── Policy headers
│ • Check budgets      │◄── Merkle proofs
│ • Enforce venues     │◄── Delegation rules
└─────┬────────────────┘
      │ 2. Emit validated event
      ▼
┌──────────────────────┐
│ Executor / Relayer   │
│                      │
│ • Reconstruct ops    │
│ • Execute tx(s)      │
│ • Emit completion    │
└─────┬────────────────┘
      ▼
┌────────────┐
│ Blockchain │
└────────────┘

Key idea

Nothing executes unless it has already passed on-chain policy verification.

This eliminates:

TOCTOU failures
Blind relayers
Agent key risk
Opaque automation

Apps and agents propose. Policies decide. Authorized executors run valid work.(open market planned)

2. What's Live Today

No hand-waving. Here's what's implemented and running.

v1 Implemented

Networks

Local Hardhat / AnvilBase Sepolia (public demo)

Core Protocol

  • Policy-enabled smart wallets
  • Multi-policy per wallet architecture
  • IntentManager (on-chain verification)
  • Two-phase execution model (validate → execute)
  • Delegated signing (agent / relayer execution)
  • V2 + V3 constraint system (Merkle leaves + policy headers)
  • TOCTOU protection via header binding
  • Executor-agnostic architecture

SDK

  • Wallet creation (counterfactual + deploy)
  • Policy creation with presets (payroll, trading, treasury)
  • Agent clients (transfer, swap, multiOp)
  • Runtime abstraction (relayer / executor endpoint)
  • Typed error handling

UI Demo

  • Wallet + policy presets
  • Successful execution paths
  • Constraint failures (budget, venue, selector)
  • Agent attempt blocked by policy
  • Two-phase lifecycle visibility
E2E tests:transfers, swaps, Aave supply/withdraw, executor portability

Explicitly not yet included (v1)

Wallet discovery API (list existing IEL wallets)Wallet recovery / policy rehydration APIManaged WalletOps Cloud (backup, attestations)Production relayer SDK (hardening + monitoring)Cross-chain routing

These are planned extensions, not blockers for protocol validity.

3. What's Coming Next

Near-term roadmap for SDK and platform.

Near-Term

SDK Extensions

  • Wallet discovery (listWallets(address))
  • Policy + wallet recovery / rehydration
  • Policy version history access
  • Relayer SDK packaging

Platform Layer

  • WalletOps Cloud (artifact backup, audit, recovery)
  • Attestations for enterprises
  • Optional execution optimization / routing

4. Traction Plan & Investor Ask

We are intentionally starting with builders who already feel the pain.

Pre-seed

Initial Target Users

1

Agent builders

Want automation without giving agents keys. Need deterministic, testable constraints.

2

DeFi automation teams

Rebalancing, DCA, yield ops. Need bounded execution + auditability.

3

Treasury / ops teams

Payroll, invoices, payouts. Need verification + lifecycle visibility.

The Business

Monetization

  • WalletOps Cloud (backup, audit, recovery)
  • Relayer SDK licensing
  • Enterprise policy attestations
  • Pilot + integration fees

Buyer

Treasury/ops teams + DeFi automation teams

Initial Wedge

Verification-first DeFi ops policies

Why We Win

Policies + lifecycle + portability + SDK-first distribution

What we're asking for now

  • Design partners to validate SDK ergonomics
  • Pilot integrations (small production scopes)
  • Feedback on WalletOps requirements

Fundraise

Raising pre-seed to fund: SDK polish + 2–3 pilots + WalletOps Cloud v1.

Funds used for:

  • SDK polish + docs
  • WalletOps Cloud v1
  • Relayer SDK hardening
  • 2–3 production pilots

90-day goal: 2 design partners + 1 pilot in production scope.

No token launch required for v1.

5. Competitive Framing

Why now, and why IEL is differentiated.

Why Now

Why Now

Agents are arriving, but key custody is unacceptable.
Protocols are shipping apps, but automation still lacks verifiable guardrails.
4337 adoption makes policy wallets practical.

Why “agents + keys” is broken

  • Keys are binary authority
  • No preconditions
  • No bounded behavior
  • One bug = total loss

IEL replaces authority with verifiable intent.

Why Safe modules / raw 4337 aren't enough

Safe + 4337 give signature aggregation and account abstraction.

They do NOT give:

  • Verified preconditions
  • Two-phase execution
  • Executor portability
  • TOCTOU protection
  • Multi-policy specialization

IEL operates above wallets as an execution membrane.

IEL's Moat

Constraint system (Merkle + policy headers)
Two-phase verification-first execution
Multi-policy per wallet
Executor portability
SDK-first distribution
Operational monetization (not protocol rent)

Competitors can copy contracts. They can't easily copy:

the constraint languagethe verification lifecyclethe developer workflowthe operational layer

Accumulating advantages over time:

  • Growing library of battle-tested policy presets
  • Real production workflows from pilot integrations
  • Institutional-grade audit trails + controls (WalletOps)
  • Ecosystem standard for intent verification events

Summary

IEL is not a wallet.IEL is not a relayer.

IEL is the missing execution layer that makes automation safe, testable, and portable.

For builders:Read Docs