Solidity Standards

Solidity and EVM contract standards

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

Premise that governs everything else: deployed code is immutable, public and handles value directly. There is no hotfix, no rollback, no "we'll fix it next sprint", and the attacker is economically incentivised in real time — they read your bytecode, your mempool and your commit before you deploy. That reorders the cost calculus of the whole catalogue: a missing test is not a potential regression, it is an irreversible loss; a skipped review does not delay a release, it funds a third party. Here the spend on prior verification is not justified by ROI, it is justified because there is no later correction phase.

Operational corollary: in this domain the expensive work goes before deployment (invariants, formal verification, audit, incident plan), not after (monitoring, patching). Inverting that order is the domain's structural mistake.

Applies to: .sol files, foundry.toml, remappings.txt, hardhat.config.ts, .solhint.json, slither.config.json, forge script deployment scripts, *.t.sol tests, and to every review of contracts on the EVM (Ethereum L1, L2s of the OP Stack / Arbitrum / zkEVM kind and compatible chains).

Not applicable: see appsec-standards (AppSec methodology: STRIDE, abuse cases, finding triage, choosing and calibrating SAST/DAST, ASVS — here the vulnerability classes specific to contracts and the code criteria that make them impossible), cryptography-pki-standards (algorithm and curve choice, key life cycle and custody — here only the correct use of the primitives the chain already exposes: signature verification, EIP-712, ecrecover and its malleability trap), secrets-management-standards (custody of the deployment private key and of the owner/upgrader key is hers —HSM, multisig, rotation, approvals—; here only the hard requirement that it must not be a single hot key), typescript-standards (deployment scripts and TS/JS Hardhat tests with viem/ethers: the language and its tooling are hers; the contract and its invariants, ours), rust-standards (contracts on non-EVM chains —Solana, CosmWasm, Arbitrum Stylus— and tooling written in Rust: this skill is about Solidity and the EVM and claims nothing outside that), cicd-standards (pipeline, runners, OIDC and artifact signing; here the specific gate: nothing is deployed without green invariant tests, without a closed external audit and without a written incident plan), vulnerability-management-standards (triage and SLA for CVEs in dependencies and tooling), offensive-security-standards (offensive testing with scope and authorisation in writing; this skill is defensive: it describes vulnerability classes in order to prevent them — see the prohibition in §7), incident-response-forensics-standards (managing the real incident, tracing funds, coordination with exchanges and law enforcement; here only the plan and the on-chain mechanisms that must exist beforehand), grc-compliance-standards (the regulatory framework —MiCA in the EU, anti-money-laundering obligations, sanctions—; no legal criteria are issued here), observability-standards (telemetry platform, alerts and SLOs; here which event to emit and why), api-design-standards (the contract of an HTTP/gRPC API; the ABI of a deployed contract is also a public contract — and an immutable one too: breaking it is not a major bump, it is a migration with a network-wide cost).

2. Default decisions / Toolchain

Verify the latest version on the web before committing to it in a real project (§8). Data from Aug 2026: it expires fast.

3. Structure and conventions

Reference layout (Foundry):

src/            # production contracts. One contract per file, name == file
  interfaces/   # IFoo.sol — the ABI is a public contract: it is designed, not derived
  libraries/
test/           # *.t.sol unit and integration tests
  invariant/    # handlers + invariants (mandatory, §4)
script/         # forge script for deployment and upgrades — versioned and reviewed
lib/            # dependencies as submodules (forge install)
foundry.toml
remappings.txt  # explicit and versioned: no implicit resolution

