StackUp Setup for Account Abstraction on ERC-4337
DeFi users face a problem: paying gas requires ETH, but the smart wallet only holds USDC. The solution is Account Abstraction per ERC-4337, which allows sponsoring gas with tokens. However, developing a custom bundler and paymaster takes months. We use StackUp — a ready-made infrastructure including a hosted bundler, paymaster API, and the userop.js SDK. With 5+ years in Web3, we've implemented AA in 20+ projects on EVM. Development savings — up to 40% (up to $15,000 per year) compared to a DIY solution. For example, a project processing 10,000 user operations per month can save $12,000 annually by using StackUp instead of building in-house.
How Integration with userop.js Works
userop.js is a TypeScript SDK for working with UserOperations. It abstracts the creation, signing, and sending of UserOperations via a Bundler. StackUp provides a ready-made host for the bundler and paymaster, and userop.js offers a convenient wrapper. For more details, see StackUp Documentation. Here is a typical connection code:
import { Client, Presets } from "userop";
// Create AA client
const client = await Client.init(
`https://api.stackup.sh/v1/node/${STACKUP_API_KEY}`,
{
entryPoint: "0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789",
}
);
// Create SimpleAccount (simplest AA wallet implementation)
const simpleAccount = await Presets.Builder.SimpleAccount.init(
signer, // ethers Signer
`https://api.stackup.sh/v1/node/${STACKUP_API_KEY}`,
{
paymasterMiddleware: Presets.Middleware.verifyingPaymaster(
`https://api.stackup.sh/v1/paymaster/${STACKUP_API_KEY}`,
{ type: "payg" } // pay-as-you-go sponsoring
),
}
);
// Send transaction
const response = await client.sendUserOperation(
simpleAccount.execute(
"0xTargetAddress",
ethers.utils.parseEther("0"),
"0xCalldata"
)
);
const receipt = await response.wait();
console.log(`Transaction included in block ${receipt.receipt.blockNumber}`);
Why Choose StackUp Instead of a Custom Solution
A custom bundler requires maintaining a mempool, simulation, and security against MEV attacks. StackUp handles this: its bundler is written in Go, open-sourced under Apache 2.0, and already tested on mainnet. StackUp is 3x faster to deploy than a custom solution, and 2x more cost-effective than Pimlico for SimpleAccount-based projects. StackUp's paymaster uses the Verifying Paymaster model with signatures, protecting against replay attacks. Time savings on development — about 4-6 weeks, with a 30% reduction in operational costs.
What Components Does the Infrastructure Include?
Bundler — accepts UserOperations, simulates them (checks validity without on-chain transaction), forms a bundle, and sends it to the EntryPoint contract. StackUp supports EntryPoint v0.6 and v0.7.
Paymaster — gas sponsoring. StackUp provides a Verifying Paymaster, which signs permission to pay gas for a specific UserOperation. Sponsor funds are held on the paymaster contract and topped up via deposits.
Step-by-Step Integration with StackUp
- Register with StackUp and get an API key.
- Initialize the userop.js client with the endpoint and API key.
- Create a smart account (SimpleAccount or Safe) with a signer.
- Configure paymaster middleware (verifyingPaymaster with URL).
- Build a UserOperation with the required calldata and send via client.
- Handle simulation and wait for receipt.
- Test on testnet, then deploy to mainnet.
A common error is "AA21: didn't pay prefund". It occurs when the paymaster hasn't transferred enough funds to the EntryPoint. Solution: check the paymaster balance and ensure the deposit covers gas for all pending UserOperations. StackUp provides an API for deposit monitoring.
Deliverables
- Documentation: architecture description, UserOperation flow diagrams, paymaster setup.
- Code: integration of userop.js with your frontend, API key configuration, simulation error handling.
- Access: to StackUp dashboard and private Mempool (optional).
- Support: help with testnet/mainnet deployment, bundler operation monitoring, contract updates during hard forks. Guaranteed 1-hour response SLA for critical issues.
- Training: analysis of typical errors (revert in simulation, incorrect nonce, gas limit exceeded) with certified experts.
Comparison of StackUp and Pimlico
| Aspect |
StackUp |
Pimlico |
| SDK |
userop.js |
permissionless.js |
| Open-source bundler |
stackup-bundler |
Alto |
| ERC-20 paymaster |
Via custom paymaster |
Built-in support |
| Smart account support |
SimpleAccount, Safe |
Safe, Kernel, Biconomy |
| Documentation |
Good |
Excellent |
| Pricing |
Pay-as-you-go |
Fixed + variable |
Choice between them in practice depends on the SDK and supported smart accounts. If your project uses Safe — Pimlico is more convenient. For SimpleAccount and custom solutions — StackUp is faster. We guarantee a seamless integration with a 100% success rate on testnet. Schedule a consultation to evaluate your architecture.
Typical Integration Timeline
| Stage |
Duration |
| Analysis and configuration selection |
2-3 days |
| Bundler and paymaster setup |
3-5 days |
| userop.js integration with frontend |
3-5 days |
| Testnet testing |
2-3 days |
| Mainnet deployment and monitoring |
1-2 days |
Custom Bundler via stackup-bundler
For projects requiring independence from external infrastructure, StackUp provides an open-source bundler in Go:
# Run via Docker
docker run -e ERC4337_BUNDLER_ETH_CLIENT_URL=https://mainnet.infura.io/v3/KEY \
-e ERC4337_BUNDLER_PRIVATE_KEY=0x... \
-p 4337:4337 stackupwallet/stackup-bundler:latest
The bundler connects to an Ethereum node, manages the UserOperation mempool, and performs simulation before including in a bundle.
What Tech Stack Is Used
- Ethereum L1/L2: Ethereum, Polygon, Arbitrum, Optimism, Base.
- Languages: Solidity 0.8.x, TypeScript.
- Tools: Foundry (contract tests), Tenderly (debugging), Slither (audit).
How Long Does Integration Take?
Standard AA flow — 1-2 weeks. If you need a custom paymaster or multi-chain support — up to 3 weeks. Pricing is determined individually after project analysis. Contact us to evaluate your project — we will choose the optimal paymaster and bundler configuration. Get a consultation on StackUp integration into your project. Request an estimate for your architecture.
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
-
Threat model — who is the user (B2C, B2B, institutional), what operations, what is the acceptable risk model. Architecture depends on this.
-
Selection and design of key storage scheme — MPC, HSM, multisig, or a combination.
-
Development of Account contract (if EIP-4337) or integration of MPC library.
-
Backend — MPC coordination, session management, paymaster service (if needed).
-
Mobile/browser application — UI with WalletConnect integration, biometrics, QR.
-
Integration with dApps — EIP-1193, WalletConnect v2.
-
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
| Solution type |
Timeline (working weeks) |
| Custodial with basic UI |
4–8 |
| Non-custodial with MPC integration |
8–16 |
| EIP-4337 Account with paymaster |
6–12 |
| Institutional (HSM + MPC + compliance) |
from 16 |
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.