Build a dApp your users actually want to use.

Most dApps fail not because the contracts are wrong, but because the application built around them is unusable.

A DeFi protocol with correct contracts and a frontend that shows raw transaction hashes, gives no feedback during pending states, and requires users to understand gas estimation will not get adopted — regardless of how good the underlying protocol is. Web3 UX problems are engineering problems. Pending transaction states require streaming event subscriptions. Correct token balances require an indexer, not direct on-chain reads for every page load. Wallet connection that works across Metamask, Rabby, mobile wallets and WalletConnect requires a well-configured wallet connection library. These are all solved engineering problems. PROPELOO builds dApps where the blockchain complexity is handled by the application layer, not offloaded to the user.

The full dApp engineering stack.

A production dApp is not a frontend that calls a contract. It is a wallet integration layer, an indexing system, a transaction management engine and a user experience product.

System Layers

• Smart Contract Layer: Business logic on-chain — state management, access control, events, upgrade patterns
• Indexing & Data Layer: The Graph subgraphs or custom indexers for queryable on-chain data, historical events and analytics
• Wallet & Transaction Layer: Multi-wallet connection, transaction construction, gas estimation, pending state management, error handling
• Application Layer: React/Next.js frontend, data fetching, real-time updates via event subscriptions, responsive UI
• Infrastructure Layer: RPC provider redundancy, IPFS gateways, CDN, monitoring, RPC rate limiting

Core Technical Capabilities

• Wallet Connection & Integration

  wagmi + RainbowKit or ConnectKit for comprehensive wallet support — MetaMask, Coinbase Wallet, Rabby, WalletConnect v2 for mobile wallets. Account abstraction (ERC-4337) wallet support. Multi-chain switching with correct network detection.

• Transaction UX Engineering

  Transaction simulation before submission (Tenderly/Foundry fork), pending state feedback, success/failure handling, gas estimation with buffer, retry logic for failed transactions and transaction history display.

• On-chain Data Indexing

  The Graph subgraph development for queryable contract event history, custom indexers for complex query patterns, real-time event subscriptions for live UI updates, and historical data analytics.

• Multi-chain Architecture

  Chain abstraction layer supporting EVM chains (Ethereum, Arbitrum, Base, Polygon, BSC) with unified interface, correct chain detection, cross-chain state display and network switching UX.

• DeFi Frontend Engineering

  AMM trade interfaces with price impact display, lending position management with health factor visualisation, yield dashboard with APY calculation, governance voting UI and liquidity provision flows.

• RPC Infrastructure

  Multi-provider RPC setup with Alchemy/Infura/QuickNode failover, request batching via multicall, rate limit management, read-write RPC separation and WebSocket subscriptions for real-time contract events.

How we think about dApp engineering.

The blockchain is a database. A dApp is a product. The engineering challenge is building a product that abstracts the database's complexity so completely that users forget they are interacting with a blockchain.

• Never read directly from chain what you can index

  Reading token balances for 50 positions by making 50 separate eth_call requests is slow, expensive in RPC calls and will break under rate limits. An indexed subgraph or multicall batching returns all 50 balances in one query. On-chain reads should be reserved for real-time critical data. Everything historical or aggregate should come from an indexer.

  Axiom:

• Transaction UX is the product experience

  The moment between a user submitting a transaction and receiving confirmation is the most anxiety-producing moment in any dApp. Pending transaction indicators, estimated confirmation time, clear success and failure states, and automatic retry on network congestion are not polish — they are the core product experience. A dApp that shows "Transaction submitted" and then nothing until a page refresh will not retain users.

  Axiom:

• Simulate before you submit

  Transaction simulation using Tenderly or a local Foundry fork lets the application know whether a transaction will succeed before it is broadcast. A transaction that will fail can show the user an error message before they pay gas. This is the single highest-impact improvement to DeFi UX — users should never pay gas for a transaction they know will fail.

  Axiom:

• RPC reliability is user reliability

  A dApp that depends on a single RPC endpoint will be broken whenever that endpoint is degraded — which happens regularly. Multi-provider RPC with automatic failover (Alchemy → Infura → public RPC) means provider outages are invisible to users. Public RPC endpoints are not acceptable for production dApps — rate limits are aggressive and latency is high.

  Axiom:

The decisions that define a dApp.

Each choice determines the developer experience, user experience and long-term maintainability.

• ethers.js vs viem vs web3.js?

  Impact: For new EVM dApps: viem is the modern choice with better TypeScript integration and lighter bundle. ethers.js is acceptable and has the larger existing ecosystem. web3.js should not be chosen for new projects.

  • ethers.js v5 — most widely used, large ecosystem, slightly heavier bundle
  • viem — TypeScript-first, lighter bundle, better type inference, wagmi v2 default
  • web3.js — legacy, large bundle, falling out of favour
  • @solana/web3.js — Solana-specific, required for Solana dApps

• Wallet connection library?

  Impact: wagmi + RainbowKit is the production standard for EVM dApps. It handles the long tail of wallet edge cases (mobile deep links, wallet detection, chain switching) that a custom implementation will get wrong. Use it unless you have a specific reason not to.

  • wagmi + RainbowKit — most complete, beautiful UI, large wallet support, wagmi hooks
  • wagmi + ConnectKit — alternative UI, same wagmi foundation
  • Web3Modal — WalletConnect's official library, good cross-chain support
  • Custom implementation — maximum control, significant maintenance burden

• On-chain data fetching strategy?

  Impact: Direct eth_call for real-time critical data (current price, user balance). Multicall for batching multiple related reads. The Graph for historical data, event history and complex queries. Custom indexer only when The Graph query limitations are genuinely constraining.

  • Direct eth_call on render — simple, slow for complex state, expensive in RPC calls
  • Multicall batching — multiple reads in one request, significant performance improvement
  • The Graph subgraph — queryable indexed events, historical data, requires subgraph deployment
  • Custom indexer — maximum query flexibility, highest engineering cost

• Real-time updates?

  Impact: WebSocket event subscriptions from the contract are the correct mechanism for real-time dApp updates — price changes, position updates, new events. Polling adds unnecessary RPC load and creates stale UI between polls.

  • Polling (refetch every N seconds) — simple, predictable, unnecessary RPC load
  • WebSocket event subscriptions — real-time, efficient, requires WebSocket RPC
  • The Graph subscription — real-time indexed events, requires GraphQL subscription endpoint
  • Optimistic updates — immediate UI response, rollback on failure

• Multi-chain support?

  Impact: EVM multi-chain is achievable with a well-designed chain configuration layer. EVM + Solana requires essentially two separate dApp codebases with different wallet and signing models. Only pursue cross-ecosystem multi-chain when your user base genuinely requires both.

  • Single chain — simple, faster to build, limits addressable market
  • EVM multi-chain (same contract address) — one codebase, multiple deployments, manageable
  • EVM multi-chain (different addresses) — requires address registry, chain-specific configuration
  • EVM + Solana — different SDKs, different wallet libraries, significant engineering complexity

• Contract interaction pattern?

  Impact: For simple dApps: direct frontend reads with server-side writes via authenticated API. For dApps targeting mainstream users: ERC-4337 account abstraction eliminates the gas UX problem entirely. Gasless via relayer is the intermediate option for EVM chains without native AA support.

  • Direct reads/writes from frontend — simple, works for simple dApps, leaks RPC keys
  • Backend API proxy — RPC key server-side, rate limit control, adds latency
  • Gasless transactions via relayer — user signs, relayer pays gas, requires ERC-2771 or ERC-4337
  • Account abstraction — smart account handles gas, batching, session keys

What PROPELOO builds.

• DeFi Protocol Frontend

  AMM trading interface with price impact, slippage settings and transaction simulation. Lending dashboard with health factor, liquidation price and position management. Yield vault interface with APY calculations and deposit/withdraw flows.

• NFT Marketplace dApp

  Collection browsing, listing, bidding and purchasing — with real-time price feeds, trait filtering, offer management and wallet portfolio display.

• DAO Governance Interface

  Proposal creation and voting interface with delegation, voting power display, proposal execution tracking and treasury management dashboard.

• Web3 Gaming Frontend

  In-game asset management, marketplace for game items, tournament interface, leaderboards and wallet-connected player profiles.

• Token Launch Platform

  ICO/IDO frontend with KYC integration, allocation display, vesting schedule visualisation, claim interface and post-launch token analytics.