• Explicit and versioned remappings.txt. Implicit resolution makes two machines compile different trees; with immutable bytecode that is unacceptable.
• Dependencies frozen to a commit, not to a branch: submodules with a pinned SHA (or the package manager's lockfile). A lib/ pointing at master is a dependency that changes on its own underneath an artifact that cannot change.
• NatSpec mandatory on every external/public and on every event and custom error: @notice (what it does, for the user who signs), @param, @return, @dev for invariants and assumptions. NatSpec feeds the human-readable signature in wallets: without it the user signs blind. @custom:oz-upgrades-from where the upgrades plugin requires it.
• Custom errors (error Foo(uint256 x); + revert) instead of require with a string: cheaper and typed, which makes the failure distinguishable from the client. Every revert must say which condition failed.
• Conventions: CamelCase for contracts and structs, mixedCase for functions and variables, SCREAMING_SNAKE for constant/immutable, a _ prefix for internal/private. Member order: types, constants, immutable, storage, events, errors, modifiers, constructor, external, public, internal, private.
• Explicit units in the name: amountWad, feeBps, deadlineTs. The precision errors in §5 start with variables that have no unit.
• Interfaces over implementations in every external integration; never cast to somebody else's contract assuming its shape.

Reference foundry.toml — what is decided here is reproducibility and the depth of the test campaigns, not convenience:

[profile.default]
solc_version = "0.8.36"        # exact: the binary must be reproducible by third parties
evm_version = "prague"         # that of the TARGET chain, not the compiler default
optimizer = true
optimizer_runs = 200           # fewer runs = less code; measure, do not copy
bytecode_hash = "ipfs"         # coherent metadata for verification on Sourcify/Etherscan
deny_warnings = true           # a compiler warning in an immutable artifact is a bug
fs_permissions = []            # no disk access by default; open by path and only what is needed

[fuzz]
runs = 10_000                  # PR: enough to catch the obvious
[invariant]
runs = 256
depth = 500                    # depth = number of calls per sequence; this is what finds bugs
fail_on_revert = false         # with bounded handlers, raise to true and fix the spurious reverts

[profile.ci.fuzz]
runs = 100_000                 # nightly: a long campaign, not on every PR

4. Quality and testing

No level in this list is optional in a contract that is going to custody value. The order is one of increasing cost; the deployment gate requires all of them.

4.1 Unit tests

forge test with explicit coverage of the happy path, edges and errors: every revert has a test that triggers it (vm.expectRevert(Foo.selector)), every event one that verifies it (vm.expectEmit), every access control branch one per role and one per unauthorised actor. A require with no test that fires it is an unverified branch of the immutable binary.

4.2 Property fuzzing and invariant tests — expected practice, not optional

• Per-function fuzzing (function testFuzz_x(uint256 amount)) for every function that accepts amounts, with vm.assume/bound instead of discarding en masse.
• Stateful invariants: the properties that must hold after any sequence of calls by any actor — solvency (sum(balances) <= totalAssets), monotonicity of indices, value conservation, that no permitted operation leaves the protocol insolvent. They are written with bounded handlers (an unguided fuzzer sends almost everything to revert and the campaign proves nothing).
• Long campaigns outside the PR (nightly) with Echidna or Medusa over the same harness; the input corpus is versioned.
• A broken invariant in CI blocks the merge. Every bug fix also leaves its regression test.

4.3 Formal verification

Escalation by criticality: solc's SMTChecker (free, start there) → halmos (symbolic tests with the same syntax as Foundry's) or kontrol → Certora Prover with CVL specifications for the economic core. What it guarantees: that the specified property holds for all inputs within the model. What it does not: that the specified property is the right one, nor anything outside the model (gas, interaction with unmodelled external contracts, economic incentives). An UNKNOWN from an SMT timeout is not a proof: treat it as a failure.

4.4 Forking and simulation

Tests against real network state (vm.createSelectFork at a pinned block, not "the latest": tests must be deterministic) for every integration with third-party protocols, oracles and real tokens. Simulate the full deployment and the upgrade on a fork before executing them.

4.5 Coverage

forge coverage as a signal, not a goal. 100 % of lines with zero invariants is worse than 80 % with good invariants. What is measured seriously: error branches covered and properties formulated.

4.6 External audit — gate prior to deployment

Mandatory before the first deployment with real value and before every upgrade that touches custody or accounting logic.

• What it guarantees: that an independent team with a reputational incentive reviewed a specific commit, in a specific scope, over a specific time, and found no more than what it reports.
• What it does NOT guarantee: that the contract is secure. It does not cover what was left out of scope, nor changes after the audited commit, nor the economic design, nor key governance, nor external dependencies. "Audited" is not an attribute of the protocol, it is a dated event about a hash.
• Process requirements: scope and commit fixed in writing, the report is published (including the uncorrected findings and the reason), every fix is re-verified, and the report is referenced against the deployed hash. Two independent audits for anything custodying significant value; a public audit contest complements, it does not replace.

