Frequently Asked Questions
Should we build on EVM or Solana?
Build on EVM (Ethereum, Arbitrum, Base, Polygon) if: you need maximum wallet ecosystem compatibility (MetaMask, WalletConnect support every EVM chain), you are integrating with existing DeFi protocols, or your team has Solidity experience. Build on Solana if: you need very high throughput at very low cost, your product requires sub-second confirmation times, or you are targeting a Solana-native user community. The decision should follow where your target users and liquidity already exist.
What is account abstraction and should we use it?
Account abstraction (ERC-4337) replaces standard Ethereum accounts (EOAs) with smart contract wallets. This enables: gasless transactions (paymaster sponsors gas), session keys (users approve once, execute many), social recovery (recover wallet via email or guardians), batch transactions and custom security rules. For consumer-facing products targeting non-crypto-native users, account abstraction is increasingly the correct default. It adds engineering complexity but dramatically improves the onboarding experience.
How do we handle users who lose their wallet or private key?
For EOA wallets: private key loss means permanent loss of access — there is no recovery. This is why consumer Web3 products should use account abstraction with social recovery built in. ERC-4337 smart accounts support guardian-based recovery (email, other trusted wallets) and can be designed with time-locked recovery to prevent theft. Embedded wallet providers (Privy, Dynamic) add email-linked key backup. This decision must be made at architecture time — recovery mechanisms cannot be added to deployed EOA wallets.
How do we make Web3 transactions gasless for users?
Gasless transactions require ERC-4337 account abstraction with a paymaster. The paymaster is a smart contract that sponsors gas fees for whitelisted transaction types. Implementation: deploy a paymaster (or use a managed one from Alchemy, Biconomy, ZeroDev), fund it with ETH, whitelist the transaction types you want to sponsor, implement per-user daily limits to prevent exploitation. The cost of gas sponsorship must be factored into your unit economics — typically $0.01-0.20 per transaction on L2s.
What is the best way to connect wallets in a Web3 product?
WalletConnect v2 (via RainbowKit or ConnectKit) provides the broadest wallet compatibility for both desktop and mobile — supporting MetaMask, Coinbase Wallet, Trust Wallet and hundreds more. For embedded wallet experiences without browser extensions, Privy or Dynamic provide social login + embedded wallet for new users. The architecture should support both: WalletConnect for power users with existing wallets, embedded wallet for new users onboarding without prior crypto experience.
How do you query on-chain data fast enough for a good UX?
Direct RPC calls for every piece of on-chain data produce slow, expensive dApps. Production Web3 apps use: The Graph subgraphs for historical indexed data (millisecond query times), Alchemy/Moralis APIs for NFT and token data, WebSocket subscriptions for real-time event updates and multicall contracts for batching multiple reads into one RPC call. The indexing strategy must be designed before frontend development — retrofitting an indexer changes the data model and every query that depended on it.
How do we handle transaction failures gracefully?
Every transaction can fail: insufficient gas, slippage exceeded, contract reverted with a specific error, network congestion, wallet rejection. Each failure mode requires a specific UI state with an actionable explanation. Implementation: simulate transactions before submission (Tenderly/Alchemy simulation API), parse contract revert reasons from the error data, display gas estimates with a buffer, handle wallet rejection (user cancelled) separately from transaction revert, and implement retry flows for network failures.
Do we need a smart contract audit?
Yes — for any contract that holds user funds, executes financial logic, or manages access rights. A smart contract audit by a specialist firm (Trail of Bits, OpenZeppelin, Spearbit, Code4rena) is required before mainnet deployment of any contract holding real value. The audit process requires: comprehensive test coverage, natspec documentation and an invariant specification. Internal security review (Slither, Foundry fuzzing) should precede the third-party audit.
Can we build a Web3 product for mobile?
Yes — mobile Web3 products are increasingly common. Options: React Native with WalletConnect v2 (broad wallet support, deep links for wallet connection), in-app embedded wallet (Privy/Dynamic React Native SDKs, no external wallet required), or a mobile-optimised web app (PWA) with WalletConnect. Mobile Web3 requires careful wallet connection UX — deep link handling for wallet redirects, session persistence and mobile-specific gas UX. Native iOS/Android dApp browsers (MetaMask Mobile, Coinbase Wallet) have specific integration requirements.
How long does a Web3 product take to build?
A Web3 product with smart contracts, dApp frontend, wallet integration, indexing and security review takes 12-24 weeks from architecture to mainnet launch. Products reusing existing audited contracts (OpenZeppelin standards, existing DeFi protocols) are faster than products with custom contract systems. The smart contract audit cycle (4-6 weeks) typically gates the mainnet launch. We deliver in milestone-based sprints with testnet deployments at each stage.
