Solidity Development Services - Smart Contract Programming

Foundry is the leading Solidity development toolkit at 57% primary framework adoption (2025, up from 51% in 2024). Tests are written in Solidity (not JavaScript), matching the language of the contract under test. Foundry's forge test runs 10-100× faster than Hardhat's JavaScript-based tests. Key Foundry features: fuzz testing (property-based randomized inputs), invariant testing, fork testing against mainnet state, gas snapshots, and cheatcodes for manipulating EVM state. Hardhat remains at 33% adoption and is still valid — particularly for projects needing its plugin ecosystem.

Check-effects-interactions (CEI) is the primary pattern preventing reentrancy attacks. Order: (1) Checks — validate inputs and conditions. (2) Effects — update contract state (balances, mappings). (3) Interactions — call external contracts or transfer ETH. If you call an external contract before updating your state, the external contract can call back into your contract while state is stale — the classic reentrancy vulnerability. Additionally, use OpenZeppelin's ReentrancyGuard on any function that calls external contracts as a belt-and-suspenders defense.

Use the latest stable release — as of 2026, Solidity 0.8.x is standard. The 0.8.x series introduced built-in overflow/underflow protection (arithmetic reverts by default), eliminating the need for SafeMath library. Use a fixed pragma (pragma solidity 0.8.28) for production contracts rather than a floating range (pragma solidity ^0.8.0) — ensures the contract compiles with exactly the version it was tested against. Run slither with the target version to check for known version-specific issues.

Only if your use case genuinely requires post-deployment modification. Upgradeable contracts introduce complexity: storage layout must be preserved across versions, upgrade logic must be secured (timelocked governance), and the 'upgradeability' itself is a security surface if admin keys are compromised. For DeFi protocols managing large TVL, upgradeable contracts with governance timelocks are standard practice. For utility contracts, token contracts, and simple escrows, immutable contracts are simpler and more trustless.

OpenZeppelin is the standard library for Solidity smart contract development — providing battle-tested, audited implementations of ERC-20, ERC-721, ERC-1155, AccessControl, Governor, UUPS Proxy, and many more patterns. Using OpenZeppelin means not reinventing security patterns that have already been audited. Key contracts: ERC20.sol (fungible tokens), ERC721.sol (NFTs), AccessControl.sol (role-based permissions), Governor.sol + TimelockController.sol (DAO governance), and Initializable.sol + UUPSUpgradeable.sol (proxy upgradeability).

Both are TypeScript libraries for interacting with Solidity contracts from a frontend. ethers.js v6 is the most-used (70% of Solidity devs) — mature, well-documented, works with all Ethereum tooling. viem is newer (39% adoption) with TypeScript-native design, 35KB bundle (40% smaller than ethers.js), and stricter type safety from ABI definitions. wagmi is a React hooks layer that can use either underneath. Use ethers.js for projects with existing code or when ecosystem compatibility is paramount; use viem for new TypeScript-first projects where bundle size and type safety matter. Never use Web3.js — it was archived March 4, 2025.

Our audit process: (1) Slither static analysis — automated vulnerability detection for common patterns (reentrancy, access control, arithmetic). (2) Aderyn — Cyfrin's static analyzer with different vulnerability signatures than Slither. (3) Foundry fuzz testing — property-based testing with thousands of randomized inputs to find invariant violations. (4) Manual code review against DeFi attack taxonomy (oracle manipulation, flash loan attacks, front-running, MEV). (5) Formal verification (Certora Prover) for critical invariants when TVL justifies cost. We recommend independent external audit from Trail of Bits, OpenZeppelin, or Spearbit before any mainnet deployment holding significant value.

Top vulnerabilities: (1) Reentrancy — external call before state update, use CEI pattern + ReentrancyGuard. (2) Access control — unprotected functions, use OpenZeppelin AccessControl or Ownable. (3) Oracle manipulation — single-source price feeds, use Chainlink + TWAP + sanity bounds. (4) Integer overflow — prevented by Solidity 0.8.x built-in checks; use unchecked blocks cautiously. (5) Flash loan attacks — logic that can be exploited when an attacker temporarily holds large liquidity. (6) Front-running / MEV — transaction ordering attacks on DEXs and auction mechanisms.

Priority optimizations: (1) Pack multiple variables into one 32-byte storage slot (uint128 a; uint128 b occupies one slot). (2) Use calldata instead of memory for read-only function parameters. (3) Use immutable for values set in constructor that don't change. (4) Replace string error messages with custom errors (revert InsufficientBalance() costs less than revert('Insufficient balance')). (5) Cache storage variables in local variables when reading multiple times in a function. (6) Use events for data only needed off-chain — storage is expensive, events are cheap. Profile with Foundry gas snapshots, not guesswork.

We offer support covering: monitoring for unusual contract interactions via Tenderly alerts, gas optimization reviews as Ethereum upgrades affect opcode costs, security patch coordination if vulnerabilities are disclosed post-deployment (upgrade via governance if UUPS proxy, or deployment of successor contracts if immutable), new contract feature development, and external audit coordination for protocol expansions. We also provide incident response documentation — pre-planned procedures for what to do if an exploit is discovered, including pause mechanisms and fund recovery paths where implemented.