4.7 Bug bounties and incident response

• A bug bounty programme before deployment, with scope, a reward scale proportional to the value at risk and explicit safe harbour. A contact channel nobody reads is the reason an honest researcher turns into something else.
• An on-chain incident response plan, written and rehearsed BEFORE deployment — it is a deployment requirement, not later documentation. It must set out: who can pause and with what mechanism (and what is paused and what is not); what the timelock protects and what its window is; the war room (who, how it is convened, an out-of-band channel); prepared contacts with exchanges and with security and chain analysis providers; the criteria for public communication; and the recovery or migration procedure. Rehearse it on testnet: a pause() nobody has ever executed is not a control.
• A contradiction to be resolved by design, not ignored: the same pause that saves the protocol is an exploitable centralisation. Document who holds it and under what governance (§5.3).

4.8 CI gate (it breaks the build, in order of cost)

forge fmt --check
solhint 'src/**/*.sol'
forge build --sizes            # deployed code size limit
forge test -vvv                # unit + fuzz
forge test --match-path 'test/invariant/*'
slither . --fail-high --fail-medium
forge coverage --report summary
# nightly: Echidna/Medusa campaign + formal verification

In addition, a deployment gate (not a merge one): green invariants + closed audit + signed incident plan + reproducible deployment verified in the explorer (Sourcify/Etherscan) with the same solc, evm_version and metadata.

5. Security — the core

5.1 Reentrancy

• Checks-Effects-Interactions is the basis and remains so: validate, write the state, and only then call out. Most reentrancies are state written after the external call.
• CEI plus a guard (ReentrancyGuard, or its transient storage variant if the target chain supports EIP-1153 — verify §2 evm_version). Belt and braces: the guard covers what a future refactor breaks.
• Every external call is a transfer of control: token.transfer to a contract, an ERC-777/ERC-721 onERC721Received/ERC-1155 callback, msg.sender.call{value:}. Enumerate them explicitly in the review.
• Cross-function and cross-contract reentrancy: a per-function guard does not protect if two different functions touch the same state. The guard goes on the shared state, not on the fashionable function.
• Read-only reentrancy — the subtle one and the least known: during the external call the protocol's state is temporarily inconsistent, and a view function (a price, a totalSupply, a ratio) read by a third party at that instant returns a false value. The classic guard does not cover it because the view function mutates nothing. Criterion: view functions that other protocols consume as a source of truth must respect the same guard (or expose a reader that reverts if the guard is taken), and never integrate by reading a third party's view without checking how it behaves mid-call.

5.2 Access control and initialisation

• Every function that mutates sensitive state declares its authorisation explicitly. Ownable only for the trivial; AccessControl with separate roles (pauser ≠ upgrader ≠ treasury) by default. Least privilege on chain too.
• tx.origin FORBIDDEN for authorisation — no exceptions. It authorises the human, not the calling contract, and any intermediate contract the victim interacts with inherits their permissions. (Besides, EIP-7702 makes the EOA/contract distinction even less reliable: msg.sender.code.length == 0 no longer means "it is a person".)
• Uninitialised implementation contracts: a logic contract behind a proxy must disable its initialiser in the constructor (_disableInitializers()); otherwise anybody initialises it, becomes owner of the implementation and —if the implementation has a reachable delegatecall or selfdestruct— can render the proxy permanently unusable.
• Ownership changes in two steps (Ownable2Step): a transfer to a wrong address is irreversible.
• delegatecall executes somebody else's code over your own storage, your balance and your identity. Only towards immutable addresses or ones governed by the same trust model; never towards an address parameterisable by the caller.

5.3 Proxies and upgradeability

