Account Abstraction Development (ERC-4337)

We build the full smart-account stack rather than the contract alone. That means the smart-account contracts themselves (modular accounts with ERC-4337-compatible validation, signature schemes, and upgrade paths), plus integration with bundlers and the `EntryPoint`, and the off-chain plumbing (RPC, indexing, monitoring) that keeps `UserOperation` flows observable in production.

On top of the account we implement session keys: scoped, time-limited permissions that let a game or trading app act on a user's behalf without a signature per click, while capping what those keys can do. We implement social recovery so a user who loses a device restores access through guardians or trusted signers instead of a seed phrase.

Each capability is a contract module plus the UX around it. We ship both, and harden the contracts before they reach an audit. Benefits: one team for contracts and product · session keys without over-granting · recovery that removes the seed-phrase failure mode.

A paymaster is the contract that decides who pays for a transaction, and it is what makes "gasless" onboarding real. We build paymasters that let your app sponsor gas entirely (a user touches the product with zero ETH), let users pay gas in an ERC-20 such as a stablecoin, or apply policy: sponsor the first N actions, sponsor only whitelisted calls, or sponsor up to a budget.

The engineering risk lives in the rules: an open sponsorship policy is a drain that can be griefed, so we design verification, rate limits, and abuse controls alongside the happy path. Fee-abstraction UX is not new territory for us: we have shipped gasless transaction experiences in production for CoW Swap, so we scope the operational cost and failure modes from experience, not theory. Benefits: onboard users with no ETH · pay gas in stablecoins · sponsorship policies that can't be drained.

Account abstraction earns its keep on mobile, where seed phrases and gas top-ups cause the most drop-off. We build the wallet experience for iOS and Android-integrated products: passkey or device-key signing instead of a seed phrase, gasless first actions so the app works before a user funds anything, and recovery flows that fit a phone, not a desk.

We have shipped full production wallets: Telos zkWallet bundled smart contracts, relayer services, and indexing infrastructure into a cross-platform app with native proof generation. We treat a wallet as a product with infrastructure behind it, not a screen bolted onto a contract.

For account abstraction we apply the same discipline: the smart account, the sponsorship backend, and the mobile UX designed as one system. Benefits: no seed phrase on a phone · the product works before funding · wallet, backend, and UX shipped as one.

Account abstraction development fits two profiles. Consumer and DeFi app teams use it to cut onboarding friction (gasless first actions, social recovery, and session keys that remove a wallet popup from every interaction) when drop-off at the wallet step is costing real users. Institutional and treasury teams use smart accounts for the opposite reason: programmable controls, spend policies, multisig, and recovery that meet an internal security model.

The common requirement is an EVM-compatible target and a real product to integrate into, rather than a research exercise. If you are deciding between an internal build and a partner, the case for a partner is exactly that the smart-account, paymaster, and recovery pieces are easy to get subtly wrong, and expensive to get wrong in code that holds funds. Benefits: lower onboarding drop-off for consumer apps · policy and recovery controls for institutions · one EVM-ready integration, scoped in milestones.