Blockchain where it earns its place, and plain software where it doesn't
Some problems need a shared ledger and plenty don't. We build the ones that do: audited contracts, wallet and key handling, indexers, and the integration into the backends your business already runs on.
The contract is the easy part: the system around it isn't
A blockchain project can fail for reasons that have nothing to do with cryptography. A chain gets chosen before anyone asks what it is actually for, the contract ships without a second pair of eyes on it, and the product still needs a conventional backend, an admin panel, and a support team to be usable. The technology worked. The system around it didn't.
The tooling has caught up. Foundry and Hardhat make contracts testable the way normal software is testable, with fuzzing and invariant checks rather than hope. L2 rollups like Base, Arbitrum, and Optimism brought transaction costs low enough for products that touch a chain often. Account abstraction, through ERC-4337 and now EIP-7702, took the seed phrase off the first screen a user sees. The hard parts moved, but they didn't disappear.
Villaex builds these systems end to end. We write production software and integrate it for a living, so we treat a chain as one component among many, and we know the parts that demos skip: reentrancy guards and checks-effects-interactions, upgrade paths and timelock windows, gas profiling on testnet before mainnet, key custody and multisig thresholds, MEV and transaction ordering, indexer lag, and reorg handling.
What you get is a system your team can actually operate. Contracts with tests and a documented change history, a deployment you can verify on the explorer, an indexer feeding the database your reports already read from, admin actions behind a multisig and a timelock, and alerting that tells you when something on-chain moves. On-chain where it helps, off-chain where it belongs.
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.
Where this work usually breaks down
Blockchain is unforgiving. Deployed code is public, hard to change, and holding value soon after it lands.
Bugs you can't patch
A web bug gets a hotfix. A contract bug gets drained. Reentrancy, weak access control, and rounding errors stay live unless you designed an upgrade path first.
A chain picked blind
Teams choose a chain from a conference talk, then discover the fees, finality, or tooling don't suit the product. Migrating later means redeploying contracts and re-onboarding every wallet.
Wallets that lose users
Seed phrases, network switching, and failed transactions with hex error codes send ordinary users away before they finish a single action.
Keys nobody planned for
A deployer key on a laptop is an outage and a theft waiting to happen. Custody, rotation, and who can sign what are easy to leave until an incident forces the question.
The off-chain half
The chain holds a fraction of the state. Reporting, support, refunds, and reconciliation still run in your normal systems, and connecting the two is work nobody scoped.
We build and integrate production systems for a living. These are the parts that decide whether a chain project survives contact with users.
Review before deploy
Foundry fuzzing and invariant tests, static analysis with Slither and Semgrep, internal review, then an external audit. Findings are fixed and retested before the contract holds a cent.
Chain selection on evidence
We size transaction volume, fee tolerance, the finality you need, and the wallets your users already hold, then choose between Ethereum, an L2 such as Base, Arbitrum, or Optimism, Polygon PoS, and Solana.
Wallet UX that forgives
Account abstraction through ERC-4337 or EIP-7702, sponsored gas where it fits, embedded wallets for users who don't want one, and transaction states written in plain language.
Custody designed up front
Multisig ownership on Safe with named signers, timelocks on privileged functions, hardware-backed keys, and a documented path for rotating a key without pausing the product.
Wired into your stack
An indexer or subgraph turns on-chain events into rows your existing services query, so support, finance, and reporting see the state the chain does, within a lag you can measure.
What we build and deliver
The engineering that makes a chain safe to ship.
Smart Contract Engineering
Solidity contracts and Rust programs written with Anchor, carrying fuzz tests, invariants, and gas profiling before anything deploys.
Oracles & Price Feeds
Chainlink and custom feeds wired in with staleness checks, sanity bounds, and manipulation resistance the contract itself enforces.
MEV & Transaction Ordering
Slippage limits, deadline checks, and private submission wherever ordering can be exploited against your users or your treasury.
Tokens & Account Abstraction
ERC-20, ERC-721, and ERC-1155 done properly, with ERC-4337 or EIP-7702 accounts so users never meet a seed phrase.
Indexing & Subgraphs
The Graph, custom indexers, and event pipelines that make on-chain state queryable by your ordinary backend.
Testnet To Mainnet
A deployment path that runs through testnet first, with source verified on the explorer once it lands.
On-Chain Alerting
Alerting on balances, privileged calls, and indexer lag, running around the clock once the contracts are live.
Specialized services
Where it creates value
Blockchain where a shared ledger does work a database can't.
Stablecoin settlement
Payments settle on-chain. Reconciliation runs against the ledger you already keep.
Escrow and payouts
Contract-held funds released on conditions both sides can verify.
Parametric payouts
Claims release automatically. The trigger is whatever an agreed oracle confirms.
Cross-border payouts
Supplier and carrier payments that clear at weekends. No correspondent bank sits in the path.
Player-owned items
In-game assets on an L2, with wallets users never think about.
Shared records
One agreed record across parties who won't share a database.
The return on the work
What blockchain returns when it belongs.
- Audited
- And verified on the explorerExternal review completed and findings fixed while changes are still cheap, then published source matched to the deployed bytecode so anyone can read what runs.
- Timelocked
- And multi-signedPrivileged changes announced in advance and signed by more than one person.
- Integrated
- With what you runOn-chain state lands in the database your team already reads from.
How the work actually runs
From chain selection to mainnet, de-risked at every step.
Discovery
We start by understanding the business, not the brief. Workshops with your team map goals, constraints, data, and the metrics success will be measured against, before anyone writes a line of code.
Planning & Architecture
We translate the problem into a system: data flows, model choices, interfaces, integrations, and a delivery plan broken into milestones you can evaluate at each step.
Development
Senior engineers build in tight, two-week iterations. Every increment is reviewed, tested, and demoed, so progress is visible and course-corrections are cheap.
Testing & QA
Automated tests, security reviews, performance profiling, and human QA run continuously, not as an afterthought. We ship when it's genuinely ready.
Deployment
We harden infrastructure, set up CI/CD, observability, and rollback safety, then ship to production with a launch plan that protects uptime and data.
Support & Scale
After launch we monitor, optimize, and evolve. As usage grows, the architecture grows with it, and the same team that built it keeps it healthy.
The stack we build on
Contracts
Chains
Application
Keys & Infrastructure
Industry coverage
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 say so. A chain earns its place when parties who don't trust each other need to agree on one record, when assets have to move without an intermediary, or when public verifiability is the product itself. If a database and an audit log would do the job, that's the cheaper and faster answer. You almost never need a token to get the rest.
Tests first, in Foundry, including fuzzing and invariant checks against the properties that must never break. Then static analysis with Slither and Semgrep, then internal review, then an external audit by a firm that does nothing else. Findings are fixed and retested. We won't ship a value-holding contract without that, and we price it in from the start.
Three things: how much value the contracts hold, how much of the product is ordinary off-chain software, and the audit. The audit is a third-party engagement priced by the firm and by contract complexity, and it is often the largest single line in the budget, so we scope it early rather than discovering it late. We price the work in phases, so you can stop after chain selection and contract design if the numbers don't work.
It runs in phases: chain selection, contract design, implementation with tests, a testnet deployment your team can actually use, an audit window set by the auditor's queue rather than by us, fixes and a retest, then mainnet. The audit slot and your own off-chain integration work are the two things most likely to move the date, so we book the slot early.
Yes, through proxies, and it's a trade-off rather than a free option. Upgradeability means someone can change the rules, so we pair it with multisig ownership and a timelock, making changes visible before they take effect. Some contracts are better left immutable. We decide that contract by contract.
Through an indexer. On-chain events are read into a database your services already query, so support, finance, and reporting see the state the chain does, within a lag you can measure, and nobody has to run a node. Writes go the other way through a signing service with controlled key access and full logging. The keys stay yours, held in a multisig with named signers.
Adjacent capabilities
Build blockchain you can operate.
Tell us what you're trying to put on-chain and why. We'll tell you honestly whether it belongs there, then build it properly if it does.