• Choice: UUPS by default (upgrade logic in the implementation, cheaper proxy) — with the trap accepted: if an upgrade deploys an implementation without the upgrade logic, upgradeability is lost for ever. Transparent when you prefer to separate the admin from the call flow. Beacon when many instances must be upgraded atomically. Diamond (EIP-2535) only with a written justification: the OZ plugins do not validate its storage.
• Storage collision: the layout is a contract between versions. Never reorder, insert in the middle nor change the type of an existing variable; only append at the end. Use the upgrades plugin's automatic validation as a gate, __gap (or namespaced storage, ERC-7201) in inheritable contracts. Simulate every upgrade over a fork of the real state before executing it.
• An upgradeable contract does not remove the risk: it transfers it entirely to whoever has the key. The governance of that key is part of the threat model and is documented with the contract: a multisig with a threshold and independent signers (a single hot key is FORBIDDEN, see secrets-management-standards), a timelock with a window long enough for a user to exit before the change takes effect, and a declared path towards immutability or towards decentralised governance. A "decentralised" protocol with an upgradeTo behind an individual key is a custodian that does not say so.

5.4 Oracles and price manipulation

• An AMM's spot price is not an oracle. It is the instantaneous state of a reserve that anybody can move within the same transaction. Reading it to value collateral is the vulnerability, not an implementation detail.
• TWAP raises the cost of the attack but does not eliminate it: its security depends on the pair's liquidity and on the window; in a shallow market or on an L2 with a single sequencer it is manipulable. Choose the window with the manipulation cost calculated, not out of habit.
• Signed / push oracles (provider feeds): validate freshness (reject stale data), maximum deviation against the previous reading, and the case where the feed does not respond — a down oracle must pause or degrade, never silently return the last value. Check the feed's number of decimals, which does not have to match the token's.
• Tokenised vault ratios (ERC-4626) and third parties' totalSupply/balanceOf: any view of another protocol is an oracle if you use it to decide, with all the risks in §5.1.

5.5 Flash loans

They are not a vulnerability: they are a capital amplifier that turns any economic flaw into something exploitable at maximum scale and with no prior capital. Design criterion: assume the attacker has unlimited capital during a transaction. Any logic that depends on balances, votes, prices or proportions measured at the instant must use delayed values or a snapshot of a previous block. Blocking "contracts" or checking msg.sender == tx.origin is not a mitigation (and it breaks multisigs and smart accounts).

5.6 Arithmetic and precision

• 0.8.x reverts on overflow/underflow by default: unchecked only with the bound demonstrated in a comment and with an edge test.
• Multiply before dividing; every division truncates. Use fixed-point libraries (mulDiv) so as not to lose precision nor overflow in the intermediate.
• Always round in favour of the protocol (up on what the user pays or owes, down on what they receive). "Neutral" rounding is the vector of erosion-by-repetition attacks.
• First depositor inflation attack in vaults: the first share is manipulated by a direct donation. Mitigate with dead shares, a virtual offset or an initial deposit by the protocol itself.
• Different decimals between tokens (USDC's 6 versus most tokens' 18, and tokens with arbitrary decimals): normalise at the entry boundary, never assume 18. decimals() is optional in ERC-20 and may lie.

5.7 Randomness and front-running

• On-chain randomness FORBIDDEN: block.timestamp, blockhash, block.prevrandao, block.difficulty, state hashes — all of it is known, predictable or influenceable by whoever builds the block, which is exactly who has the incentive. Instead: a provider's verifiable VRF, or commit-reveal with a time window and a penalty for not revealing. The validator can revert the transaction that does not suit them: no single-transaction scheme is safe.
• MEV and front-running: the mempool is public; the order of transactions is decided by a third party with an economic incentive. Every swap or liquidation exposes slippage (minAmountOut) and deadline parameters that are mandatory and decided by the user — a minAmountOut = 0 or a deadline = block.timestamp is a blank cheque. Veto patterns susceptible to a sandwich; use commit-reveal or private submission where the value justifies it.
• ERC-20 approvals: the classic approve race. Use increase/decreaseAllowance or permit; FORBIDDEN to require infinite approval when the exact amount is enough.

5.8 Tokens that do not comply with the standard

The real ERC-20 is a heterogeneous mess. Assume by default:

• Absent or non-boolean return (USDT and others): always use SafeERC20; checking a bool that does not exist causes a revert.
• Fee on transfer and rebasing: never assume you receive what you sent — measure the balance before and after, or explicitly reject those tokens with an allowlist.
• Double entry point (two addresses controlling the same balance): it breaks any control based on the token's address.
• Callbacks (ERC-777, ERC-721/1155 onReceived): reentrancy through the back door.
• Criterion: a reviewed token allowlist in protocols that accept collateral. "Any ERC-20" is an attack surface open to the attacker deploying the token.

