Intent (Intent-Driven Architecture)¶

Traditional Model (Transaction):
User: I want to swap 1 ETH for DAI on Uniswap via the path ETH → USDC → DAI
Characteristics: User specifies exact execution steps
Problem: User needs to understand underlying protocols, routing, slippage, and other technical details

Intent Model (Intent):
User: I want to swap at most 1 ETH for at least 1,800 DAI
Characteristics: User only expresses the goal, doesn't care about execution method
Advantage: Solvers compete to provide the best price and execution path

// ERC-7683 Cross-Chain Intent Standard
struct CrossChainOrder {
    // Source chain information
    address settlementContract;  // Intent settlement contract
    address swapper;             // User initiating the intent
    uint256 nonce;               // Replay prevention
    uint32 originChainId;        // Source chain ID
    uint32 openDeadline;         // Intent open deadline
    uint32 fillDeadline;         // Execution deadline

    // User inputs (assets willing to pay)
    Input[] inputs;

    // User outputs (assets expected to receive)
    Output[] outputs;
}

struct Input {
    address token;      // Token address
    uint256 amount;     // Amount
}

struct Output {
    address token;           // Token address
    uint256 amount;          // Minimum receive amount
    address recipient;       // Recipient address
    uint32 chainId;          // Destination chain ID
}

1. User Creates Intent:
   - Input: 1 ETH (Ethereum Mainnet)
   - Output: At least 1,800 USDC (Arbitrum)
   - Deadline: 10 minutes

2. User Signs Intent (Off-Chain):
   - Uses EIP-712 signature
   - No immediate on-chain submission needed (saves Gas)
   - Can broadcast to multiple Solver networks

3. Solver Competition:
   - Solver A bid: 1,850 USDC
   - Solver B bid: 1,870 USDC (best)
   - Solver C bid: 1,840 USDC

4. Best Solver Executes:
   - Solver B locks user's 1 ETH on source chain
   - Solver B transfers 1,870 USDC to user on destination chain
   - Transaction verified via cross-chain messaging
   - Solver B receives 1 ETH + spread profit

5. User Benefits:
   - Gets better price than AMM
   - No manual cross-chain bridge operation needed
   - No need to hold Gas tokens on destination chain

Identity: Professional transaction executors (market makers, MEV searchers, funds, etc.)

Capabilities:
1. Private liquidity: Fulfill orders directly from inventory
2. Route optimization: Find optimal paths across multiple DEXs and aggregators
3. Batch settlement: Bundle multiple intents for execution, reducing costs
4. Cross-chain resources: Hold assets on multiple chains, execute quickly

Revenue Sources:
1. Spread: Offer better-than-market prices, earn the difference
2. Rebates: Receive trading rebates from DEXs, bridges, etc.
3. MEV extraction: Extract value through optimized transaction ordering

CoW Swap / CoW Protocol:
- Batch Auction
- Each batch contains multiple intents
- Solvers submit execution plans
- Best plan wins

Advantages:
- Prevents sandwich attacks (no ordering within batches)
- Coincidence of Wants (COW): Match opposing orders
- Maximize user welfare

Example:
Intents in a batch:
- Alice: Sell 1 ETH, buy USDC
- Bob: Buy 1 ETH, sell USDC
- Solver directly matches Alice and Bob, no AMM needed
- Saves slippage and fees

UniswapX:
- Dutch Auction
- Price decays linearly over time
- First-come-first-served

Timeline (10-minute order):
T=0:  Minimum acceptable price 1,800 USDC
T=5:  Decayed price 1,850 USDC
T=10: Optimal price 1,900 USDC

Solver Decision:
- Execute early: More spread, but higher competition risk
- Execute late: Less spread, but higher success rate
- Balance timing and profit

Across Protocol V3:
- Relayers (Solvers) must stake BOND tokens
- Malicious behavior gets slashed
- Good track record earns more orders

Incentive Mechanism:
- Fast execution: Earn additional rewards
- Stable service: Increase reputation score
- Slash risk: Deters fraud

// ERC-7683 Core Interface
interface ISettlementContract {
    // User creates intent
    function open(CrossChainOrder calldata order) external;