• Cross-chain Bridge UI

  Multi-chain bridge interface with route selection, fee comparison, transaction status tracking across source and destination chains and historical transfer display.

The dApp engineering stack.

Each layer requires specific tooling. The combination determines DX, UX and reliability.

• Chain Interaction

  Stack: viem, ethers.js v6, wagmi v2, @solana/web3.js, Anchor (Solana)

• Wallet Connection

  Stack: RainbowKit, ConnectKit, Web3Modal, Solana Wallet Adapter, Dynamic.xyz

• Indexing

  Stack: The Graph (subgraph), Ponder, Moralis, Alchemy NFT API, Custom indexer (Node.js + PostgreSQL)

• Frontend

  Stack: Next.js, React, TypeScript, TanStack Query, Zustand, Tailwind CSS

• RPC & Infrastructure

  Stack: Alchemy, Infura, QuickNode, Tenderly (simulation), Multicall3

• Account Abstraction

  Stack: ERC-4337 EntryPoint, Pimlico, ZeroDev, Biconomy, Safe{Core}

dApp security extends beyond the smart contracts.

The application layer introduces attack surfaces that contract audits do not cover.

• Wallet Drainer Prevention

  Wallet drainer attacks use malicious transaction payloads disguised as legitimate interactions — approve() calls with unlimited allowances to attacker-controlled contracts, setApprovalForAll() for NFT collections, or signature phishing for off-chain typed data. Transaction simulation before submission detects suspicious token approvals. Clear display of what a transaction will do — not just raw hex — is required for user safety.

• Frontend Injection & XSS

  React's JSX escaping prevents most XSS, but dangerouslySetInnerHTML, URL injection in href attributes and prototype pollution in JSON parsing are still vectors. Content Security Policy headers, Subresource Integrity for CDN assets, and input sanitisation for any user-generated content displayed in the dApp are required mitigations.

• RPC Endpoint Security

  RPC API keys exposed in frontend bundles can be extracted and abused for rate limit exhaustion or paid-tier consumption. API keys must be server-side with appropriate CORS and rate limiting. Public RPC endpoints (no key) are rate-limited aggressively and unreliable for production. Use a proxy API route to forward RPC calls without exposing keys in the browser.

• Signature Phishing

  Off-chain signatures (EIP-712 typed data, personal_sign) can be crafted by malicious dApps to authorise token transfers, NFT approvals or protocol parameter changes without a transaction. Always display the full decoded signature content to users before they sign — not just "Sign this message to continue." Verify that signature requests include the correct contract address and chain ID.

• Smart Contract Interaction Validation

  dApp frontends that construct transaction calldata must validate inputs before submission — preventing integer overflow in amount fields, validating address checksums, confirming allowance amounts match user intent, and checking slippage parameters are within expected bounds. The contract enforces correctness; the dApp should prevent invalid inputs from reaching the contract in the first place.

• IPFS & Metadata Security

  dApps that display content from IPFS or external URLs are vulnerable to content injection if the content is not validated before rendering. NFT metadata from arbitrary IPFS hashes could contain malicious SVG content with script tags, phishing links, or social engineering content. Content validation, sanitisation of SVG before rendering, and URL validation before linking are required for dApps that display community-sourced content.

From contracts to production dApp.

1. 01. Architecture Design

   Smart contract interface definition, data indexing strategy, wallet connection approach, multi-chain configuration and RPC infrastructure planning.

2. 02. Contract Integration

   ABI type generation, contract hook development with wagmi, read/write function wrappers, error handling and transaction status management.

3. 03. Data Indexing

   The Graph subgraph development for contract events, historical data queries and real-time subscriptions. Custom indexer for complex query requirements.

4. 04. Frontend Development

   Next.js application, UI components, wallet connection integration, data fetching with TanStack Query, real-time event subscriptions and responsive design.

5. 05. Transaction UX

   Transaction simulation, pending state management, gas estimation, error message decoding, success feedback and transaction history.

6. 06. Security Review

   Frontend security review — XSS prevention, RPC key exposure, signature phishing prevention, wallet drainer detection patterns.

7. 07. Production & Monitoring

   RPC multi-provider setup, error monitoring (Sentry), analytics, performance monitoring and incident response for RPC/indexer outages.

Frequently Asked Questions