Smart contract development engineered for security

Our primary smart contract language is Solidity, which targets all EVM-compatible blockchains — Ethereum, Polygon, Arbitrum, Optimism, Base, BNB Chain, and Avalanche. For projects requiring maximum gas efficiency or advanced features, we also develop in Vyper, a Python-inspired language that produces more gas-efficient bytecode for certain patterns due to its restricted feature set (no inheritance, no operator overloading). For Solana, we write programmes in Rust using the Anchor framework. For Move-based chains like Aptos and Sui, we develop in Move. The language choice depends on your target blockchain, security requirements, and ecosystem — Solidity has the largest developer community, audit tooling, and library support (OpenZeppelin), making it the default choice for most EVM projects.

Smart contract security requires multiple overlapping layers of defence. Our process starts with secure development practices — using battle-tested OpenZeppelin libraries, following the checks-effects-interactions pattern, implementing reentrancy guards, and minimising external calls. We write comprehensive test suites targeting 100% branch coverage using Hardhat and Foundry, including unit tests, integration tests, and fork tests against mainnet state. Automated analysis tools form the next layer: Slither for static analysis detects common vulnerability patterns, Mythril performs symbolic execution to find edge cases, and Foundry fuzz testing generates thousands of random inputs to discover unexpected behaviours. We also run invariant tests that verify critical protocol properties hold across all possible state transitions. Before mainnet deployment, we engage independent third-party audit firms for a fresh-eyes review. Post-deployment, we implement monitoring with real-time alerting for anomalous on-chain behaviour and maintain bug bounty programmes for ongoing community-driven security review.

Upgradeable smart contracts use a proxy pattern — users interact with a proxy contract that delegates all calls to an implementation contract. The implementation can be swapped out by the contract owner, effectively upgrading the logic while preserving the contract address, state, and user balances. The most common patterns are Transparent Proxy (OpenZeppelin), UUPS (Universal Upgradeable Proxy Standard), and Beacon Proxy for deploying many instances with shared logic. Upgradeability is valuable for complex protocols that may need bug fixes, feature additions, or parameter changes post-deployment. However, it introduces trust assumptions — users must trust that the upgrade authority will not deploy malicious code. For DeFi protocols, we often implement timelocks (24-72 hour delay before upgrades take effect), multi-sig governance (requiring multiple signers), and eventually transition to fully immutable contracts once the protocol matures. The decision depends on your project stage — early-stage protocols benefit from upgradeability, while mature protocols may choose immutability for maximum trust.

A comprehensive smart contract audit involves multiple phases. First, we review the project specification and threat model to understand the intended behaviour and identify high-risk areas. Second, automated analysis — Slither static analysis, Mythril symbolic execution, and custom Foundry fuzz/invariant test suites identify low-hanging vulnerabilities and edge cases. Third, manual line-by-line code review focuses on business logic errors, access control flaws, reentrancy vulnerabilities, flash loan attack vectors, oracle manipulation risks, integer overflow/underflow, front-running susceptibility, and economic exploit scenarios. Fourth, we verify that the contract follows best practices — event emission, error handling, gas efficiency, and upgradeability safety. Fifth, we produce a detailed audit report categorising findings by severity (Critical, High, Medium, Low, Informational) with specific remediation recommendations. Sixth, we verify fixes — once your team addresses the findings, we review the changes and issue a final report. The entire process typically takes 2-4 weeks depending on codebase complexity. For critical protocols, we recommend engaging two independent audit firms for maximum coverage.

Smart contract development costs vary based on complexity and scope. A standard ERC-20 token contract with vesting and governance features costs EUR 5,000 to EUR 15,000. A DeFi protocol with lending, borrowing, and liquidation mechanics ranges from EUR 30,000 to EUR 80,000. A full DEX with AMM pools, concentrated liquidity, and governance typically costs EUR 50,000 to EUR 120,000. NFT marketplace smart contracts with lazy minting, auction mechanics, and royalty enforcement range from EUR 20,000 to EUR 50,000. Independent third-party auditing adds EUR 15,000 to EUR 60,000+ depending on codebase size and complexity. These estimates include development, testing (unit, integration, fuzz, invariant), internal security review, testnet deployment, and documentation. We provide detailed fixed-price quotes after an initial technical scoping session.

Formal verification is a mathematical approach to proving that a smart contract behaves exactly as specified — not just testing with sample inputs, but mathematically proving correctness for all possible inputs and states. Tools like Certora and Halmos allow us to write formal specifications (invariants, pre/post-conditions) and use SMT solvers to verify that the contract code satisfies these properties. For example, we can formally prove that a token contract total supply always equals the sum of all balances, that a lending protocol can never be drained below its collateral requirements, or that access control functions can only be called by authorised addresses. Formal verification is most valuable for high-value DeFi protocols where bugs can result in millions in losses. It complements but does not replace traditional auditing — formal verification catches mathematical/logical errors, while manual audits catch business logic issues and economic attack vectors.

Gas optimisation is critical for user experience and protocol competitiveness — especially on Ethereum L1 where gas costs are significant. Our optimisation techniques include: storage layout packing (grouping smaller variables to fit in single 32-byte slots), using mappings instead of arrays for lookups, minimising SSTORE operations (the most expensive EVM opcode), using calldata instead of memory for read-only function parameters, implementing bitmap patterns for boolean flags, using unchecked arithmetic where overflow is impossible, batch processing to amortise base transaction costs, and implementing EIP-2929 access list optimisations. We also use Solidity compiler optimisation settings tuned for your deployment scenario — high run counts for frequently called functions. For complex protocols, we profile gas usage per function using Foundry gas reports and optimise hot paths first. On Layer 2 chains, we focus on calldata compression since L2 gas costs are dominated by data posting to L1.

Yes — Layer 2 deployment is a core part of our smart contract practice. We deploy on all major L2 networks including Arbitrum (Optimistic Rollup with full EVM equivalence), Optimism (OP Stack, powering the Superchain ecosystem), Base (Coinbase L2 built on OP Stack), zkSync Era (ZK rollup with native account abstraction), Polygon zkEVM (ZK rollup with full EVM compatibility), and StarkNet (ZK rollup using Cairo language). For most projects, we recommend starting on an L2 for dramatically lower gas costs (typically 10-100x cheaper than Ethereum L1) and faster confirmation times, while inheriting Ethereum security guarantees. We handle L2-specific considerations including cross-chain messaging (L1 to L2 and L2 to L1 bridging), sequencer downtime handling, L1 data availability costs, and differences in opcode pricing between L1 and L2 environments.