Smart Contract Wallet Development (Account Abstraction)

Picture this: your user wants to send tokens but has no ETH for gas. Or needs to recover wallet access without a seed phrase, but the seed phrase is lost. A classic EOA wallet can't handle these scenarios. The solution is a smart contract wallet with Account Abstraction (AA). Our engineers have 10+ years of blockchain experience and have been building such wallets since the standardization of EIP-4337. Account Abstraction transforms a wallet from a passive key storage into a programmable agent. All logic lives in smart contracts, and a specialized mempool infrastructure (Bundlers and Paymasters) processes UserOperation objects instead of regular transactions. We have delivered 20+ projects on Ethereum, Polygon, and Arbitrum. Average gas savings when using a Paymaster are $0.5–2 per transaction. The cost of an external audit is discussed individually. Order your smart contract wallet development — get an engineer consultation within 2 days.

How Account Abstraction Changes Wallet Architecture

System Components — Smart Contract Development

A classic EOA transaction goes directly to the mempool and is executed by a node. In an AA system, the chain is different:

1. UserOperation — a pseudo‑transaction signed by the user. Contains callData, sender (smart wallet address), signature, gas limits, and Paymaster parameters.
2. Bundler — an off‑chain agent that collects UserOperations from the alternative mempool, packs them into one on‑chain transaction, and calls the EntryPoint. Existing implementations: Stackup, Pimlico, Alchemy Rundler (written in Rust, order of magnitude faster than the reference implementation).
3. EntryPoint — a singleton contract (0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 on most EVM networks), deployed by the ERC-4337 team. It verifies and executes the batch of operations. You cannot deploy your own EntryPoint — the ecosystem depends on this address.
4. Account Contract — the user's smart wallet itself. Must implement the IAccount interface with the validateUserOp method. This is where all custom logic lives.
5. Paymaster — an optional contract that pays gas for the user or accepts payment in ERC-20 tokens instead of ETH.

More details in the EIP-4337 specification.

Lifecycle of a UserOperation

User → sign UserOp → send to Bundler RPC
Bundler → simulate via eth_estimateUserOperationGas → validate signature + paymaster
Bundler → batch multiple UserOps → call EntryPoint.handleOps()
EntryPoint → validateUserOp() on each Account Contract
EntryPoint → Paymaster.validatePaymasterUserOp()
EntryPoint → execute callData
EntryPoint → postOp() on Paymaster (for gas accounting)

Important: simulation and execution are separate. The Bundler simulates using eth_callStateOverride and rejects operations that would fail on‑chain. This protects the Bundler from losing ETH on failed transactions.

What Is Factory and Counterfactual Deploy?

One key property of AA is that the wallet exists as an address even before deployment. CREATE2 with a deterministic salt (usually a hash of the owner address) gives a predictable address. The user gets the wallet address before the first transaction, can receive funds — the wallet is deployed automatically on first use.

contract WalletFactory {
    function getAddress(address owner, uint256 salt) public view returns (address) {
        return Create2.computeAddress(
            bytes32(salt),
            keccak256(abi.encodePacked(
                type(ERC1967Proxy).creationCode,
                abi.encode(address(implementation), initData(owner))
            ))
        );
    }

    function createAccount(address owner, uint256 salt) external returns (SmartWallet) {
        address addr = getAddress(owner, salt);
        if (addr.code.length > 0) return SmartWallet(payable(addr)); // already deployed
        return SmartWallet(payable(new ERC1967Proxy{salt: bytes32(salt)}(
            address(implementation), initData(owner)
        )));
    }
}

Implementing Gasless Transactions via Paymaster

Sponsoring Paymaster

