Written to be audited, deployed behind a timelock.
Smart contract engineering is writing code that will hold other people's money and proving it is safe before it does. neoForge™ delivers Solidity, Rust, and Move contracts with a written specification, machine-checked invariants fuzzed against millions of states, three independent audits per release, a public testnet run of the exact bytecode, and a 24-hour timelock on every privileged deploy.
NeoFund.sol · invariant run
4.81M casescounterexample
burn(amount=3) across 7 holders → 1 wei unaccounted
1 property violated · release blocked
3
Independent audits per release
4.8M
Fuzz cases in a typical run
24h
Timelock before privileged deploy
0
Unaudited contracts holding value
Six stages from specification to deploy
Specification, implementation, invariant testing, three audits, public testnet, and a timelocked deploy. Each stage has a written exit criterion.
Stage 1
Specification before syntax
Every contract starts as a written specification: what it holds, who may call it, what must always be true, and what an attacker would want. Contracts that cannot justify holding value are redesigned so they do not.
Stage 2
Implementation against the spec
Solidity, Rust, or Move depending on the target chain, written to be read: small surface area, explicit access control, no cleverness a reviewer has to unpick.
Stage 3
Invariant & property testing
The properties from the specification become machine-checked invariants, fuzzed against millions of generated states. A property that cannot be expressed as an invariant usually means the specification was vague.
Stage 4
Three independent audits
Three firms review each release without sight of one another's findings. Findings are remediated and re-reviewed before release.
Stage 5
Public testnet, verified source
The exact bytecode headed for production runs on a public testnet with source verified, so your team, your auditor, and any counterparty can read what is about to be deployed.
Stage 6
Timelocked deploy & monitoring
Privileged deploys sit behind a 24-hour timelock, which creates a window in which somebody can still object. Once live, the contract is watched against the same invariants it was tested on.
Four techniques, and the scope of each
These are the four we use, and what each covers.
Property-based fuzzing
Invariants exercised against millions of randomly generated call sequences and states, so the failing case is found by a machine before a user with funds at stake finds it.
Formal verification where it pays
Applied to the properties that warrant it: supply conservation, access control, settlement finality. We do not claim to have formally verified an entire system.
Adversarial review
A separate engineer is tasked with breaking the contract, with economic attacks and integration assumptions in scope alongside code defects.
Runtime invariant monitoring
The invariants follow the contract into production. A violation trips a circuit breaker on the affected path.
Four stacks, chosen by the target chain
Language choice follows the chain, and chain choice follows where your counterparties already are.
| Stack | Targets | Toolchain | When we reach for it |
|---|---|---|---|
| Solidity | Ethereum, L2s, Polygon, BSC | Foundry + Slither + Echidna | The default unless there is a reason |
| Rust | Solana, Near, CosmWasm | cargo-fuzz + Miri | Where throughput or account model demands it |
| Move | Aptos, Sui | Move Prover | Resource safety enforced by the language |
| Solidity (permissioned) | Besu, Quorum, subnets | Same toolchain, private network | Institutional deployments requiring a closed set |
What ships with every engagement
An invariant, a run that catches something, and a gated deploy
A rounding residual of one wei on a partial burn is the class of defect that survives code review, passes a hand-written test suite, and drains a contract months later. The middle tab shows the fuzzer catching it.
// Total supply must equal the sum of all balances,// after any sequence of calls, always.function invariant_supplyEqualsBalances() public { uint256 total; for (uint256 i; i < holders.length; ++i) { total += token.balanceOf(holders[i]); } assertEq(total, token.totalSupply());}Properties over test cases
A test checks one path. An invariant checks that something is true after every path a fuzzer can construct.
Counterexamples
A violated invariant returns the exact inputs that broke it, so remediation starts from a reproduction.
The deploy gate is mechanical
Audits signed, invariants passing, bytecode matching. The tool refuses; nobody is asked to confirm.
Objection window
A queued deploy is public for 24 hours. That delay has caught more than one thing worth catching.
Three shapes of engagement
Most clients arrive with one of the following.
Build from a specification
You know what the contracts must do. We specify, implement, test, audit, and deploy them, and hand over a repository your own engineers can maintain.
Audit an existing system
You have contracts, live or pending. We review the code, the deployment configuration, the admin key arrangement, and the upgrade path.
Remediate and re-launch
Something has gone wrong or an audit came back badly. We triage severity, contain what is live, redesign what needs redesigning, and take it back through the full pipeline.
What engineering leads ask
A single audit tells you what one team found in the time you paid for, and audit findings overlap less than people assume. Three unaffiliated firms working without sight of each other's findings turn one opinion into a measurement: where they agree, the risk is well understood; where they disagree, something was missed.
Get a pre-launch read on your contracts
A technical session with the engineers who would do the work: a first-pass read of your contracts or specification, the invariants we would write, and a view of the audit scope and timeline.