Web3 · Engineering
Smart Contract Development
Most exploits are not clever cryptography, they are an unaudited line that shipped because security was bolted on at the end. Smart contract development is the blockchain engineering practice that turns a protocol specification into on-chain code engineered for third-party audit from the first commit. We write Solidity, Vyper, and Move, hand auditors a spec and a threat model, and own the code from architecture through mainnet and governance.
- 4Hacken audit rounds clearedNeemo Finance contracts
- Moveon Aptos, in productionrKGEN / KGEN token
- EVM + Solanaplus Cosmos and Aptoschains we ship on
In short
What is Smart Contract Development?
Smart contract development is an on-chain engineering practice for protocol founders that ships audit-ready Solidity, Vyper, and Move code. We engineer for third-party audit from the first commit, not retrofitted afterwards. Our Neemo Finance contracts cleared four separate Hacken audit rounds. We wrote the KGEN token contracts in Move on Aptos.
What we deliver
Concrete artefacts, not capabilities
- 01
Audit-ready contracts with NatSpec docs and a full Foundry or Hardhat test suite.
- 02
Threat model covering economic, MEV, oracle, and reentrancy attack vectors.
- 03
Deployment scripts and verified contract sources on the target chain's explorer.
- 04
Monitoring hooks for paused functions, role changes, and large value transfers.
- 05
Handover runbook covering upgrade paths, parameter changes, and incident response.
Key concepts
Key terms, defined
- Threat model
- A threat model is a written enumeration of how a contract can be attacked: reentrancy, oracle manipulation, MEV extraction, access-control failure, and economic exploits. It is drafted alongside the specification, before code, so each contract decision is made against a named adversary rather than discovered during an external audit.
- Reentrancy
- Reentrancy is an attack where an external call lets a malicious contract re-enter a function before its state updates settle, draining funds across repeated calls. It is mitigated with the checks-effects-interactions pattern and reentrancy guards, and remains one of the most exploited classes of smart contract bug.
- Invariant testing
- Invariant testing asserts that a property of a contract holds true across thousands of randomised call sequences. A solvency invariant, for example, checks that total liabilities never exceed assets. Property-based fuzzers such as Echidna or Foundry generate the sequences, surfacing edge cases that example-based unit tests miss.
- Formal verification
- Formal verification mathematically proves that a contract satisfies a specification under all possible inputs, rather than sampling behaviour through tests. It is applied to high-value primitives where a single failure is catastrophic, complementing audits and fuzzing rather than replacing the threat model and review process around them.
- Move resource model
- Move is a contract language where assets are typed resources that cannot be copied or silently discarded, only moved between accounts. On chains like Aptos this eliminates whole classes of double-spend and accounting bugs at the language level, shifting part of the security burden from the developer to the type system.
How we work
Engagement phases
Specification & threat model
We translate the protocol's economic intent into a contract specification. Every state variable, role, and external call is named before code is written. In parallel we draft a threat model covering economic attacks, MEV exposure, oracle dependencies, and reentrancy paths. The spec and threat model are the two artefacts an external auditor reads first, so we write them for that reader.
Engineering & internal audit
Contracts are built against the spec with property-based tests for invariants and fork tests against live mainnet state. Coverage targets are absolute, not a percentage: every branch tested, every revert path exercised. Before any external review a second engineer runs an internal audit pass against the threat model, signing off line by line and filing what they could not break.
External audit cycle
We hand the codebase to a firm chosen with you (Hacken, Trail of Bits, OpenZeppelin, or similar), respond to findings within 48 hours, ship fixes against a second-round review, and publish the final report with the deployment. The Neemo Finance contracts cleared four separate Hacken rounds through exactly this process, with the report public on day one.
Deployment & operate
Mainnet deployment runs from a script reviewed by both teams. We verify sources on the explorer, transfer admin roles to your multisig, and document every privileged call. After launch we monitor paused functions and large transfers, respond to incidents on a defined SLA, and ship parameter changes through governance for as long as the engagement runs.
Tech stack
What we build on
- SolidityLanguage
- VyperLanguage
- MoveAptos
- FoundryTesting
- HardhatBuild
- OpenZeppelinLibraries
- SlitherStatic Analysis
- EchidnaFuzzing
- TenderlyMonitoring
- SolidityLanguage
- VyperLanguage
- MoveAptos
- FoundryTesting
- HardhatBuild
- OpenZeppelinLibraries
- SlitherStatic Analysis
- EchidnaFuzzing
- TenderlyMonitoring
Scope
When this fits and when it doesn't
| This fits when | This doesn't fit when |
|---|---|
| You have a protocol specification and need contracts engineered for third-party audit from day one. | You want a copy-paste fork of an existing protocol with no economic or security review. |
| Your engineering lead can review a spec and threat model rather than ship-or-die backlog tickets. | Security is a checkbox at the end and the audit is treated as an optional cost. |
| Budget covers an external audit firm in addition to development, not 'audit later'. | The primary deliverable is UI engineering, dashboards, or an off-chain backend system. |
Related work
Shipped engagements
- Live project
KGEN: Move smart contracts on Aptos
We engineered the smart contracts for KGEN (Kratos Gamer Network) in Move on Aptos, covering the rKGEN and KGEN token logic.
View live project - Live project
Neemo Finance: staking contracts, four audit rounds
Astar-network staking contract suite engineered for Neemo Finance that cleared four separate Hacken audit rounds before mainnet.
View live project
Related services
Adjacent engagements
- Web3
DeFi Protocol Development
Lending, perpetuals, yield, and vault infrastructure spec'd for third-party audit.
- Web3
Token Launchpad Development
Token sale and distribution platforms: fair launch, vesting, bonding curves, and allowlists, engineered for audit.
- Product Studio
MVP Development
Zero-to-launch product builds - founder-led scope through first paying users.
Frequently asked questions
Choice follows the chain, not preference. Solidity for EVM ecosystems where library maturity and auditor coverage matter most. Vyper when a smaller surface area helps, typically Curve-pattern stableswap or audited treasury contracts. Move for Aptos or Sui, where the resource model removes whole classes of accounting bug at the language level. We document the decision so the auditor sees rationale, not preference.
No, the external audit is always a separate firm. We engineer for audit and run an internal audit pass, where a second engineer reviews against the threat model line by line, but the external auditor is the signal a serious investor or DAO trusts. The Neemo Finance contracts we wrote were audited by Hacken across four rounds, and we coordinate the engagement directly with the firm you choose.
Mainnet is the start of the operate phase, not the end. We monitor pause functions, role changes, and large transfers through Tenderly alerts, respond to incidents on a defined SLA, ship parameter changes through your governance process, and document every privileged call. The engagement runs as long as you need it, with hand-off documentation so an in-house team can take over cleanly.
Yes, when an upgrade path exists. We work on proxy-based upgradeable systems, write migration scripts for non-upgradeable patterns, and reason about the storage layout before any change ships. Migrations are tested on a mainnet fork against historical state. We do not fork an unfamiliar contract and ship: we read the original audit, the deployment history, and the open issues first.
Yes. We wrote the KGEN (Kratos Gamer Network) token contracts in Move on Aptos, covering the rKGEN and KGEN logic in production. Move treats assets as typed resources that cannot be copied or dropped, which removes a class of accounting bug before audit. We choose Move when the resource model materially reduces attack surface, and document why for the auditor.
Last reviewed · Reviewed by Metaborong engineering team
Tell us what you are building.
We build what large agencies under-deliver and freelancers can't architect, across Web3 protocols, AI agents, and SaaS products. Tell us what you are building. We will tell you how we would approach it, no pitch deck, no fluff, no commitment required.