How Intent-Based Lending Changes DeFi Risk?

Pooled lending defined DeFi’s first era. In early lending and borrowing protocols, users deposited assets into shared vaults while borrowers drew over-collateralized loans, with interest rates adjusting algorithmically. Settlement was synchronous and fully on-chain. The model was simple and liquid, but capital often sat idle, risk was socialized across participants, and pricing remained constrained by governance decisions and utilization curves.

Intent-based lending replaces pooled capital with signed constraints. Instead of depositing funds, users sign off-chain EIP-712 intents specifying principal, rate bounds, duration, collateral, LTV limits, and execution conditions. Borrowers submit symmetric intents. A competitive solver network matches these off-chain and submits a single atomic on-chain settlement transaction that transfers assets directly between counterparties or into isolated CREATE2 loan contracts.

Capital remains in user custody until settlement. Terms are fixed at the constraint level. Risk is isolated per match.

But this shift moves discovery, matching, and routing off-chain. Execution becomes asynchronous. Solvers become economically powerful actors. Oracle freshness, nonce management, and settlement-time validation become critical security boundaries.

The attack surface is no longer pool accounting, it is the intent-to-settlement pipeline.

This guide dissects that pipeline in detail, including architecture, exploit vectors, and production-grade mitigations for teams building or auditing intent-based lending systems.
 

How Intent-Based Lending Works: Technical Architecture

At its core, an intent is a signed EIP-712 message that encodes the user’s desired final state rather than a rigid transaction path. A representative LendIntent struct (generalized from current high-performance implementations) looks like this:

1struct LendIntent {
2    address signer;
3    uint256 amount;                   // principal to lend
4    address asset;                    // e.g., USDC
5    uint256 minRateBps;               // annualized fixed or variable flag
6    uint256 durationSeconds;
7    address collateralAsset;
8    uint256 maxLTVBps;
9    uint256 nonce;                    // per-signer replay protection
10    uint256 deadline;                 // absolute Unix timestamp
11    bytes32 conditionsHash;           // keccak256 of oracle requirements, whitelists, hooks, chainId, minFillAmount, maxSlippageBps
12    uint256 minFillAmount;
13    uint256 maxSlippageBps;
14}

The borrower signs a symmetric BorrowIntent. Both are broadcast to a public or permissioned solver network. Solvers high-performance Rust or Go binaries run by professional market makers or specialized entities, perform the following off-chain computation:

1. Deserialize and cryptographically re-verify the EIP-712 digest against the on-chain DOMAIN_SEPARATOR (which includes chainId and contract version).
    
2. Simulate fulfillment via eth_call bundles to check current oracle medians, LTV feasibility, rate overlap, and hook execution.
    
3. Batch multiple intents together to discover Coincidence of Wants (CoW) matches or ring-trade optimizations that minimize slippage and gas.
    
4. Select the optimal match set that maximizes surplus (better rates for users) while respecting all constraints.

The winning solver submits a single atomic on-chain fulfill transaction that:

• Recovers both signers via _hashTypedDataV4.
   
• Validates deadlines, nonces, oracle freshness (lastUpdate + MAX_STALENESS >= block.timestamp, typically ≤ 300 seconds).
   
• Performs SafeERC20 transfers with strict minFillAmount and post-execution slippage recalculation.
   
• Deploys an isolated loan contract via CREATE2 (salt = keccak of intent hash) containing deterministic liquidation logic, repayment schedules, and custom hooks.
   
• Executes post-settlement hooks (e.g., deposit principal into a yield vault, emit compliance events).

This flow achieves several breakthroughs impossible in pooled designs:

• Zero idle capital - every lent unit is immediately matched and deployed.
• Fixed-rate, fixed-term loans - users lock in economics at signing time.
• Isolated risk - one default affects only the matched counterparty.
• AI-agent native - autonomous agents can sign intents based on real-time market signals.
• Cross-protocol composability - solvers can nest routing (swap → bridge → settle) with on-chain guarantees.

The architecture deliberately keeps asset custody with users until the final atomic settlement. This is the source of both its power and its novel security challenges.
 

Attack Vectors in Intent-Based Lending

The shift from synchronous pooled accounting to asynchronous off-chain matching followed by on-chain settlement introduces new trust boundaries and timing windows that do not exist in traditional pooled protocols. Because discovery and matching occur off-chain while final execution occurs on-chain, the system depends on signatures, solvers, and delayed settlement steps. This separation creates new attack surfaces. Below are the primary vectors, each illustrated with concrete failure modes, Mermaid attack sequences, and code patterns observed in early implementations.
 

Malicious or Compromised Solvers

Solvers control match selection and settlement submission with no native on-chain slashing in most designs.

A compromised solver (key theft, RCE on cloud infrastructure, or insider) can:

• Censor high-value intents.
• Pair legitimate lenders with artificially under-collateralized borrowers using stale data.
• Front-run by inserting its own intents.

Exploit Example

Solver sees $10M borrow intent. Submits fake lend intent from controlled address, settles, then immediately liquidates after price movement, pocketing fees while locking borrower collateral.

Vulnerable Pattern (no bond, no challenge window)

1function fulfill(LendIntent calldata i, bytes calldata sig) external {
2    address recovered = _hashTypedDataV4(hashIntent(i)).recover(sig);
3    require(recovered == i.signer);
4    // No solver bond or dispute period
5    transferAssets(...);
6}

Front-Running and Intent-Layer MEV

Intent discovery occurs off-chain before any transaction hits the mempool. Attackers monitor public relays or run their own solver.