contract SponsoringPaymaster is IPaymaster {
    mapping(address => bool) public whitelistedContracts;

    function validatePaymasterUserOp(
        UserOperation calldata userOp,
        bytes32,
        uint256 maxCost
    ) external returns (bytes memory context, uint256 validationData) {
        // Sponsor only calls to whitelisted contracts
        address target = address(bytes20(userOp.callData[16:36]));
        require(whitelistedContracts[target], "Not whitelisted");
        require(deposit() >= maxCost, "Insufficient deposit");
        return (abi.encode(userOp.sender), 0);
    }
}

The Paymaster must hold a deposit in the EntryPoint. The staking mechanism prevents DoS: a Paymaster without stake can sponsor at most one operation per bundle.

ERC-20 Paymaster

Accepts any ERC-20 as gas payment. An oracle is needed for conversion: Chainlink price feed or Uniswap V3 TWAP pool. Workflow: before execution, lock maxCost * exchangeRate tokens; after, deduct the actual cost through postOp.

Ready solutions: Pimlico ERC-20 Paymaster (open source), Stackup Paymaster SDK.

Implementing the Account Contract

Basic Structure

We base our work on SimpleAccount from eth-infinitism or SafeAccount from Safe (formerly Gnosis Safe). For production, we recommend Safe v1.4.1 with the 4337 module, as it is battle‑tested with $100B+ TVL.

Instead of providing the full code, we describe the key method validateUserOp. It checks the signature, nonce, and optionally pays for gas. validationData encodes three parameters: validation result (0 success, 1 failure), validAfter and validUntil timestamps (time‑bounded operations).

Extended Logic Patterns

Session keys. A restricted key (e.g., generated by a browser without exposing the seed phrase) that is allowed operations only on a specific contract, amount limit, and time window. Storage structure:

struct SessionKey {
    address key;
    address allowedContract;
    uint256 spendingLimit;
    uint48 validUntil;
    bool enabled;
}
mapping(address => SessionKey) public sessionKeys;

This is the foundation for "gasless gaming" — the user signs a session for the game contract once, and the game makes transactions on their behalf.

Social recovery. Guardians — trusted addresses that can change the owner after a timelock (usually 72 hours). The Argent implementation is a good reference: M‑of‑N guardians with cancellation within the timelock window if the owner is online.

Frontend Integration

Viem + permissionless.js is the most current stack (regularly updated). permissionless builds on Viem and provides abstractions for working with Bundler and Paymaster RPC:

import { createSmartAccountClient } from "permissionless";
import { signerToSimpleSmartAccount } from "permissionless/accounts";
import { createPimlicoBundlerClient } from "permissionless/clients/pimlico";

const smartAccount = await signerToSimpleSmartAccount(publicClient, {
  signer: walletClient,
  factoryAddress: FACTORY_ADDRESS,
  entryPoint: ENTRY_POINT_ADDRESS,
});

const smartAccountClient = createSmartAccountClient({
  account: smartAccount,
  chain: optimism,
  bundlerTransport: http(BUNDLER_RPC_URL),
  middleware: {
    sponsorUserOperation: paymasterClient.sponsorUserOperation,
  },
});

// Sending a transaction — identical to a regular wallet for the user
const txHash = await smartAccountClient.sendTransaction({
  to: contractAddress,
  data: encodeFunctionData({ abi, functionName: "doSomething" }),
});

ZeroDev SDK is an alternative with a higher level of abstraction, built‑in session keys, and the Kernel account (a popular Account Contract with a plugin system).

Alternatives to EIP-4337

zkSync Native AA — on zkSync Era, AA is built into the protocol, no separate EntryPoint needed. Every account can be a smart contract out of the box. More gas‑efficient, but tied to zkSync.

EIP-7702 (Prague/Electra) — upcoming Ethereum hard fork. Allows an EOA to temporarily delegate execution to a smart contract via a special transaction type. It doesn't fully replace 4337, but closes some use cases more simply.

Development and Estimation Stages

A minimum production‑ready wallet (single owner + sponsoring paymaster + frontend) takes 4–6 weeks of development. A full‑featured product with social recovery, session keys, and multi‑chain support takes 3–5 months. We will evaluate your project within 2 days — just send us your task description.