5.9 Denial of service

• Unbounded loops over arrays a third party can grow: the day comes when the function exceeds the block gas limit and becomes inaccessible for ever. Every iterable array must have a bound, or be iterated by pages.
• Push versus pull: never send funds in a loop to N recipients. One recipient that reverts (a contract with no receive, or malicious on purpose) blocks the rest. Pull pattern: the beneficiary withdraws.
• Dependency on an external call that may revert inside a critical function (liquidations, position closing): isolate it or make it tolerant to failure.
• Gas griefing and the 63/64 rule: a call forwards at most 63/64 of the remaining gas, so the caller can choose how much gas to leave so that the subcall fails while the outer transaction appears successful. In critical functions: check the result of the call, do not swallow the failure, and require a minimum of gas if the subcall must complete. Never wrap an external call in try/catch and carry on as if nothing happened.

5.10 Contract life cycle

• selfdestruct is deprecated: since EIP-6780 (Dencun, 2024) it only really destroys the contract if it runs in the same transaction in which it was created; in any other case it merely sends all the ether to the recipient. Every design that depends on "deleting the contract" is broken. FORBIDDEN in new contracts.
• CREATE2 and predictable addresses: the address depends on (deployer, salt, initcode). Two consequences: you can deposit into an address before a contract exists there (counterfactual), and the change in selfdestruct semantics alters the old assumptions about re-creation at the same address (metamorphic contracts). Set the salt so that a third party does not control it, and never assume an address with no code will stay that way.
• address.code.length == 0 does not mean "it is a person": it is false during the constructor and, with EIP-7702, also for EOAs with delegated code. Do not use it as access control.

5.11 Signatures

• EIP-712 for every piece of data signed by a user: a domain separator with chainId, verifyingContract, name and version. Without chainId the signature is reusable on another chain (and on any fork); without verifyingContract, on another contract.
• A nonce per signer and a deadline are mandatory. Without a nonce, replay within the same chain; without a deadline, a signature lives for ever.
• ecrecover malleability: it accepts the pair (s, n-s) — two different valid signatures for the same message. And it returns address(0) on failure instead of reverting: comparing against address(0) is not optional. Use OpenZeppelin's ECDSA (it forces s into the low range and reverts) instead of bare ecrecover. Never use the signature hash as a unique identifier — it is malleable; the identifier is the nonce.
• Curves other than secp256k1: since Fusaka there is the secp256r1 (P-256, EIP-7951) precompile, which makes it viable to verify passkey and secure-enclave signatures on chain. Use the precompile, never a Solidity implementation of the curve. (Curve choice and the life cycle of those keys belong to cryptography-pki-standards.)
• Smart accounts: verify with EIP-1271 (isValidSignature) in addition to ECDSA. With EIP-7702 on mainnet since Pectra (2025-05-07), an EOA can have delegated code: any logic that assumes a codeless msg.sender is a person is broken.
• permit (EIP-2612): it improves UX but introduces one more signature that has to be bounded with a deadline and a nonce; and not all tokens implement it (check, with an alternative path).

5.12 Cross-chain bridges

The category with the greatest accumulated historical losses and the one that tolerates a design error worst: there is no shared consensus between the two chains, so security rests on a set of signers, on a proof, or on a verifier — and that component is the target. Criterion: you do not write your own bridge; if it is unavoidable, the trust model is documented explicitly (who can mint at the destination and with what proof), message verification validates origin, destination, nonce and uniqueness, and the signer set is subject to the rules in §5.3. Figures (§8, verify before citing): DefiLlama puts cumulative losses from exploitation at more than USD 16.5bn, of which ~7.7bn is DeFi; the bridge figure appears as USD 2.9bn in one report and as USD 3,304m on DefiLlama's own page — declared discrepancy, verify at the source before using it. Two figures that correct the domain's intuition: private key compromise accounts for more than 25 % of thefts and appears in four of the ten largest, above any class of contract bug; and the largest recorded incident (Bybit, Feb 2025) was not a Solidity failure, but a signing and interface-approval failure. Writing a perfect contract and holding the key badly is the dominant failure mode.

6. Gas and operability

