On-chain systems
built for real volume,
not just whitepapers

Yes - for any contract that will hold user funds or govern a protocol with meaningful TVL. We don't ship to mainnet without an independent audit from a reputable firm. We can recommend auditors based on your protocol type, or work with an auditor you've already selected. The audit cost is a separate line item in every project scope, and we prepare the codebase specifically to be audit-ready - NatSpec documentation, clean test coverage reports, and a threat model - so the auditor's time is spent on security, not on understanding what the code does.

We have production deployments on Ethereum mainnet, Polygon, Arbitrum, Optimism, Base, BNB Chain, and Avalanche. Each chain has its own gas model, opcode availability, and bridging assumptions that affect contract design - particularly for cross-chain protocols. We specify chain targets in the architecture phase and design accordingly, rather than treating chain deployment as a simple copy-paste operation.

A focused single-contract system (ERC-20 with staking, NFT collection with minting logic) typically takes 4–6 weeks to develop and test, then 2–3 weeks for audit and remediation. A full DeFi protocol with multiple interacting contracts is typically 10–16 weeks of development followed by 3–5 weeks of audit. We can't shortcut the audit - attempting to do so is how exploits happen.

Yes. We have engineers experienced with Rust and the Anchor framework for Solana. For non-EVM chains, we assess tooling maturity, auditor availability, and the security implications of the specific runtime environment before recommending it for production use. If a chain's ecosystem doesn't yet have reputable auditors available for the contract language, we'll tell you - because audit availability should be a factor in chain selection for any protocol handling user funds.

We recommend against upgradeable contracts where possible, because proxy patterns introduce an admin key risk that protocol users must trust explicitly. Where upgradeability is necessary - for bug fixing capability in early-stage protocols - we implement OpenZeppelin's UUPS pattern with a governance timelock controlling the upgrade key, and document the admin key ownership structure clearly in the protocol's security model. We also design immutable contracts with clearly defined migration paths as an alternative.

We're not a tokenomics advisory firm, but we do review economic design for security implications before writing any code. Flash loan attack vectors, governance attack thresholds, oracle manipulation resistance, and incentive alignment between protocol participants are all areas where the contract implementation and the economic model must agree. Where we identify economic design risks, we flag them clearly - and we can connect you with tokenomics specialists if the design requires deeper work before development begins.

We offer a post-launch monitoring and support retainer that covers on-chain event monitoring with custom alerting (via Tenderly or OpenZeppelin Defender), incident response support for the first 90 days, protocol parameter management assistance, and upgrade implementation as needed. We also run a post-launch review at the 30-day mark to assess real-world usage patterns against the threat model, which occasionally reveals economic edge cases that testing didn't surface.