What Is Included in the Work

• Requirements analysis and architecture design
• Smart contract development (Account Contract, Factory, Paymaster)
• Integration with Bundler and Paymaster (Pimlico, Stackup, Alchemy)
• Frontend SDK using Viem + permissionless.js
• Testing (unit, integration, fuzzing via Echidna)
• Code audit (internal + external)
• Deployment to mainnet/testnet
• Documentation and team training
• Technical support for 3 months

A critical point when choosing a contractor: the validateUserOp implementation must be audited. An error in this function directly leads to loss of user funds. Saving on audit here is a conscious risk. Contact us for a preliminary assessment — we can tell you how to avoid typical mistakes. Get an engineer consultation today!

We develop crypto wallets turnkey — from custodial solutions for fintech to smart contract accounts on EIP-4337. 5+ years in blockchain development, 40+ projects implemented. Let's examine which architecture to choose for your task and why MPC or Account Abstraction solve the private key problem that MetaMask and classic HD wallets could not close.

Why are classic wallets dangerous for business?

A seed phrase in a browser extension is the only way to restore access. For retail users, this is a barrier to entry (lost phrase = lost money). For corporate treasuries, it is incompatible with compliance (KYC/AML, role model, multisignature). Any single key leak compromises all funds. These risks are built into the architecture, not poor UX.

We eliminate them at the protocol level: MPC wallets (key never fully assembled), smart contract wallets (authorization logic in code), hardware HSM for institutional storage. Details below.

What is the real difference between custodial and non-custodial?

Custodial — the provider stores the private key. User authenticates via email/password/OAuth. Recovery is trivial, KYC/AML built-in. For centralized financial applications, often the only regulatory acceptable option. Risk: single point of failure (e.g., Bitfinex hack — $72M, FTX — $600M+ client funds).

Non-custodial — keys are with the user. Provider has no access to funds. Storage responsibility falls on the user. For 99% of people, this model is unworkable without additional protection — hence MPC.

MPC wallets: the key that doesn't exist

Multi-Party Computation (MPC) is a cryptographic protocol that allows multiple parties to jointly sign a transaction without revealing their partial secrets. The private key never exists in its assembled form.

Standard scheme: 2-of-3 MPC between user (share on device), provider server, and backup cloud storage. Transaction is signed by any two of three parties. Lost phone — recovery via server + cloud. Server compromised — attacker holds only one share, signing impossible.

TSS (Threshold Signature Scheme) is a concrete implementation of MPC for ECDSA/EdDSA. Algorithms: GG18, GG20, CGGMP21 (the latter is faster and has better security proofs). Libraries: tss-lib (Go, from Binance), multi-party-sig (Go, from Coinbase), ZenGo-X/multi-party-ecdsa (Rust).

MPC requires no on-chain changes — to the blockchain, the signature looks like a normal single-key signature. This saves gas and keeps the key management scheme confidential (not published in chain) — unlike multisig.

Account Abstraction (EIP-4337): smart contract as wallet

EIP-4337 completely changes the model: instead of EOA (Externally Owned Account), a smart contract Account is used. Authorization logic is in contract code, not in protocol cryptography. This opens up arbitrary signing logic, social recovery, session keys, sponsored transactions, and batch operations.

How the EIP-4337 stack works:

User → UserOperation → Bundler → EntryPoint contract → Account contract
                                          ↑
                                    Paymaster (optional, pays gas)

UserOperation — a new type of object (not an L1 transaction). Bundler collects UserOps from an alternative mempool, packs them into one transaction, and sends to EntryPoint. EntryPoint calls validateUserOp on the Account contract — Account decides if the signature is valid.

Practical capabilities:

Social recovery. The contract stores a list of guardians (other addresses or a service). Lost key — guardians vote for replacement. Argent has used this scheme since 2020.