• Gas is a functional requirement, not an optimisation: a function that exceeds the block gas limit is not slow, it is unreachable for ever. A gas budget per critical function, measured (forge test --gas-report, CI snapshots that fail on regressions) and verified on the target chain, not only on L1.
• storage is the dominant cost: reading and writing persistent storage dominates any micro-optimisation of computation. Cache in memory inside the function; pack variables that are read together into the same 32-byte slot (and do not pack the ones that are not, or you pay for the masking with no benefit). immutable/constant for what does not change. Transient storage (EIP-1153) for state that lives within a transaction — verify support on the target chain.
• Events are a contract's telemetry: there is no stdout, no agent, no sidecar. Without events there is no possible operation — no monitoring, no state reconstruction, no detection of an attack in progress, no indexing. Rule: every relevant state transition emits an event, with the fields you need to filter by as indexed (a maximum of 3), including actor and amount. Emit after writing the state. And conversely: events nobody consumes are pure cost — each one must have a declared consumer (indexer, alert, accounting).
• Minimum production alerts: role and ownership changes, timelock queuing and execution, pause/unpause, upgrades, and economic thresholds (anomalous withdrawals, oracle deviation, drop in collateralisation). With a real on-call recipient.
• Deployed code size limit: it is still that of EIP-170 (24 KiB). EIP-7907 (raising the limit and metering the cost of loading code) was pulled from Fusaka at ACDE #216 and could be reconsidered for Glamsterdam: do not design counting on more space. forge build --sizes in CI; if it gets close, the problem is one of design (split into libraries or modules), not of optimiser flags.
• Per-transaction gas cap (EIP-7825, in Fusaka): a single transaction can no longer consume the whole block. Every heavy administrative operation (migration, mass initialisation, sweeping lists) must be paginable and resumable — if it does not fit under the cap, it does not exist.
• Layer 2: the cost model is different (data availability dominates over execution), and the opcode set lags behind L1 (see evm_version, §2). The sequencer is normally a single one: it changes the MEV model, introduces a single point of failure and means block.timestamp and transaction ordering have different guarantees. Verify per chain before assuming anything.
• Recent protocol changes that affect contract-writing criteria (verify in §8, do not cite from memory):
  • Pectra (mainnet 2025-05-07) introduced EIP-7702, with the impact in §5.10 and §5.11.
  • Fusaka (meta EIP-7607, status Final), activated on mainnet at the end of 2025. From its list, what changes contract criteria: EIP-7951 (the secp256r1 curve precompile — it enables verifying passkey/Secure Enclave signatures on chain at reasonable cost, see §5.11), EIP-7825 (per-transaction gas cap), EIP-7939 (the CLZ opcode), EIP-7823/7883 (bounds and repricing of MODEXP: review anything doing modular exponentiation), EIP-7935 (default block gas to 60M). The rest (PeerDAS, eth/69, the RLP block limit) is infrastructure. solc set osaka as the default EVM in 0.8.31.
  • Glamsterdam (ePBS EIP-7732, block-level access lists EIP-7928, gas repricing) was not activated on mainnet as of Aug 2026 — any criterion that depends on it is premature.
  • EOF was dropped from Fusaka and solc removed the experimental backend in 0.8.36: code, articles or tools that assume EOF are obsolete.

7. Sustainability and prohibitions

Cadence: review solc at every minor release (the bytecode of what is already deployed does not change, but anything new must be compiled with a compiler carrying the known bugfixes — consult the official list of bugs by version). OpenZeppelin: upgrade minors after reading the full CHANGELOG, never automatically. Security tooling, kept updated and with its version pinned in CI. Every deployed contract is re-reviewed when an external dependency its security model relies on changes (an oracle, a token, a bridge): you cannot update, but they can.

When NOT to use a blockchain. Honesty first: if the problem is solved with a database and a signature, it does not need a contract. A chain provides exactly one thing — verifiable execution with no shared trusted party — in exchange for cost per operation, latency, the impossibility of correcting, public exposure of data, and a regulatory regime of its own (MiCA: the transitional period for service providers in the EU ended on 1 July 2026; see grc-compliance-standards). If there is a trusted operator, if the data is personal (the right to erasure and an immutable record are incompatible), if errors need correcting, or if the only reason is the narrative: the correct answer is not to deploy a contract, and saying so is part of the job.