    // Solver executes intent
    function fill(
        bytes32 orderId,
        bytes calldata originData,
        bytes calldata fillerData
    ) external;

    // Verify cross-chain execution
    function resolve(
        bytes32 orderId,
        bytes calldata proof
    ) external;
}

Scenario: Ethereum → Arbitrum cross-chain swap

Step 1: User creates intent on Ethereum
┌─────────────────────────────────────┐
│ Ethereum Mainnet                     │
│                                      │
│ User signs Intent:                   │
│ - Give: 1 ETH (Ethereum)            │
│ - Want: ≥1,800 USDC (Arbitrum)     │
│ - Deadline: 10 min                   │
│                                      │
│ → Broadcast to Solver network       │
└─────────────────────────────────────┘

Step 2: Solvers compete with bids
┌─────────────────────────────────────┐
│ Off-chain Solver Network             │
│                                      │
│ Solver A: 1,850 USDC (rejected)    │
│ Solver B: 1,880 USDC (WINNER!)     │
│ Solver C: 1,860 USDC (rejected)    │
│                                      │
└─────────────────────────────────────┘

Step 3: Solver B locks funds
┌─────────────────────────────────────┐
│ Ethereum Mainnet                     │
│                                      │
│ Solver B calls fill():              │
│ - User's 1 ETH locked in contract  │
│ - Solver commits to 1,880 USDC     │
│                                      │
│ emit Filled(orderId, solverB)       │
└─────────────────────────────────────┘

Step 4: Solver B sends assets on destination chain
┌─────────────────────────────────────┐
│ Arbitrum                             │
│                                      │
│ Solver B transfers:                  │
│ - 1,880 USDC → User's address       │
│                                      │
│ emit OutputFilled(orderId)          │
└─────────────────────────────────────┘

Step 5: Cross-chain message verification completes
┌─────────────────────────────────────┐
│ Ethereum Mainnet                     │
│                                      │
│ Cross-chain proof received:          │
│ - Verify output on Arbitrum         │
│ - Release 1 ETH to Solver B         │
│                                      │
│ Intent finalized ✓                  │
└─────────────────────────────────────┘

Option 1: Optimistic Verification
Protocol: Across Protocol
Mechanism:
- Solver executes first, verifies later
- 7-day challenge period
- Challengers can submit fraud proofs to slash Solver
Advantage: Extremely fast (seconds)
Disadvantage: Requires staking, low capital efficiency

Option 2: Fast Messaging Layer
Protocol: LayerZero, Wormhole, Axelar
Mechanism:
- Relay network verifies cross-chain events
- Verification completes within minutes
Advantage: No staking required, high capital efficiency
Disadvantage: Relies on third-party relay networks

Option 3: Native Bridge
Protocol: Optimism, Arbitrum official bridges
Mechanism:
- L2 → L1: 7-day challenge period
- L1 → L2: 10-30 minutes
Advantage: Most secure
Disadvantage: Slow

Sandwich Attack:
1. Alice submits: Buy 10 ETH (public mempool)
2. MEV Bot detects transaction
3. Bot front-runs: Buys 10 ETH first (pushes up price)
4. Alice's transaction executes: Buys at worse price
5. Bot back-runs: Sells 10 ETH for profit

Alice's loss: 0.5-2%

1. Off-Chain Signing:
   - Intents don't enter public mempool
   - Sent directly to Solver network
   - Prevents front-runner monitoring

2. Price Protection:
   - User specifies minimum receive amount
   - Solver must meet or exceed
   - Otherwise transaction reverts

3. Solver Competition:
   - Multiple Solvers bid
   - User gets best price
   - MEV value transferred to user

4. Batch Settlement (CoW):
   - No transaction ordering within batches
   - Cannot perform sandwich attacks
   - MEV structurally eliminated

Scenario: Swap 100 ETH for USDC on ETH/USDC pool

Traditional DEX (Uniswap):
- Expected price: 1 ETH = 2,000 USDC
- MEV attack loss: -1.5% = -3,000 USDC
- Actually received: 197,000 USDC

