TL;DR: ERC-4337 account abstraction enables AI agents to operate smart wallets with programmable spending rules: session keys that authorize specific transaction types, spending limits per time period, and automatic yield deployment for idle balances. An ERC-4337 agent wallet can be configured to earn 4-7% APY on any USDC or USDT balance that exceeds a defined operational reserve, without requiring the agent to manage DeFi protocol interactions directly. RebelFi integrates with ERC-4337 smart wallets to provide the yield layer for AI agent platforms on Ethereum and Base.
Key Facts:
ERC-4337: Ethereum account abstraction standard enabling smart contract wallets
Session keys: authorize specific transaction types and amounts without full signing authority
Spending limits: programmable per-transaction, per-period, per-counterparty constraints
Auto-yield: idle balances above operational reserve earn 4-7% APY via DeFi lending
Non-custodial: agent platform retains master signing authority
Aave v3 (Ethereum, Base): $10B+ TVL, $1T+ cumulative volume, preferred EVM yield venue
Morpho: $4B+ TVL, isolated markets with higher rates for predictable agent balance patterns
How does tl;dr work?
ERC-4337 account abstraction replaces raw private key wallets with smart contract accounts, giving AI agents programmable spending controls, gas sponsorship in USDC, session keys, and batch transactions. For builders deploying autonomous agents that handle real money, ERC-4337 is the correct default account architecture because it makes spending policy enforceable at the contract level rather than trusting application code.
Why Are EOA Wallets the Wrong Architecture for AI Agent Payments?
The default wallet architecture for most early AI agent deployments is an externally owned account (EOA): a private key pair where the private key is stored in the agent's environment and used to sign transactions. This works at the prototype level. It fails at production for several reasons.
First, an EOA private key grants unlimited spending authority. If the key is exposed, through a software vulnerability, a prompt injection attack, or a supply chain compromise of a dependency, the attacker has full access to all funds. There is no spending limit, no recipient whitelist, no time delay. The agent's wallet can be drained in a single transaction.
Second, EOA wallets cannot batch transactions. Each action requires a separate transaction, each with its own gas cost and confirmation latency. An agent that needs to withdraw from a yield protocol and then execute a payment needs two sequential transactions, each requiring on-chain confirmation.
Third, EOA wallets require ETH for gas. An agent holding USDC must also maintain an ETH balance for gas, creating a second asset to manage. If the ETH balance runs low, the agent cannot transact regardless of how much USDC it holds.
ERC-4337 solves all three problems. It is not a trivial migration from EOA wallets, but for production agentic payment systems, it is the right architecture. Here is how it works.
What Are the Four Core Components of ERC-4337?
ERC-4337 introduces four new concepts that work together to replace the EOA model with smart contract accounts.
UserOperations are the fundamental unit of ERC-4337. Rather than broadcasting a raw transaction directly to the Ethereum mempool, an agent constructs a UserOperation: a structured object specifying the sender (the smart contract account), the calldata (what action to execute), the gas limits, and validation fields. The UserOperation is signed by the account's authorized key, but it is not a standard Ethereum transaction. It is submitted to a separate mempool maintained by bundlers.
Bundlers are specialized nodes that aggregate UserOperations from multiple users into a single on-chain transaction. The bundler calls the EntryPoint contract, a singleton contract that processes all ERC-4337 operations, with a batch of UserOperations. The bundler earns a priority fee for this service. From the agent's perspective, submitting a UserOperation is similar to submitting a transaction: you construct it, sign it, and send it to a bundler endpoint (often via an RPC API like Alchemy, Pimlico, or Stackup). The bundler handles the rest.
Paymasters are optional contracts that sponsor gas fees on behalf of users. For AI agents, the paymaster pattern is transformative. An agent holding only USDC and no ETH can still transact, provided a paymaster is configured to accept USDC in exchange for covering the ETH gas cost. The paymaster contract verifies that the agent has sufficient USDC, deducts the gas equivalent in USDC from the agent's account, and pays the actual gas in ETH on behalf of the agent. This eliminates the ETH balance management problem entirely.
The EntryPoint Contract is the singleton contract deployed at a canonical address on EVM chains that processes all ERC-4337 UserOperations. It calls the smart account's validation logic, handles paymaster verification, executes the intended operation, and handles refunds. The EntryPoint is the trust root for the entire ERC-4337 system: it enforces that accounts validate UserOperations before executing them.
How Do Smart Contract Accounts and Session Keys Protect AI Agent Funds?
The smart contract account is the centerpiece of ERC-4337 for AI agents. Unlike an EOA, the account is a contract with customizable validation logic. The account defines who can authorize spending, under what conditions, and with what constraints.
For AI agents, the most important capability is session keys. A session key is a temporary signing authority scoped to specific permissions. A platform deploying autonomous agents can create a session key for each agent with the following parameters: maximum spend per transaction ($50), approved recipient list (a set of pre-vetted service providers), expiration (session key valid for 24 hours), and total session budget ($500 before requiring re-authorization).
The agent uses its session key to sign UserOperations within these constraints. The smart account's validation logic enforces the constraints on-chain. Even if the agent's session key is compromised, the attacker can only spend within the defined parameters. The root signing key, held by the platform in an MPC wallet or HSM, retains full account control and can revoke session keys at any time.
This architecture makes it possible to give agents meaningful autonomous payment authority while maintaining enforceable, auditable spending controls. The security model shifts from "trust the agent application code to not overspend" to "the contract enforces the spending policy regardless of what the application does."
How does batch transactions and gas optimization work?
ERC-4337 smart accounts support atomic batch transactions: multiple operations executed in a single transaction, succeeding or failing together. For yield-aware agent wallets, this is particularly powerful. The sequence of withdraw-from-yield + pay-for-service, which requires two sequential transactions with an EOA wallet, can be executed as a single atomic batch operation with a smart account.
Aave has processed over $1 trillion in cumulative lending volume since its 2020 launch, with zero instances of lender principal loss. During the November 2022 CRV market stress event, a $100 million bad debt position was absorbed entirely by the Aave Safety Module, not by USDC depositors.
Atomic batching has important safety properties. If the payment transaction fails, the withdrawal also reverts. The agent does not end up with funds withdrawn from the yield protocol but sitting idle because the subsequent payment failed. The entire operation is transactional in the database sense: all or nothing.
Gas optimization through batching is significant. Two ERC-20 transfers as separate transactions cost roughly 2 x 65,000 gas. The same two transfers in a batched UserOperation cost approximately 1 x 110,000 gas, a 15% savings. Across millions of agent transactions, batching reduces operating costs meaningfully.
Book a call with our team if you are building agent infrastructure and want to understand how RebelFi's non-custodial yield deployment integrates with ERC-4337 smart accounts.
How does solana's native account model: the equivalent for non-evm agents work?
ERC-4337 is an EVM standard. For agents building on Solana, the chain's native account model provides equivalent flexibility through different mechanisms. Solana programs (smart contracts) have full control over the accounts they own. A program account can implement arbitrary authorization logic, spending controls, and multi-sig requirements.
Solana's nonce accounts provide replay protection without the ordered transaction nonce model of Ethereum, allowing agents to pre-sign transactions that can be executed later. Solana's transaction versioning supports address lookup tables, enabling complex multi-instruction transactions (equivalent to EVM batching) at lower cost. Kamino's yield protocol on Solana is designed for high-frequency deposit and withdrawal, making it well-suited for the rapid deposit-yield-withdraw cycles that agent wallets require.
For teams building cross-chain agent systems, RebelFi supports both Solana and EVM chains, providing consistent yield infrastructure regardless of which settlement layer the agent uses. Our non-custodial model works identically on both: we generate unsigned transactions, you sign them with your own keys.
How RebelFi Uses Smart Accounts for Non-Custodial Yield?
RebelFi's yield infrastructure for agentic platforms is designed to work natively with ERC-4337 smart accounts. Here is how the integration architecture works in practice.
At $10 million in average deployed float earning 6% APY, a fintech generates $600,000 per year in yield revenue with no changes to the user-facing product. RebelFi's 15% fee on yield generated leaves the fintech with $510,000 net annual yield revenue.
The platform's agent capital is held in an ERC-4337 smart contract account controlled by the platform's root signing key (held in MPC or an HSM). The account has a session key provisioned to RebelFi's infrastructure system with scoped permissions: it can execute deposit transactions to approved yield protocols (Aave, Morpho, Compound) and withdrawal transactions from those same protocols, but cannot transfer funds to arbitrary addresses.
RebelFi's infrastructure monitors yield rates, protocol utilization, and the account's idle balance. When idle capital exceeds a threshold, RebelFi generates a UserOperation to deploy it to the highest-yielding approved protocol and submits it via the session key. When an agent signals a pending payment, RebelFi generates a batch UserOperation that atomically withdraws from the yield protocol and transfers the required USDC to the payment recipient.
At no point does RebelFi hold custody of the funds. The smart account's validation logic enforces that our session key can only interact with approved protocol addresses. The platform can revoke the session key at any time, removing RebelFi's ability to generate yield transactions without any migration.
This non-custodial, session-key-scoped model is important for regulated financial platforms. RebelFi's role is clearly that of an infrastructure provider, not a custodian. For more on how this connects to the broader AI yield infrastructure landscape, see our piece on AI Agents and Yield-Aware Stablecoin Infrastructure.
What is The Developer Experience: Implementing ERC-4337 Today?
The ERC-4337 developer ecosystem has matured significantly in 2025 and 2026. Several production-ready SDKs and RPC providers make implementation accessible without requiring deep EVM expertise.
Pimlico provides a bundler and paymaster API that supports USDC gas sponsorship (ERC-20 paymasters) and is compatible with major smart account implementations including Safe, Biconomy, and ZeroDev.
ZeroDev provides a complete smart account SDK with session key management, gas sponsorship, and batching built in. It abstracts the bundler and paymaster complexity and provides a unified API for smart account operations compatible with LangChain and other agent frameworks.
Safe (formerly Gnosis Safe) provides multi-sig smart accounts widely used in production DeFi and treasury management. Safe's smart accounts support ERC-4337 UserOperations through the Safe4337Module, combining multi-sig governance with ERC-4337 functionality.
For AI agent builders, ZeroDev or Biconomy with a paymaster configured for USDC gas sponsorship is a practical starting point. The session key primitives are well-documented and designed explicitly for agent use cases.
For context on why smart contract infrastructure (not just messaging) is the right foundation for agentic finance, see our analysis: Why Agentic Finance Needs Smart Contracts, Not Just Messaging Protocols.
What should fintechs do next?
Morpho Protocol holds over $4 billion in total value locked in isolated lending markets on Ethereum and Base. Its per-market isolation means a problem in one collateral category does not affect USDC lenders elsewhere, providing a more conservative risk profile than pooled lending protocols.
ERC-4337 is not a future standard: it is deployed on Ethereum mainnet, Base, and other EVM chains today, with a mature ecosystem of bundlers, paymasters, and SDKs. For AI agents that handle real stablecoin balances, the migration from EOA wallets to smart contract accounts is the correct architectural move. It transforms spending policy from application-layer trust assumptions into contract-enforced guarantees.
RebelFi integrates natively with ERC-4337 smart accounts to provide non-custodial yield deployment on idle agent balances. Session keys, spending limits, and atomic batching make the yield layer both secure and operationally efficient. The result is an agent wallet architecture that earns yield, enforces policy, and pays for services, all within a single coherent smart contract account. For a broader view of how stablecoin yield works for businesses in 2026, see our Complete Guide to Stablecoin Yield for Businesses 2026.
What is ERC-4337 and why does it matter for AI agent wallets?
ERC-4337 is an Ethereum standard that introduces account abstraction: the ability to use smart contracts as wallets rather than raw private key pairs (EOAs). For AI agents, this matters because EOA wallets have unlimited spending authority and no programmable controls. A compromised EOA private key means total loss of funds. ERC-4337 smart contract accounts allow developers to define spending rules at the contract level: maximum transaction amounts, approved recipient whitelists, session keys that expire, and multi-sig requirements for large transfers. These rules execute on-chain and cannot be bypassed by application code. Additionally, ERC-4337 enables gas sponsorship through paymasters, allowing agents to pay transaction fees in USDC rather than requiring a separate ETH balance. For production AI agent deployments handling real stablecoin balances, ERC-4337 smart accounts are the correct default architecture because they provide enforceable, auditable spending controls rather than relying on trust in the agent's application code.
How do UserOperations differ from standard Ethereum transactions?
A standard Ethereum transaction is a signed object broadcast directly to the Ethereum mempool by an EOA. The sender, nonce, gas, and signature are all part of the transaction. A UserOperation is a different object: it represents an intended action by a smart contract account but is not itself a blockchain transaction. Instead, UserOperations are submitted to a separate alt-mempool maintained by bundlers. The bundler aggregates multiple UserOperations into a single on-chain transaction and submits it to the EntryPoint contract, which processes each UserOperation's validation and execution. This indirection has important benefits: it allows the smart account to define its own validation logic (not just ECDSA signature verification), enables paymasters to sponsor gas, and allows batching multiple operations atomically. For AI agents, UserOperations are submitted to a bundler RPC endpoint (Pimlico, Alchemy, Stackup) using standard APIs, abstracting most of the complexity from the agent developer.
What are session keys and how do they improve AI agent security?
Session keys are temporary, scoped signing authorities delegated by a smart contract account's root key. Rather than having the agent use the account's root signing key for every transaction, the platform creates a session key with defined constraints: it can only authorize transactions up to a certain dollar amount, only to pre-approved recipient addresses, and only until a specified expiration time or budget cap. The smart account's validation logic enforces these constraints on-chain. Even if the session key is compromised, an attacker can only act within the defined parameters. The root key, held securely in an MPC wallet or HSM, retains full account control and can revoke session keys at any time. For agentic platforms deploying many agents, session keys allow each agent to have its own signing authority without requiring separate key management infrastructure per agent. A single smart contract account can issue thousands of session keys with different scopes, all enforceable by the same on-chain validation logic.
How does ERC-4337 enable gas sponsorship for agents holding only USDC?
Kamino Finance on Solana holds over $1.7 billion in TVL, delivering 5-8% APY on USDC with sub-second deposit and withdrawal composability essential for high-frequency payment use cases.
ERC-4337 includes a paymaster mechanism that allows a third party to sponsor transaction gas costs on behalf of a user. For AI agents holding only USDC with no ETH balance, the USDC paymaster pattern works as follows: the agent constructs a UserOperation, the paymaster contract verifies that the agent has sufficient USDC, the paymaster covers the ETH gas cost from its own ETH balance, and the equivalent gas cost in USDC is deducted from the agent's account. The agent never needs to hold or manage ETH. This simplifies agent infrastructure significantly: the agent has one asset (USDC), one balance to monitor, and one token to manage for both payments and gas. Paymaster providers like Pimlico and Alchemy provide production-ready USDC paymaster contracts and APIs. This pattern is particularly important for agent platforms where individual agents may have small, variable balances, making ETH gas management across thousands of agent wallets an operational nightmare that USDC paymasters completely eliminate.
How does batch transaction support in ERC-4337 help yield-aware agent wallets?
ERC-4337 smart accounts support atomic batch transactions: multiple operations that execute together in a single transaction, succeeding or failing as a unit. For yield-aware agent wallets, batch transactions solve a specific problem. When an agent needs to pay for a service, the sequence is withdraw from yield protocol, transfer USDC to the service. With an EOA wallet, these are two separate transactions. If the first succeeds but the second fails, funds are withdrawn from the yield protocol but not delivered to the intended recipient. They sit idle until the agent retries. With ERC-4337 batch transactions, the withdrawal and payment execute atomically. If either operation fails, both revert. The agent never ends up in an inconsistent state. Additionally, batching reduces gas costs: two operations in one UserOperation cost less than two separate transactions. For high-frequency agent payment systems, the combination of atomicity and gas efficiency makes ERC-4337 batching a meaningful operational improvement over sequential EOA transactions.
Does ERC-4337 work on chains other than Ethereum, including Solana?
ERC-4337 is an EVM standard and is deployed on Ethereum mainnet, Base, Optimism, Polygon, and other EVM-compatible chains. It is not available on Solana, which uses a different account model. Solana's native architecture provides analogous capabilities through different mechanisms: Solana programs can implement arbitrary authorization logic for the accounts they own, nonce accounts enable pre-signed transaction queuing, and multi-instruction transactions provide batching equivalent to ERC-4337 batch operations. For teams building on Solana, the ZK compression developments and Solana's native program architecture provide the building blocks for sophisticated agent wallet logic without needing ERC-4337. RebelFi's yield infrastructure supports both EVM chains using ERC-4337 smart accounts and Solana using native program accounts, providing consistent non-custodial yield deployment regardless of which chain an agentic platform uses for settlement. The economic model is identical: idle balances earn yield, withdrawals are pre-generated, and the platform retains signing authority throughout.
Frequently Asked Questions
What is stablecoin yield infrastructure?
Stablecoin yield infrastructure is the software and API layer that routes idle USDC or USDT balances to DeFi lending protocols, generates interest income, and returns funds on demand. Enterprise stablecoin yield platforms like RebelFi handle protocol selection, position monitoring, yield optimization, and risk management, delivering a simple API interface: deposit, withdraw, and check balance. The underlying protocols — Aave, Morpho, Kamino, and Compound — are audited, overcollateralized lending markets where yield is generated by paying borrowers who post collateral exceeding the loan value. Lenders have never lost principal on Aave across $1 trillion in cumulative volume.
What APY can fintechs earn on stablecoin balances?
Fintechs deploying USDC through RebelFi earn 4-7% APY on the standard tier via Aave, Morpho, and Kamino. The managed tier delivers 7-11% APY using delta-neutral strategies that combine lending yield with basis trades and liquidity provision. Standard tier rates are variable and track real-time borrowing demand; managed tier rates are more stable due to their multi-strategy composition. At $10 million in average deployed float, the standard tier generates $400,000-$700,000 per year in gross yield. After RebelFi's 15% fee, the fintech retains $340,000-$595,000 annually.
How does RebelFi's non-custodial model work?
RebelFi generates unsigned yield transactions specifying the deposit amount, target protocol, and wallet address, then passes them to the client's key management infrastructure for signing. The client's HSM, MPC wallet, or hardware security module authorizes and broadcasts the transaction. RebelFi has no technical capability to move funds without client authorization. This non-custodial architecture means clients retain full on-chain custody, satisfy most e-money and payment license requirements without additional authorization, and maintain complete audit trails of all yield positions. The model is supported on Solana, Ethereum mainnet, and Base.
What protocols does RebelFi use for yield generation?
RebelFi routes yield through four audited protocols: Aave, Morpho, Kamino, and Compound. Aave has processed over $1 trillion in cumulative lending volume with zero lender principal losses. Morpho holds over $4 billion in TVL with isolated markets that prevent cross-market contagion. Kamino is Solana-native with $1.7 billion in TVL and sub-second composability for payment flows. Compound has operated since 2018 with a consistent risk track record. Protocol selection is automated based on real-time APY comparison, liquidity depth, and the client's chain and liquidity preference. Clients can override the routing to specific protocols if required by their compliance policies.
How long does integration take?
A fintech with existing USDC wallet infrastructure can integrate RebelFi's yield API in 2-4 weeks. Week one covers API authentication, sandbox testing, and initial deposit flows. Week two covers compliance review of the yield architecture — specifically the non-custodial transaction flow and treasury segregation model. Weeks three and four cover staging environment testing and production cutover with monitoring dashboards. Fintechs without existing USDC signing infrastructure may require an additional 2-4 weeks. Building equivalent capability in-house typically takes 6-18 months and costs $800,000-$2.4 million in engineering, compliance, and licensing expenses.
Is stablecoin yield compliant with financial regulations?
Stablecoin yield on company treasury funds is broadly compliant under most financial regulatory frameworks, including US money transmitter licenses, EU e-money institution frameworks, and UK FCA authorization. The critical compliance variable is the source of funds: yield on company treasury USDC is treated as ordinary investment income; yield on customer deposits faces additional restrictions under MiCA Article 54 and equivalent frameworks. RebelFi implements a three-wallet segregation architecture — operational wallet, yield wallet, and customer custody wallet — that satisfies most regulatory requirements. Fintechs receive a compliance documentation package for regulatory review.
What chains does RebelFi support?
RebelFi supports stablecoin yield on Solana, Ethereum mainnet, and Base. Solana is recommended for high-frequency payment flows requiring sub-second transaction finality and sub-cent transaction costs — Kamino on Solana delivers 5-8% APY with withdrawal finality in under 5 seconds. Ethereum mainnet provides the deepest liquidity through Aave and Morpho, appropriate for large institutional positions above $10 million. Base offers Coinbase infrastructure backing with Ethereum-level security at 10-100x lower transaction costs, suitable for mid-market fintechs. Arbitrum is not currently supported. Tron is on the roadmap.
What does RebelFi charge for yield infrastructure?
RebelFi charges approximately 15% of yield generated, calculated as a share of gross APY. There are no flat fees, setup fees, or minimum volume requirements on the standard tier. For a fintech with $10 million in deployed float earning 6% APY, the gross annual yield is $600,000; RebelFi's fee is $90,000; the fintech retains $510,000 net. The B2B2C pricing model for partners sharing yield with customers charges 15% of the partner's net margin rather than 15% of gross yield — ensuring RebelFi's fee scales with the partner's actual profitability. Enterprise volume pricing is available at $50 million or more in average deployed float.
If you are evaluating stablecoin yield infrastructure for your fintech, RebelFi's non-custodial API delivers 4-11% APY on USDC without touching your signing keys. Integration takes 2-4 weeks. **Schedule a 30-minute call with the RebelFi team** to see a live demo and get a yield estimate for your specific float volume.