FORBIDDEN (requires written justification and explicit approval to make an exception):

• ❌ tx.origin for authorisation.
• ❌ Randomness derived from block.timestamp, blockhash, block.prevrandao or any on-chain state.
• ❌ A pragma with ^ or a range in deployable contracts; an unset evm_version; deploying without verifying the source code in the explorer.
• ❌ An AMM's spot price as an oracle; integrating a third party's view without analysing its behaviour under reentrancy.
• ❌ A value call/transfer before writing the state (a checks-effects-interactions violation); delegatecall to an address controllable by the caller.
• ❌ An implementation behind a proxy without _disableInitializers(); an upgrade without storage layout validation and without fork simulation.
• ❌ The owner/upgrader key in a single hot address; an upgrade with no timelock in a protocol holding third-party value.
• ❌ ERC-20 calls without SafeERC20; assuming 18 decimals; assuming that transfer moves exactly what was sent.
• ❌ Unbounded loops over data a third party grows; distributing funds by push in a loop.
• ❌ Swaps without minAmountOut and deadline decided by the user; infinite approval by default.
• ❌ Bare ecrecover (without checking address(0) nor normalising s); signed data without chainId, without a nonce and without a deadline.
• ❌ unchecked without a demonstrated bound; rounding in the user's favour in the protocol's accounts.
• ❌ Deploying without green invariant tests, without a closed external audit and without a written and rehearsed incident plan.
• ❌ selfdestruct in new contracts, and any design that depends on destroying or re-creating a contract at its address.
• ❌ address.code.length == 0 or msg.sender == tx.origin as a check for "it is a person".
• ❌ Home-made cryptography; reimplementing a standard OpenZeppelin already provides audited.
• ❌ Mythril, or any unmaintained tool, as a security control (useful only as an occasional confirmation).
• ❌ Including ready-to-use exploits, weaponised PoCs or attack recipes against specific third-party protocols. This skill is defensive: it describes vulnerability classes in order to prevent them. All offensive testing goes with scope and authorisation in writing, under offensive-security-standards.

8. Mandatory web verification

Before committing any datum from this document to a real project, verify on the web (Atom feeds and raw files; api.github.com returns 403 unauthenticated and the page summariser invents dates):

1. solc: https://github.com/argotorg/solidity/releases.atom and the raw Changelog.md. Check the current version, the default EVM and the official list of known bugs by version before pinning a pragma.
2. The EVM supported by the target chain (L1 and every L2 used): the operator's documentation. It is the datum that expires the most and the one that breaks a deployment irreversibly.
3. OpenZeppelin Contracts: releases.atom + raw LICENSE + the CHANGELOG of breaking changes. Check whether a 6.x major already exists.
4. Foundry and Hardhat: the v1.x tags of the Foundry repo (do not trust the rolling stable tag, see the discrepancy below) and Hardhat's releases.atom.
5. Security tools, one by one (maintenance status and licence, both change): Slither, Echidna, Medusa (AGPL-3.0), halmos (AGPL-3.0), kontrol (BSD-3-Clause), Certora Prover (GPL-3.0), Mythril (MIT, unmaintained). A repo with little activity does not imply abandonment: cross-check with the project's official source before discarding it.
6. Ethereum network upgrades: what is activated on mainnet and which EIPs it includes — read the fork's meta-EIP (eips.ethereum.org, e.g. EIP-7607 for Fusaka) and the Ethereum Foundation's blog, never third-party articles: several published EIP lists still include proposals that were pulled from the fork before it activated (EIP-7907 is the clear case). As of Aug 2026: Pectra and Fusaka activated, Glamsterdam not.
7. EIP-7702 and account abstraction: what is deployed on mainnet and how wallets treat it. A hot topic.
8. Loss figures: DefiLlama (/hacks, /hacks/total-value-lost) or another source that publishes data, not headlines. Cite the date of consultation.
9. Regulatory status (MiCA and equivalents): official sources (ESMA, the national authority). Engineering criteria only; the regulatory side belongs to grc-compliance-standards.

Declared discrepancies (Aug 2026):

• Foundry: the page of the rolli

…(truncated)