UniswapX (Intent):
- Signs intent: At least 199,000 USDC
- Solver competitive bid: 200,500 USDC
- Actually received: 200,500 USDC

Difference: +3,500 USDC (+1.8%)

// UniswapX Reactor Contract
contract DutchOrderReactor is IReactor {
    // User creates order (signature)
    function execute(SignedOrder calldata order) external {
        // 1. Verify signature
        _validateOrder(order);

        // 2. Check time and Dutch auction price decay
        ResolvedOrder memory resolvedOrder = _resolve(order);

        // 3. Execute order
        _fill(resolvedOrder, msg.sender);
    }

    // Resolve Dutch auction price
    function _resolve(SignedOrder memory order) internal view returns (ResolvedOrder memory) {
        DutchOutput[] memory outputs = order.outputs;
        uint256 elapsed = block.timestamp - order.startTime;
        uint256 duration = order.endTime - order.startTime;

        for (uint256 i = 0; i < outputs.length; i++) {
            // Linear price decay
            outputs[i].amount = outputs[i].startAmount +
                (outputs[i].endAmount - outputs[i].startAmount) * elapsed / duration;
        }

        return ResolvedOrder(order.input, outputs);
    }

    // Filler executes order
    function _fill(ResolvedOrder memory order, address filler) internal {
        // 1. Transfer input tokens from user
        order.input.token.transferFrom(order.swapper, address(this), order.input.amount);

        // 2. Filler executes swap (custom strategy)
        IFiller(filler).fill(order);

        // 3. Verify outputs meet requirements
        for (uint256 i = 0; i < order.outputs.length; i++) {
            require(
                order.outputs[i].token.balanceOf(order.outputs[i].recipient) >= order.outputs[i].amount,
                "Insufficient output"
            );
        }
    }
}

Order Parameters:
- Input: 1 ETH
- Output start: 1,800 USDC (minimum acceptable)
- Output end: 1,900 USDC (optimal price)
- Duration: 10 minutes

Price Decay:
t=0s:   1,800 USDC  ┐
t=120s: 1,820 USDC  │ Linear growth
t=240s: 1,840 USDC  │
t=360s: 1,860 USDC  │
t=480s: 1,880 USDC  │
t=600s: 1,900 USDC  ┘ (optimal)

Filler Strategy:
- Wait longer = Less profit but higher success rate
- Execute early = More profit but may be outbid
- Usually executes at t=400-500s (equilibrium point)

// Filler Contract Example
contract UniswapXFiller {
    IUniswapV3Router public router;

    function fill(ResolvedOrder calldata order) external {
        // Strategy 1: Execute via Uniswap V3
        if (canProfitFromV3(order)) {
            fillViaV3(order);
            return;
        }

        // Strategy 2: Use private inventory
        if (hasInventory(order.outputs[0].token)) {
            fillViaInventory(order);
            return;
        }

        // Strategy 3: Aggregate multiple DEXs
        fillViaAggregator(order);
    }

    function fillViaV3(ResolvedOrder calldata order) internal {
        // 1. Receive 1 ETH from Reactor
        // 2. Swap ETH → USDC on Uniswap V3
        router.exactInput(
            IUniswapV3Router.ExactInputParams({
                path: abi.encodePacked(WETH, uint24(500), USDC),
                recipient: order.outputs[0].recipient,
                amountIn: order.input.amount,
                amountOutMinimum: order.outputs[0].amount
            })
        );
        // 3. USDC sent directly to user
        // 4. Filler keeps spread profit (if V3 price > order price)
    }
}

Batch Time Window: 5 minutes

Collected Intents:
1. Alice: Sell 10 ETH, buy USDC (market price)
2. Bob: Buy 5 ETH, sell USDC (market price)
3. Carol: Sell 20,000 DAI, buy ETH
4. Dave: Buy 30,000 DAI, sell USDC

Solver Optimization Objective:
- Maximize total surplus within batch (user welfare)
- Prioritize internal order matching (CoW)
- Minimize external liquidity usage

Solver Execution Plan:
Step 1: Match Alice and Bob
- Alice sells 5 ETH → Bob buys 5 ETH
- No AMM needed, saves slippage and fees
- Alice has 5 ETH remaining to process

