Your contract can be perfect and the app still lose people
Wallet connection that works on a phone, sponsored gas for a first action, transaction states that tell the truth, and chain reads that load fast. We build that layer around your contracts, on real devices with real wallets.
Web3 fails at the front end, not usually at the contract
Ask someone what a web3 app is and they'll describe the contract. Then they use one, and what they judge is whether the wallet connected on their phone, whether the button said anything useful while the transaction sat in the mempool, and whether the page loaded before they gave up. Reading state straight from an RPC node is slow and rate limited. New users hold no gas. Transactions get replaced, dropped, and reverted, and every one of those needs a screen.
Villaex builds web3 applications with the discipline any product needs to survive real users: Next.js and React on the front, viem with wagmi for chain interaction, EIP-6963 discovery so every installed wallet is offered instead of whichever one loaded first, smart accounts for new users and EIP-7702 delegation for existing ones, subgraphs or a custom indexer for reads, and ordinary APIs and databases for everything with no business being on chain.
Then there's the detail that decides whether people finish: simulating a transaction before asking for a signature, scoping approvals to the amount at hand instead of an unlimited allowance, decoding revert reasons into readable messages, and surfacing indexer lag instead of hiding a stale number behind a fresh looking page. Wallets connect on mobile as well as desktop, and nobody is stopped at the gas step. The chain works quietly in the background.
From input to outcome
What a chain project moves through before it holds value, and what has to be true at each boundary before the next stage can run.
Scope & chain
What the chain is actually for, then the chain, the standards and the custody model.
- In
- The problem
- Out
- An architecture
Contracts & tests
Contracts written against a specification, with invariants, fuzzing and gas profiling.
- In
- An architecture
- Out
- Tested contracts
Review & audit
Internal review and static analysis, then an external audit, with findings fixed and retested.
- In
- Tested contracts
- Out
- Audited contracts
Mainnet & monitoring
Testnet rehearsal, verified deploy, then alerting on balances, privileged calls and indexer lag.
- In
- Audited contracts
- Out
- A system you can operate
Feedback edge
What monitoring catches on chain, and what support hears off it, feeds the next change and the next audit scope.
What we build and deliver
The application layer, engineered for real users.
Wallet Connection
EIP-6963 discovery, WalletConnect, mobile deep links, and embedded wallets in one tested flow.
Smart Accounts
ERC-4337 accounts and EIP-7702 delegation for sponsored gas, batching, and session keys.
Transaction States
Signing, pending, replaced, reverted, and confirmed, each with a screen that explains itself.
Transaction Simulation
Every transaction simulated before the app asks anyone for a signature.
Scoped Approvals
Approvals scoped to the amount at hand instead of granted without limit.
Indexing & Subgraphs
The Graph or a custom indexer into Postgres, so reads are fast and queryable.
Off-chain APIs
Ordinary services and databases for everything that doesn't belong on chain.
Where it creates value
Web3 front ends wherever real users have to get through them.
Payment dapps
Stablecoin sends and settlement. Clear states the whole way through. A receipt at the end that reads like one.
On-chain listings
Browsing runs fast off an indexer. Settlement is handled on chain.
Session key flows
Play without a signature prompt on every in-game action.
Ownership and provenance views
Token holdings, transfer history, and documents in one interface. The same chain records render as a readable timeline for non-crypto staff.
Internal consoles
Multisig queues, timelock windows, and treasury views for operations teams.
The return on the work
What a front end built for people returns.
- 0
- Gas at first useSponsored transactions remove the hardest step in web3 onboarding.
- Fast
- By defaultIndexed reads instead of live RPC calls on every page load.
- Plain
- Even the failuresEvery outcome explained, including reverts, replacements, and dropped transactions.
- Yours
- End to endFront end, indexer, and APIs owned by you, no rented platform.
Questions we get before we start
Still unresolved? A 30-minute conversation with an engineer usually settles it faster than another page of copy.
Often not, and we'll tell you honestly. If there's no shared ownership, no multi-party settlement, and nobody outside your company who needs to verify a record, a normal database is faster, cheaper, and easier to change later. We'd rather build the right thing.
That's a product decision, and it deserves a deliberate one. Self custody puts the user in charge and means a lost seed phrase is a lost account. Embedded wallets with social recovery, or a smart account with a recovery signer, keep support answerable. We weigh it against who your users are and what losing access would cost them.
Usually an EVM L2, because Base, Arbitrum, Optimism, and Polygon share tooling, wallets, and the account abstraction stack, so you aren't betting the product on one chain. Solana is a real answer when you need its throughput and fee profile, and it's a separate codebase with Anchor and its own wallet stack, not a config change.
The front end and the indexer have to move with them. We version ABIs, keep the client reading through a typed layer instead of scattered call sites, and plan the subgraph resync so history doesn't vanish mid migration. Upgrade windows are also where timelocks and multisig approvals surface in the interface.
You do, through a paymaster you fund, so it's a running cost worth sizing before you promise it. We scope sponsorship to the actions that matter, usually a user's first, with limits per user and per action so a script can't drain it. Existing wallets can be delegated under EIP-7702 rather than migrated to a new address.
Yes, and it usually should. Chain events flow into your database, CRM, accounting, and support tooling through ordinary APIs, so your team works where they already work instead of reading a block explorer. That integration is most of what makes the on-chain part useful.
Adjacent capabilities
Make web3 feel like software.
Show us the flow you want users to complete. We'll build the front end, the indexer, and the wallet experience that gets them through it.