# Smart Contract Development Services Solidity, Vyper, and Move smart contracts engineered for third-party audit. Specs, tests, deployment, and post-deploy monitoring all included. Canonical: https://www.metaborong.com/services/web3/smart-contract-development Service: web3/smart-contract-development ## Overview 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. ## What is it? 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 - Audit-ready contracts with NatSpec docs and a full Foundry or Hardhat test suite. - Threat model covering economic, MEV, oracle, and reentrancy attack vectors. - Deployment scripts and verified contract sources on the target chain's explorer. - Monitoring hooks for paused functions, role changes, and large value transfers. - Handover runbook covering upgrade paths, parameter changes, and incident response. ## Key concepts **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 1. **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. 2. **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. 3. **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. 4. **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 Solidity (Language), Vyper (Language), Move (Aptos), Foundry (Testing), Hardhat (Build), OpenZeppelin (Libraries), Slither (Static Analysis), Echidna (Fuzzing), Tenderly (Monitoring) ## When this fits ### Fits when - You have a protocol specification and need contracts engineered for third-party audit from day one. - Your engineering lead can review a spec and threat model rather than ship-or-die backlog tickets. - Budget covers an external audit firm in addition to development, not 'audit later'. ### Does not fit when - You want a copy-paste fork of an existing protocol with no economic or security review. - Security is a checkbox at the end and the audit is treated as an optional cost. - The primary deliverable is UI engineering, dashboards, or an off-chain backend system. ## FAQ ### How do you choose between Solidity, Vyper, and Move? 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. ### Do you run the security audit yourselves? 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. ### What happens after mainnet deployment? 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. ### Can you upgrade an existing protocol's contracts? 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. ### Do you write contracts in Move for Aptos and Sui? 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.