Step 2: Match Carol and Dave
- Carol's 20,000 DAI → Dave
- Part of Dave's 30,000 USDC used for Alice
- Swap difference via AMM

Step 3: Remaining orders use AMM
- Alice's remaining 5 ETH → Uniswap
- Dave's remaining 10,000 USDC → Curve

Result:
- 50% of orders matched via CoW
- Saves ~$100 in fees + slippage
- Users get better-than-market prices

Batch Auction Process:
T=0:00 - T=4:30: Collect intents
T=4:30 - T=4:50: Solvers submit plans
T=4:50 - T=5:00: Evaluation and execution

Solver Submission:
{
  "solver": "0x123...",
  "orders": [...],
  "executionPlan": {
    "cowMatches": [...],  // CoW matches
    "ammTrades": [...],   // AMM trades
    "gasEstimate": 500000
  },
  "totalSurplus": 15000  // Total user surplus (higher is better)
}

Selection Criteria:
1. Maximize total surplus (user welfare)
2. Reasonable Gas cost
3. Solver historical performance
4. Plan feasibility verification

Winning Solver:
- Executes the batch
- Earns spread (profit from plan optimization)
- Gains reputation points

Components:
1. Origin Chain Contract: Receives user intents
2. Relayer (Solver): Fast cross-chain transfer execution
3. Destination Chain Contract: Receives and records
4. Data Worker: Verifies cross-chain events
5. Optimistic Oracle (UMA): Dispute resolution

Timeline:
T=0:     User deposits 1 ETH on Ethereum, requests cross-chain to Arbitrum for USDC
T=0:30:  Relayer sends 1,800 USDC to user on Arbitrum
T=1:00:  Data Worker submits Merkle Root (proves cross-chain event)
T=1d-7d: Challenge period (anyone can dispute)
T=7d:    Final settlement, Relayer receives 1 ETH compensation on Ethereum

User experience: 30 seconds to complete cross-chain!

// Across V3 HubPool (Ethereum Mainnet)
contract HubPool {
    mapping(bytes32 => bool) public relayFilled;

    // Data Worker submits Merkle Root
    function proposeRootBundle(
        bytes32 poolRebalanceRoot,
        bytes32 relayerRefundRoot,
        bytes32 slowRelayRoot
    ) external {
        // Record Root
        rootBundles[bundleId] = RootBundle({
            poolRebalanceRoot: poolRebalanceRoot,
            relayerRefundRoot: relayerRefundRoot,
            slowRelayRoot: slowRelayRoot,
            proposalTime: block.timestamp,
            challenged: false
        });

        // Start 2-hour challenge period
    }

    // Relayer claims compensation
    function executeRootBundle(
        uint256 bundleId,
        bytes32[] calldata proof
    ) external {
        RootBundle storage bundle = rootBundles[bundleId];

        // Verify challenge period has passed
        require(block.timestamp > bundle.proposalTime + 2 hours, "Challenge period");
        require(!bundle.challenged, "Bundle challenged");

        // Verify Merkle Proof
        require(MerkleProof.verify(proof, bundle.relayerRefundRoot, leaf), "Invalid proof");

        // Compensate Relayer
        token.transfer(relayer, amount);
    }
}

Revenue:
1. Speed reward: Fastest execution earns extra rewards
2. LP fees: Share of cross-chain bridge fees
3. ACX token rewards: Protocol incentives

Costs:
1. Capital cost: Need to hold assets on multiple chains
2. Gas cost: Destination chain transfer Gas
3. Risk cost: 7-day fund lock-up period

Profitability Calculation:
Assuming: Ethereum → Arbitrum, 10 ETH cross-chain
- User pays fee: 0.1% = 0.01 ETH
- Relayer Gas cost: 0.001 ETH (Arbitrum)
- Relayer net profit: 0.01 - 0.001 = 0.009 ETH
- Annualized return (assuming 10 orders/day): 0.009 x 10 x 365 = 32.85 ETH

