Code that holds value, reviewed like it does
We write Solidity on EVM chains and Rust with Anchor on Solana. Specification first, invariants tested in Foundry, gas profiled, then rehearsed on testnet with the same scripts and multisig before anything reaches mainnet.
Solidity is the easy part and the discipline is the job
A smart contract is software with two properties most software never has: it's public, and it's permanent. Anyone can read it, anyone can call it, and whatever it holds is a standing bounty for the first person to find the mistake. Most of the losses that made headlines weren't exotic. They were reentrancy, an unchecked external call, or an oracle trusted further than it deserved.
So the discipline is different. You write the specification before the contract, state the invariants that must never break, then spend real effort trying to break them with unit, fork, fuzz, and invariant runs in Foundry. You profile gas, because on-chain cost is a product decision. And you decide upfront whether the contract is upgradeable, because an upgrade key is the real ownership of the system.
Villaex writes contracts to that standard, in Solidity on EVM chains and in Rust with Anchor on Solana where the project calls for it. We ship and operate production software, so we plan for the parts a tutorial skips: state updated before any external call, proxy storage layouts, timelock windows long enough for someone to actually object, signer sets that survive a person leaving, indexer lag that makes the UI lie, and a wallet flow that shows people what they're actually signing.
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 engineering that makes a contract safe to deploy.
Specification & Standards
A written spec, with ERC-20, ERC-721, ERC-1155, or ERC-4626 where a standard fits.
Invariant & Fork Testing
Unit, fork, fuzz, and invariant runs in Foundry, against live chain state.
Gas Profiling
Storage layout, loops, and calldata tuned so users aren't paying for shortcuts.
Upgrades & Key Control
Proxy storage safety, timelocks, and multisig rights chosen for real risk.
Review & Audit Prep
Internal review, Slither static analysis, and a clean handoff to auditors.
Testnet Rehearsal & Deploy
The same scripts and multisig run on testnet first, then mainnet, with the source verified on the explorer.
Post-Launch Monitoring
Alerts on events, balances, and privileged role changes once it's live.
Where it creates value
Contracts where a chain beats a database for a stated reason.
Payments and settlement
Stablecoin settlement wired into the off-chain ledgers. Reconciliation runs daily, so the two records agree.
Escrow and payouts
Escrow, milestone release, and fee splits enforced in code.
Multi-party workflows
Agreements between parties who trust the record more than each other.
Scheduled distributions
Vesting and revenue splits paid off a fixed schedule. Every party can read the schedule for themselves.
Assets and rewards
Minting and reward contracts users can move without asking you first.
Account abstraction
ERC-4337 accounts, so people transact without holding gas. No seed phrase required.
The return on the work
What careful contract engineering returns.
- Reviewed
- Before it holds valueInternal review first, then an independent firm scoped to the risk.
- Verifiable
- By anyoneSource published and matched to the deployed bytecode on the explorer.
- Timelocked
- Not unilateralUpgrades and privileged calls wait, in public, before they take effect.
- Reproducible
- DeploymentsThe same scripts run on testnet and mainnet, with addresses recorded.
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 contract earns its place when several parties need a record none of them controls, when settlement has to happen without a middleman, or when the asset itself lives on-chain. If a database and an audit log would do the job, that's the cheaper and faster answer.
EVM chains first: Ethereum and L2 rollups like Base, Arbitrum, and Optimism, plus Polygon, written in Solidity and tested in Foundry. We build on Solana with Rust and Anchor where the throughput or fee profile genuinely calls for it. The chain follows the requirements, it isn't the starting point.
We do internal review, static analysis, and invariant testing, but we don't sign off on our own work. Anything holding real value goes to an independent security firm, and that's their fee, scoped and paid separately from our build. Its size follows the contract's complexity and what it will hold, so we scope it with you before the build starts rather than surprising you at the end.
You do. Production admin and upgrade rights sit with your multisig, and Villaex doesn't hold production keys once handover is done. We document the signer set, the timelock windows, and the rotation path at deploy, so losing a person isn't an incident.
It depends on what the upgrade key is worth to an attacker. Upgradeability buys you the ability to fix a bug and costs you the guarantee that the rules can't change. We usually put upgrades behind a multisig and a timelock, or make the contract immutable and plan a migration instead. We rehearse either path on testnet with the same scripts and multisig we'll use on mainnet.
We verify the source on the explorer, watch events, balances, and privileged role changes, and keep the pause and upgrade runbook where the on-call person can find it. Contracts don't need patching every week, but the indexers, keys, and interfaces around them do.
Adjacent capabilities
Deploy something you can defend.
Bring us the rules you need enforced on-chain. We'll specify them, test them until they hold, and get them reviewed before anything touches mainnet.