Upon seeing a large borrow intent against volatile collateral, the attacker:

• Posts a competing lender intent with marginally worse terms.
• Flashloans to pump collateral price during the matching window.
• Submits fulfillment first.

The window spans minutes far longer than transaction-level MEV.

Collateral Manipulation Pre-Settlement

Assets remain in user custody until fulfillment. Borrowers can flashloan-pump collateral valuation, partially sell on external venues, or double-pledge across protocols.

Settlement succeeds on inflated value, immediate bad debt post-reversion.

Vulnerable Check

1uint256 price = oracle.latestAnswer(); // snapshot only at fulfill
2require(collateralBalance * price * 10000 / debt >= intent.maxLTVBps);

Oracle Staleness in Asynchronous Settlement

Intents lock in price constraints at the time of signing, while settlement happens later. If lastUpdate + MAX_STALENESS isn’t enforced, trades can settle using outdated prices, leading to bad debt or unfair liquidations. In multi-oracle setups without per-source freshness checks, malicious solvers can deliberately route through the stalest oracle to exploit pricing gaps.

Vulnerable check:

1uint256 price = oracle.latestAnswer(); // no timestamp
2require(price >= intent.minPrice);

Slippage and Fill-Guarantee Mismatches

Users sign exactly 100 000 USDC at exactly 8.5 %. Solver delivers 98 400 USDC after routing fees and impact. Without strict on-chain enforcement after all hooks, users suffer silent degradation and dust griefing.

Vulnerable Enforcement

1require(receivedAmount >= intent.amount); // no minFill, no post-hook slippage buffer

Signature & Nonce Vulnerabilities

Raw keccak256 hashes, missing chainId, or nonce marking before external calls enable replay across forks, ECDSA malleability, and reentrancy drains.

Vulnerable Pattern

1bytes32 hash = keccak256(abi.encode(intent)); // no domain separator
2address signer = ECDSA.recover(hash, sig); // malleable s-value
3require(!usedNonces[signer][intent.nonce]);
4usedNonces[signer][intent.nonce] = true; // BEFORE transfer → reentrancy window

Denial-of-Service at the Matching & Settlement Layer

Because intents are created off-chain without mandatory upfront on-chain validation or escrow, a malicious actor can flood the solver network with thousands of fake or non-viable intents. These intents may reference wallets that hold insufficient balances or have never approved the protocol for transferFrom. Even if solvers perform off-chain balance/allowance checks, the repeated evaluation and discarding of junk intents degrades matching efficiency, inflates operational costs for honest solvers, and can slow or stall legitimate matching for all users.

A second DoS variant, an attacker intentionally matches a borrower's intent as the lender, then front-runs the settlement transaction by withdrawing or spending the promised funds beforehand. The on-chain transferFrom reverts, the match fails, and the borrower’s intent remains unfulfilled. Repeating this griefing across multiple matches can effectively halt protocol operation without direct profit to the attacker, pure disruption at the settlement layer.

Vulnerable Off-Chain Solver Pseudocode (Rust-style)

1// VULNERABLE — no rate-limiting or proof-of-funds requirement
2fn process_intent(intent: Intent) -> bool {
3    if !verify_signature(&intent) { return false; }
4    // No mandatory pre-check bond or reservation tx
5    if simulate_fulfill(&intent).is_ok() {
6        submit_onchain(); // but funds may be gone by then
7    }
8    true
9}

Mitigation Framework and Production Security Checklist

1. Cryptographic Foundation - Mandatory EIP-712 with chainId + version. OpenZeppelin SignatureChecker + ERC-1271. Per-signer nonces + deadlines ≤ 24 h.
    
2. Solver Economic Security - Slashable bonds + 60-minute on-chain challenge window with oracle-snapshot dispute proofs.
    
3. Temporal & Freshness Controls - Strict deadlines + per-oracle updatedAt checks (≤ 300 s). Timestamp-weighted median for multi-oracle.
    
4. Collateral & Fill Guarantees - Optional gas-abstracted reservation tx. On-settlement: SafeERC20.safeTransferFrom + post-all-hooks slippage buffer (value * (10000 - maxSlippageBps)) / 10000.
    
5. Anti-DoS & Anti-Griefing - Mandatory proof-of-funds reservation or small bond per intent. Per-solver and per-lender rate-limiting. Front-running protection via sealed-bid or commit-reveal matching.
    
6. AI-Agent Hardening - Rate-limits and approval lists on delegated wallets. On-chain audit logs for agent-signed intents.
    

Immediate 2026 Audit Checklist

• EIP-712 DOMAIN_SEPARATOR includes chainId and version?
• Oracle staleness enforced per source with timestamp?
• Nonces updated after all external calls inside nonReentrant?
• Solvers post slashable bonds with public challenge function?
• minFillAmount and maxSlippageBps validated after every hook?
• Atomic user cancel path without solver cooperation?
• CREATE2 loan salt derived from full intent hash?
• Proof-of-funds or reservation required before matching?
• Rate-limits on AI-delegated intent submission?
   

Conclusion

Intent-based lending replaces pooled liquidity with constraint-based execution, unlocking capital efficiency and isolated risk, but shifting critical trust boundaries off-chain. The security model is no longer about pool accounting, it is about signatures, solver incentives, oracle freshness, and settlement-time validation. Every exploit vector stems from that asynchronous gap between intent and execution. Teams building in this paradigm must treat the intent-to-settlement pipeline as a first-class security surface. In the next cycle of DeFi, failures won’t come from utilization curves, they will come from improperly secured matching engines and settlement logic.