Traditional Cross-Chain Swap Flow:
1. Swap ETH for USDC on Chain A (DEX fees + slippage)
2. Bridge USDC to Chain B (bridge fees + wait time)
3. Swap USDC for target token on Chain B (more fees + slippage)

Total cost: Fees 0.3% x 2 + Bridge fee 0.05% + Slippage 0.5% x 2 = 1.65%
Total time: 20-30 minutes (or even hours)

User Operation:
1. Sign intent: Swap 10 ETH (Ethereum) for at least 18,000 USDC (Arbitrum)
2. Wait 30 seconds
3. Receive 18,200 USDC (Arbitrum)

Solver Backend Processing:
- May use private inventory to fulfill directly
- Or execute via optimal path
- User doesn't need to care about details

Advantages:
- One-click completion: No multi-step operations
- Better price: Solver competition + route optimization
- Faster speed: 30 seconds vs 30 minutes

Scenario: Swap 1,000 USDC from Polygon to ETH on Arbitrum

Traditional Approach:
1. Bridge Polygon to Ethereum: 10 minutes, $0.5 fee
2. Swap for ETH on Ethereum: $50 Gas, $3 slippage
3. Bridge ETH to Arbitrum: 20 minutes, $20 Gas
Total: 30+ minutes, $73.5 cost

Intent Approach (Across):
1. Sign intent: 1,000 USDC (Polygon) → ETH (Arbitrum)
2. Relayer executes: 30 seconds
3. Fee: $1.5
Total: 30 seconds, $1.5 cost

Savings: 97.9% cost, 99% time

Traditional Multi-Chain Applications:
- Users need to manually switch networks
- Need to hold Gas tokens on each chain
- Need to understand different chain characteristics
- Assets scattered across multiple chains

Intent-Driven Chain Abstraction:
User Experience:
1. Connect wallet (showing aggregated assets across all chains)
2. Execute action (e.g., "Buy NFT")
3. Application automatically selects optimal chain
4. Solver handles cross-chain and Gas tokens
5. User completes transaction seamlessly

// Socket Chain Abstraction API
contract SocketGateway {
    // User intent: Buy NFT from any chain with any token
    function executeIntent(
        Intent calldata intent
    ) external {
        // 1. Analyze user asset distribution
        UserAssets memory assets = _scanUserAssets(intent.user);
        // Assets: 100 USDC (Polygon) + 0.5 ETH (Arbitrum)

        // 2. Determine NFT chain and price
        // NFT: On Optimism, price 200 USDC

        // 3. Solver plans path
        ExecutionPlan memory plan = solver.plan(assets, intent);
        // Plan:
        // - Bridge Polygon USDC to Optimism
        // - Swap Arbitrum ETH to USDC then bridge to Optimism
        // - Buy NFT on Optimism

        // 4. Execute plan
        _execute(plan);
    }
}

// Frontend code (using Socket API)
async function buyNFT(nftId) {
  // 1. Create intent
  const intent = {
    type: "BUY_NFT",
    nftContract: "0x123...",
    nftId: nftId,
    maxPayment: { amount: "200", token: "USDC" },
    user: userAddress
  };

  // 2. Call Socket API
  const route = await socketAPI.getOptimalRoute(intent);
  // Route automatically handles:
  // - Asset bridging
  // - Token swaps
  // - Gas token sponsorship
  // - NFT purchase

  // 3. User signs intent
  const signature = await signIntent(intent);

  // 4. Submit for execution
  await socketAPI.execute(route, signature);

  // User experience: One-click purchase, no cross-chain details to worry about
}

Pimlico / Biconomy (ERC-4337 + Intent):

User Operation:
1. User signs intent (off-chain)
2. Intent includes: Pay Gas with another token (e.g., USDC)
3. Paymaster (Solver) fronts the Gas
4. Deducts equivalent amount from user's USDC

Technical Implementation:
┌─────────────────────────────────────┐
│ User Account Abstraction Wallet     │
│                                      │
│ Balance: 1000 USDC, 0 ETH           │
│                                      │
│ User Intent:                         │
│ - Action: Swap on Uniswap           │
│ - Pay Gas with: USDC                │
└─────────────────────────────────────┘
            ↓ (sign intent)
