// Build
Smart contracts written for security, not just functionality
Custom Solidity smart contracts: ERC-20 tokens, NFTs, DeFi logic, and protocol contracts. We treat every contract as a public attack surface — because it is. Fuzz tested, internally audited, and mainnet-deployed with verification.
EVM + Solana
Chain support
Foundry + Echidna
Fuzz testing
OpenZeppelin
Battle-tested base
NatSpec
Full documentation
// Services
Smart contract services
- Specification and threat modelling before code
- Solidity with OpenZeppelin foundations
- Hardhat + Foundry test suite
- Slither static analysis
- Mainnet deployment and block explorer verification
Custom Smart Contract Development
Bespoke on-chain logic for your protocol.
Token Development
ERC-20, ERC-777, governance, and utility tokens.
NFT Smart Contracts
ERC-721, ERC-1155, royalties, and mint mechanics.
Smart Contract Testing & Deployment
Hardhat/Foundry test suites and mainnet deployment.
Contract Optimisation & Maintenance
Gas optimisation, upgrades, and ongoing monitoring.
// Standards
Smart contract security standards
Security-first design
Checks-Effects-Interactions pattern, reentrancy guards, minimal privilege, and pull-over-push payment patterns are non-negotiable in every contract.
Third-party audit recommended
For contracts handling significant user value, we strongly recommend and facilitate third-party audits from firms like Trail of Bits, ConsenSys Diligence, or OpenZeppelin.
Fuzz testing coverage
Foundry invariant tests and Echidna property-based fuzzing catch edge cases that hand-written unit tests miss, particularly for mathematical operations and state transitions.
Upgradeable when needed
Transparent proxy or UUPS patterns for upgradeable contracts; immutable deployment for trust-minimised contracts where upgradeability is a liability.
Gas-optimised by default
Storage packing, event vs. storage trade-offs, batch operations, and unchecked arithmetic where safe — gas costs are a user experience consideration.
Full NatSpec docs
Every public and external function documented with NatSpec — readable developer documentation generated automatically from inline annotations.
// Technology
Smart contract technology stack
Languages
Frameworks
Libraries
Testing
Client SDKs
Chains
// Process
From specification to verified mainnet contract
Spec & Threat Modelling
2–3 daysContract specification with precise state machines, access control design, attack surface analysis, and economic security modelling before a line of Solidity is written.
// FAQ
Common questions about smart contract development
What is the minimum viable smart contract engagement?+
A single contract type (e.g. ERC-20 token with custom vesting schedule) is our minimum scope. We do not implement contracts without a full specification phase — undefined requirements produce insecure contracts.
Do you recommend third-party audits?+
Yes — strongly, for any contract handling user funds. We conduct internal reviews as part of our process, but they do not substitute for specialist third-party audit firms. We can introduce you to firms we trust.
Can you upgrade deployed contracts?+
If the contract was deployed with a proxy pattern (Transparent or UUPS), yes. Immutable contracts cannot be changed by design — which is sometimes the correct security posture. We design upgrade strategies intentionally upfront.
What chains do you deploy on?+
All EVM-compatible chains — Ethereum mainnet, Polygon, Base, Arbitrum, Optimism, and BNB Chain. For high-value deployments, we recommend Ethereum L1 or audited L2s.
What does gas optimisation involve?+
Storage layout review (packing variables to minimise slots), replacing storage reads with events where read is not needed on-chain, using immutable variables, batch functions, and unchecked arithmetic in proven-safe loops.