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.
Why IEL
Built for DeFi automation that needs to be provably safe, observable, and executor-agnostic.
Safe automation with guardrails
Budgets, venues, selectors, assets. Make automation provably bounded.
Failure clarity (not mystery reverts)
Readable violations: budget exceeded, venue not allowed, TOCTOUTOCTOU (Time-of-check to time-of-use)Execution conditions changed after validation but before execution. mismatch.
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.
// 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.
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.
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.
What to show (fast)
Want early access to IEL?
Use this section for your “request access” flow (email, calendar link, or a gated deck/login).