┌─────────────────────────────────────┐
│ Paymaster (Gas Sponsor)              │
│                                      │
│ - Validates intent                   │
│ - Pays ETH gas upfront              │
│ - Deducts equivalent USDC from user │
└─────────────────────────────────────┘
            ↓
┌─────────────────────────────────────┐
│ Transaction Executed                 │
│ User never needed ETH!              │
└─────────────────────────────────────┘

// Using Biconomy SDK
const smartAccount = new SmartAccount(config);

// User executes transaction, pays Gas with USDC
const tx = await smartAccount.sendTransaction({
  to: uniswapRouter,
  data: swapCalldata,
  feeQuotes: [
    { token: "USDC", amount: "2.5" },  // Gas priced in USDC
    { token: "DAI", amount: "2.5" }
  ]
});

// Behind the scenes:
// 1. Paymaster fronts 0.001 ETH Gas
// 2. Deducts 2.5 USDC from user's wallet
// 3. User experience: No ETH needed

User Intent:
- Input: 10 ETH
- Output: At least 25,000 USDC
- Validity: 24 hours

Solver Behavior:
- Monitors market prices
- Executes when ETH price ≥ $2,500
- Similar to limit orders on traditional exchanges

Advanced Features:
- Partial fills: Allow execution in batches
- Time-weighted: Change price over time (TWAP orders)
- Conditional triggers: Execute when certain conditions are met

// 1inch Fusion Limit Order
struct LimitOrder {
    address makerAsset;      // Asset to sell
    address takerAsset;      // Asset to buy
    uint256 makingAmount;    // Sell amount
    uint256 takingAmount;    // Minimum buy amount
    address maker;
    uint256 validUntil;      // Expiry
    bytes makerAssetData;
    bytes takerAssetData;
}

// Resolver executes limit order
function fillLimitOrder(
    LimitOrder calldata order,
    bytes calldata signature,
    uint256 takingAmount
) external {
    // 1. Verify signature and validity
    require(block.timestamp <= order.validUntil, "Order expired");
    _validateSignature(order, signature);

    // 2. Check if market price meets conditions
    uint256 currentPrice = _getMarketPrice(order.makerAsset, order.takerAsset);
    require(currentPrice * order.makingAmount >= order.takingAmount, "Price not met");

    // 3. Execute order
    _executeSwap(order, takingAmount);
}

User Pain Point:
- Large trades are vulnerable to sandwich attacks
- Loss of 0.5-2% of funds

Flashbots Protect + Intent:
1. User signs intent (not a transaction)
2. Intent sent to Flashbots Private RPC
3. Flashbots Searchers (Solvers) compete to execute
4. Best plan directly included in block
5. Transaction never enters public mempool

Result:
- Completely avoids sandwich attacks
- Gets better prices (Searcher competition)
- May even receive MEV Rebate (kickback)

Scenario: Swap 100 ETH → USDC

Public Mempool:
- Expected: 200,000 USDC
- Sandwich attack loss: -3,000 USDC
- Actually received: 197,000 USDC

Flashbots Protect + Intent:
- Intent: At least 199,000 USDC
- Searcher bid: 200,500 USDC
- MEV Rebate: +500 USDC
- Actually received: 200,500 USDC

Difference: +3,500 USDC (+1.8%)

Simplified Complex Operations:
Traditional: Bridge → Swap → Bridge again (3 steps, 30 minutes)
Intent: Sign intent (1 step, 30 seconds)

Reduced Cognitive Load:
- No need to understand AMMs, slippage, Gas concepts
- No need to hold Gas tokens on multiple chains
- No need to manually find optimal paths

Solver Advantages:
1. Private liquidity: Fulfill directly from inventory, no slippage
2. Route optimization: Find best paths across multiple DEXs
3. Batch settlement: Bundle multiple orders, reduce costs
4. Competition mechanism: Multiple Solvers bid, users benefit

Price Improvement Examples (Data from CoW Protocol):
- Average price improvement: 0.5-2%
- Fee savings: 30-50%
- MEV loss avoidance: 1-3%