Session keys. A temporary key with limited rights: interaction only with a specific contract, until a certain date, up to a certain amount. For GameFi and dApps — user does not sign every micro-transaction.

Paymaster. A third-party contract pays gas for the user. Onboarding pattern: user does not hold ETH, gas is sponsored by dApp or taken from ERC-20 tokens.

Implementations: Safe{Core} Protocol, Biconomy SDK (Stackup), ZeroDev (Kernel), Alchemy (Rundler bundler). EntryPoint v0.6/v0.7 is deployed and active on Ethereum mainnet, Polygon, Arbitrum, Optimism. We guarantee compatibility with the latest contract versions.

What is a Hardware Security Module for corporate wallets?

For treasuries and institutional storage: HSM (Hardware Security Module). The key is generated and never leaves the secure chip. Signing happens inside the HSM. Hardware attestation is supported. Solutions used: AWS CloudHSM, Azure Dedicated HSM, Thales Luna, YubiHSM 2 (for small volumes). Integration via PKCS#11 or cloud-specific API.

A combination of HSM + MPC is optimal for institutional use: key shares are stored in HSMs on different servers/jurisdictions, signing via TSS. This ensures compliance with regulatory requirements (e.g., for crypto custodians).

Integration with dApps: WalletConnect and standards

Any wallet must be able to interact with dApps. Standard: WalletConnect v2 (Sign API): QR code or deep link, peer-to-peer encrypted channel via relay server. For browser extensions: EIP-1193 (Ethereum Provider API).

On the frontend, we use wagmi + viem — one interface for MetaMask, WalletConnect, Coinbase Wallet, injected providers. For Account Abstraction: EIP-5792 (wallet capabilities) and EIP-7677 (paymaster service).

Development process

1. Threat model — who is the user (B2C, B2B, institutional), what operations, what is the acceptable risk model. Architecture depends on this.
2. Selection and design of key storage scheme — MPC, HSM, multisig, or a combination.
3. Development of Account contract (if EIP-4337) or integration of MPC library.
4. Backend — MPC coordination, session management, paymaster service (if needed).
5. Mobile/browser application — UI with WalletConnect integration, biometrics, QR.
6. Integration with dApps — EIP-1193, WalletConnect v2.
7. Audit of contracts and cryptographic implementations — mandatory step. MPC libraries have known vulnerabilities (GG18 susceptible to attack with malicious participant without abort protocol). We use libraries with up-to-date security reviews (CGGMP21). Experience passing audits with Certik, Hacken, Trail of Bits — we have certificates.

What is included in the work (deliverables)

• Source code of smart contracts (Solidity/Rust) with documentation
• Backend MPC coordination service (Go or Rust) with API
• Mobile application (iOS/Android) or browser extension
• Integration with WalletConnect, Ledger/Trezor (if required)
• Preparation for security audit (vulnerability report)
• Administrator and user documentation
• Access to repository, CI/CD, monitoring (Tenderly, Etherscan API)
• Training of your team (2-3 sessions)
• Post-launch support — 1 month

Timeline and cost

Cost is calculated individually for your project. We will estimate within one day — contact us by email or Telegram. We provide a guarantee on code and timeline.

Typical mistakes in crypto wallet development (and how to avoid them)

• Using outdated MPC libraries — GG18 without abort protocol. Choose CGGMP21 or tss-lib with up-to-date audit reports.
• Tight coupling to a single blockchain — not abstracting for L2/sidechains. Use viem/wagmi for cross-chain.
• Ignoring MEV attacks — when using multisig without timelocks. Add tx simulation (Tenderly) and sandwiching protection.
• Lack of fallback recovery mechanism — for Account Abstraction, not setting up social recovery. Include from the first release.

We eliminate these pitfalls at the design stage — for each project, we create a threat model and security checklist.

Need a reliable wallet with no compromises? Get a consultation from our architect — we will analyze your task and propose an architecture with a precise estimate. Leave a request — we will respond within a day.