Replace brittle key-held bots with verifiable automation.

Verification-first execution for DeFi automation.

IEL (Intent Execution Layer) lets apps automate swaps, Aave actions, and rebalancing with hard guardrails—budgets, venues, and selectors. Intents are verified on-chain before any executor can run them, making automation testable, auditable, and allowing executors to be swapped without migrating wallets.

Extends naturally to AI agents and programmatic payments.

Non-custodial (no keys held)Executor-agnostic (switch without wallet migration)Two-phase lifecycle (verify → execute, fully observable)

Why IEL

Built for DeFi automation that needs to be provably safe, observable, and executor-agnostic.

Verification-first
1

Safe automation with guardrails

Budgets, venues, selectors, assets. Make automation provably bounded.

2

Failure clarity (not mystery reverts)

Readable violations: budget exceeded, venue not allowed, TOCTOU mismatch.

3

Executor portability

Swap or rotate executors without migrating wallets or changing policies.

How it works

A clean separation: apps and agents create intents, the chain validates them, and executors perform the action.

Intent → Validate → Execute
Intent Submitted(tx 1)
On-chain Validation ✓(event)
Executor Runs(tx 2)
1
Define policyCreate a wallet and attach guardrails: budgets, venues, selectors, token allowlists.
2
App signs intentApp/agent builds an intent (transfer/swap/call) and signs it under a policy + time window.
3
Verify on-chainIntentManager validates constraints and emits a verification event on success.
4
Executor runsExecutor sees the event, executes, and emits completion. Apps can track both phases via events.
// App-side (SDK): execute under a policy (guardrails enforced on-chain)
const runtime = iel.relayer.connect({ url, chainId, defaultDelegate });

const result = await runtime.multiOpExecute({
  policyId,
  walletAddress,
  operations: [
    { opType: "APPROVE", target: USDC, value: "0", data: approveData },
    { opType: "CALL", target: AAVE_POOL, value: "0", data: supplyData },
  ],
  leafAndProof,
  policyRootVersion,
  headerVersion,
});

await runtime.waitForExecution({ intentHash: result.intentHash });

// Executor runtime
executor.start({ rpcUrl, intentManager });

Security & Trust Model

Execution power is always constrained, auditable, and replaceable by design.

Trust by design

Who can execute

Any authorized executor can run an intent — but only after it passes on-chain policy validation.

Who can move funds

Executors never have custody. They can only execute what a policy explicitly allows.

How abuse is prevented

Budgets, venues, selectors, and time windows are enforced on-chain before execution.

If an executor is malicious

Invalid intents fail validation, violations emit readable errors, and apps can switch executors without migrating wallets.

Use cases

Start with DeFi automation. Expand to agents and payments when you're ready.

Built to scale

DeFi automation (bots you can trust)

For protocols and funds that need bounded automation

Swaps, Aave supply/withdraw, DCA, rebalancing—bounded by budgets, venues, selectors, token allowlists.

AI agent execution (same guardrails)

For builders who don't trust agents with keys

Agents can propose actions, but policies decide what executes. "Malicious agent" becomes a test, not a breach.

Programmatic payments (later lane)

For teams replacing brittle ops scripts

Payroll, invoices, payouts—audit-friendly two-phase lifecycle and policy-based controls.

Demo

Watch a DeFi automation flow with guardrails—and see exactly why failures happen.

Two-phase execution in action
Demo video

What to show (fast)

A
Wallet + DeFi Automation presetOne-click preset that creates a constrained DeFi environment.
B
Happy path: swap + Aave supplyExecute bounded swap and Aave supply operations.
C
Failure clarityVenue/selector/budget/TOCTOU violations with readable errors.
D
Executor portabilitySwitch executor endpoint and re-run—same policy, different executor.

Want early access to IEL?

Use this section for your “request access” flow (email, calendar link, or a gated deck/login).