Smart Contract Development

Contract deployed. Two weeks pass. A message arrives: "Our pool was drained for $800k." Looking at the transaction in Tenderly: attacker called deposit() → inside the ERC-777 callback called withdraw() again → balance only updated after the second exit. Classic reentrancy, but not through ETH transfer — through ERC-777 hook. ReentrancyGuard was only on withdraw().

Such cases are not rare. A smart contract is financial logic without the ability to patch it overnight.

Languages: Solidity, Rust, Move, Vyper — When to Use What

Solidity 0.8.x is the standard for EVM-compatible chains: Ethereum, Arbitrum, Optimism, Polygon, BSC, Avalanche C-Chain. Starting with 0.8.0, overflow protection is built-in, removing an entire class of arithmetic vulnerabilities. But this doesn't mean arithmetic is automatically safe — unchecked blocks used for gas optimization disable checks again.

Rust + Anchor is for Solana. Fundamentally different model: accounts and programs are separate, state lives in accounts, not inside the contract. Parallel transaction execution on Solana requires explicit declaration of all accounts that an instruction reads or writes — these are #[account] attributes in Anchor. Error in account declarations is a vector for data substitution.

Move (Aptos, Sui) is resource-oriented. Resources cannot be copied or accidentally destroyed — the type system forbids it at compiler level. Linear types solve part of the problems that Solidity solves manually through patterns.

Vyper is Python syntax, more restricted than Solidity: no inheritance, no inline assembly by default, simpler to audit. Curve Finance writes critical contracts in Vyper. In 2023, the Vyper compiler contained a bug in the reentrancy lock for versions 0.2.15–0.3.0, leading to attacks on Curve pools with ~$70M losses — the vulnerability was in the compiler, not the contract code.

Gas Optimization: Not Premature Optimization, But Architectural Decision

Gas is users' money. On Ethereum mainnet, deploying a poorly designed contract can cost 2–5 ETH just because of suboptimal storage layout.

Storage Packing

In EVM, each storage slot is 32 bytes. Storing uint256, uint8, uint256 in that order means three slots. Reordering to uint256, uint256, uint8 means two slots because uint8 packs into the end of the second slot. Seems minor. But if this structure is read in every transaction, saved SLOAD operations (each costs 2100 gas on cold access) sum to thousands of dollars over a month of protocol operation.

Real case: a governance contract with 7 variables in a Proposal structure placed in random order occupied 7 slots. After repacking to slot boundaries — 4 slots. Savings per vote operation: ~18k gas, or about $1.5 at 30 gwei gas price and $3000 ETH.

Calldata vs Memory vs Storage

calldata is read-only, cheaper than memory for function arguments. memory clears after the call. storage is persistent, most expensive. Typical error: passing large arrays through memory arguments instead of calldata in external functions.

Custom Errors vs Require Strings

require("Insufficient balance") stores the string in bytecode and includes it in revert data. error InsufficientBalance(uint256 available, uint256 required) with revert InsufficientBalance(...) costs 50–200 gas less on each revert and gives structured data to the frontend.

Upgrade Patterns

Three main approaches to upgradeable contracts:

Storage collision is the main danger in proxies. Implementation v2 should not add variables before existing ones. The OpenZeppelin Upgrades plugin for Hardhat and Foundry checks this automatically when running upgrades.upgradeProxy(), but only if you use its API, not deploying through new.

Timelock on Upgrades

Any upgradeable protocol with real money should have a timelock. TimelockController from OpenZeppelin: operation is proposed → waits minimum delay (48–72 hours for DeFi) → executes. During this time the community can notice a malicious upgrade. Without timelock, one compromised deployer wallet means loss of the entire protocol.

Testing: Foundry as the Primary Tool

Foundry made invariant testing and fuzz testing accessible without additional frameworks.

forge test --fuzz-runs 10000
forge test --match-test invariant

Fuzzing in 20 minutes finds edge cases that manual tests miss for months. Real example: AMM contract with custom math for LP token calculation. 6 months of work, 150 unit tests in Hardhat, all green. Ran Foundry fuzz with runs = 50000 — found integer division truncation at a certain reserve ratio that gave users 1 wei less on withdrawal. Harmless itself, but opened a vector for dust accumulation on the contract.

Echidna for property-based fuzzing: you define invariants ("sum of all balances never exceeds totalSupply"), Echidna searches for a sequence of transactions that violates them.

Slither for static analysis without running code. Finds reentrancy, uninitialized variables, dangerous delegatecall. Runs in CI in 30 seconds.

MEV and Front-Running

On Ethereum mainnet, transactions in the mempool are visible to everyone. MEV bots monitor them and insert their transactions before yours (frontrunning), after (back-running), or sandwich attacks. For DEX this is expected, for NFT minting or governance it's a problem.

Protection: commit-reveal scheme for auctions and minting. Flashbots PROTECT RPC for private transaction submission (doesn't hit public mempool). EIP-7702 and PBS (proposer-builder separation) change the picture, but slowly.

Smart Contract Development Process

Analysis — function specification, contract interaction schema, edge case analysis. Without this, coding starts blind.

Development — Solidity/Rust with tests in parallel. Not after. Test → code → refactoring.

Internal audit — Slither + Echidna + manual code review. Foundry invariant tests for protocol invariants.

External audit — mandatory for protocols with TVL from $1M. Trail of Bits, Consensys Diligence, OpenZeppelin, Code4rena (community audits). Duration: 2–4 weeks.

Deployment — Foundry scripts or Hardhat Ignition for reproducible deployment. Verify on Etherscan automatically. Gnosis Safe for ownership transfer immediately after deployment.

Monitoring — Tenderly alerts on suspicious transactions, OpenZeppelin Defender for operation automation, Forta Network for on-chain attack detection.

Timelines

• ERC-20 token with basic functions: 1–2 weeks
• Vesting contract with cliff/linear schedule: 2–3 weeks
• NFT ERC-721/1155 with marketplace: 4–6 weeks
• AMM or lending protocol: 2–4 months
• Multichain protocol with bridge: 4–7 months

Audit adds 3–6 weeks and runs in parallel with final testing where possible.