Structural Protection:
- Intents don't enter public mempool
- Batch settlement eliminates transaction ordering
- Price guarantee mechanism

Value Redistribution:
- MEV value from miners/attackers → Users
- Solver competition passes profits to users

Unified Multi-Chain Experience:
- Users see aggregated cross-chain assets
- Applications automatically select optimal chain
- Seamless cross-chain operations

Developer Friendly:
- No need to develop separate frontends per chain
- Unified Intent API
- Faster application development speed

Problem:
- Solvers need large capital and technical capabilities
- High barriers lead to few Solvers
- A small number of Solvers control order execution

Data (UniswapX Early Stage):
- Top 3 Fillers account for 80%+ orders
- Some orders have only 1-2 Fillers competing
- Insufficient competition → Limited price improvement

Mitigation:
- Lower Solver barriers (permissionless)
- Transparent Solver performance data
- Decentralized Solver networks

Scenario: No Solver willing to execute

Causes:
1. Price requirements too high (market price cannot reach)
2. Insufficient liquidity (long-tail tokens)
3. Solver inventory shortage
4. Gas price spike (execution not economical)

Consequences:
- Order expires unexecuted
- User misses trading opportunity
- Negative user experience

Solutions:
- Fallback mechanism: Revert to traditional AMM
- Dynamic price adjustment: Allow Solver to negotiate price
- Incentive mechanism: Reward Solvers for executing edge orders

Challenges:
- Cross-chain message verification is slow (7-day challenge period)
- Relies on third-party bridges (security assumptions)
- Solvers need to lock large amounts of capital on multiple chains

Example (Across Protocol):
- Relayer stake: $100K+ per chain
- Fund lock-up period: 7 days
- Capital efficiency: Low (annual utilization <50%)

Improvement Directions:
- Faster cross-chain messaging layers (zkBridge)
- Liquidity aggregation networks (multiple Solvers share funds)
- Insurance mechanisms (reduce staking requirements)

Problem:
- User intents contain trading intentions and amounts
- Sent to Solver networks (off-chain)
- Solvers may analyze user behavior

Risks:
- Front-running (Solver malfeasance)
- Order flow selling (Solver sells info to third parties)
- User behavior tracking

Solutions:
- Zero-knowledge proofs (hide intent details)
- Encrypted intents (only Solver can decrypt)
- Solver reputation system (penalize malfeasance)
- Decentralized Solver network (reduce trust)

Current State:
- Multiple intent standards (ERC-7683, UniswapX, CoW, etc.)
- Different protocol formats are incompatible
- Solvers need to support multiple formats

Impact:
- Fragmented liquidity
- High Solver development costs
- Inconsistent user experience

Progress:
- ERC-7683 standardization (led by Uniswap, Across)
- Cross-protocol Intent routers
- Unified Solver SDK

Potential Issues:
- Are Solvers classified as "money transmission services"?
- Need MSB (Money Service Business) license?
- KYC/AML requirements?

Hypothetical Regulatory Scenario:
- Regulators require Solver registration
- Solvers need to KYC users
- Breaks the permissionless nature

Response:
- Decentralized Solver network (no single responsible party)
- On-chain Solvers (fully decentralized)
- Regulatory-friendly version + censorship-resistant version

Vision: Unified cross-chain intent standard

Supporting Protocols (2024):
1. Uniswap (UniswapX)
2. Across Protocol
3. 1inch
4. Socket
5. Li.Fi
6. Bungee
... 70+ protocols

Interoperability Benefits:
- Solvers only need to develop once
- Liquidity shared across protocols
- Users get best prices (more Solver competition)

Roadmap:
2024 Q4: ERC-7683 finalized
2025 Q1: Major protocol integration
2025 Q2: Cross-protocol Intent routing
2025+: Intents become mainstream DeFi paradigm

Vision: A dedicated chain layer for intent-driven execution

Architecture:
┌─────────────────────────────────────┐
│ Application Layer                    │
│ (DeFi Dapps)                        │
└─────────────────────────────────────┘
            ↓ (submit intent)
┌─────────────────────────────────────┐
│ Intent Layer (Rollup / Appchain)    │
│ - Intent Matching Engine            │
│ - Solver Auction                     │
│ - Cross-chain Verification          │
└─────────────────────────────────────┘
            ↓ (execute)
┌─────────────────────────────────────┐
│ Execution Layer                      │
│ (Ethereum, L2s, Alt-L1s)            │
└─────────────────────────────────────┘

Representative Projects:
- Anoma: Intent-centric Architecture
- SUAVE (Flashbots): Decentralized Block Building
- Essential: Intent Layer for Ethereum

Capabilities:
1. Real-Time Market Analysis
   - Monitor hundreds of DEX prices
   - Predict price movements
   - Optimal timing execution

2. Complex Strategy Optimization
   - Multi-hop route search
   - Cross-chain path planning
   - Gas cost optimization

3. User Intent Understanding
   - Natural language to intent conversion
   - Fuzzy intent parsing
   - Personalized recommendations

Example (Virtuals Protocol + Intent):
User: I want to buy the maximum possible ETH with my portfolio
AI Solver:
1. Analyzes user assets: 1000 USDC (Polygon) + 0.5 BTC (Bitcoin)
2. Plans path:
   - Bridge Polygon USDC to Arbitrum
   - BTC via THORChain to ETH
   - Aggregate on Ethereum mainnet
3. Timing selection: Monitor Gas prices, execute during lows
4. Result: User gets 1.23 ETH (3% more than direct execution)

Scenario: AI proactively suggests intents

Example:
AI Analysis:
- Detects user has 10,000 USDC idle in wallet
- Aave USDC deposit APY = 5%
- Gas prices are at a low point

AI Suggestion:
"Detected your 10,000 USDC is not generating yield.
Recommend depositing into Aave to earn 5% APY.
Estimated annual return: 500 USDC
One-click to execute?"

User clicks confirm → AI generates intent → Solver executes

Value:
- Proactively optimize user assets
- Lower DeFi usage barriers
- Improve capital efficiency

Hashflow: RFQ (Request for Quote) Model
- User requests quote (similar to intent)
- Market makers bid
- User accepts best quote
- No AMM, no slippage

Advantages:
- Zero slippage (quote is final price)
- MEV protection (off-chain matching)
- Native cross-chain support

Example:
Trade: 10 ETH → USDC (Ethereum → Arbitrum)
- User requests quote
- Market Maker A: 20,100 USDC
- Market Maker B: 20,200 USDC (best)
- User accepts, Market Maker B executes
- 30 seconds to complete cross-chain swap

Vision: Lending protocols support intents

Traditional Lending:
1. Deposit collateral
2. Manually borrow
3. Monitor health factor
4. Manually repay or add collateral

Intent-based Lending:
User intent: "I want to borrow 10,000 USDC, maximize yield, automatically manage risk"
Protocol executes:
- Automatically selects optimal lending pool
- Auto-rebalances collateral
- Auto-replenishes when health factor is low
- Auto-repays and migrates to lower-rate platform when rates spike

Example Protocol: Instadapp (automated strategies)

Problem:
- Intents expose user trading intentions
- Solvers can front-run
- Privacy leaks

Solution: zk-Intent (Zero-Knowledge Intent)

Technology:
User submits:
- zk-Proof: Proves intent is valid without revealing details
- Commitment: Hashed intent

Solver Executes:
- Blind Execution
- Cannot see actual intent content
- Only knows the post-execution result

Verification:
- On-chain zk-Proof verification
- Ensures Solver fulfilled commitment
- Unlocks funds

Projects:
- Penumbra: zk-Intent DEX
- Anoma: Private Intent Settlement

Design:
- Solver whitelist (licensed market makers)
- KYC/AML integration
- Transaction monitoring and reporting
- Jurisdictional restrictions

Hypothetical Case:
Uniswap Compliant Version (UniswapX Compliant):
- Solvers must register and complete KYC
- Users must pass KYC verification
- Transaction records automatically reported to regulators
- Sanctioned addresses prohibited from trading

Dual-Track:
- Censorship-resistant version: Fully decentralized, no KYC
- Compliant version: For institutions and conservative users
- Users choose freely