Smart Contract Security: A 2026 Developer Guide
You've reviewed the Solidity, run a scanner, and maybe even received an audit report. Then a protocol's vault loses funds because a callback reaches a function before the contract has finished updating its state. The code did exactly what it allowed, and the team now has to explain why its checks didn't cover that path.
Smart contract security is the work of protecting funds and rules that users can't ask a clerk to undo. It's not just about writing safer Solidity. It's about designing, testing, deploying, governing, and monitoring a system whose behavior may be difficult to change once people rely on it.
Why One Contract Bug Can End a Protocol
A vault passes review, launches, and looks fine until a withdrawal triggers an external callback. The callback returns to the vault before balances are updated, so the attacker can withdraw against the same recorded shares again. By the time the team spots the pattern, the contract has already completed every transaction the code permitted.
Think of a smart contract as a vending machine. It completes every sale its programmed rules allow, including a bad one. There's no refund window after the transaction, and the machine won't reconsider the rules because the operator has noticed a problem.
The 2016 DAO attack made that risk a network event. An attacker exploited a reentrancy flaw in an Ethereum contract and diverted approximately 3.6 million ether, roughly one-third of the ether held by The DAO at the time. The incident led the Ethereum community to a controversial chain split, creating Ethereum and Ethereum Classic, and helped establish why security decisions can affect an entire ecosystem, not just one application. The history and its consequences are described in this USENIX Security review.
Three principles still shape protocol outcomes. Code holding user funds creates balance-sheet risk. Bugs can emerge from interactions between contracts, not just from a single function viewed in isolation. And because deployed code may be immutable, prevention, strong tests, and carefully governed changes become the practical safety net.
That means a serious review has to ask more than whether a function looks correct. It has to trace calls across contracts, examine who can change the system, and test the economic assumptions that make the rules safe. The practical map includes vulnerability review, upgrade choices, scanner limits, audit scope, and a workflow a candidate can defend in an interview.
Security hiring follows the same logic. Teams don't need candidates who can collect tool badges. They need people who can reduce the chance and impact of loss.
The Vulnerabilities Hiring Screens Still Miss
| Vulnerability | What fails | Review signal | First control |
|---|---|---|---|
| Reentrancy | State updates after an external call | Attacker-controlled callback before balances or shares finalize | Checks-effects-interactions plus reentrancy guards on cross-function paths |
| Access control | A privileged action is callable by the wrong account | Missing onlyOwner or role check, or an overly broad role |
Explicit roles, least privilege, and a tested emergency maintainer |
| Arithmetic on old compilers | Overflow or underflow wraps balances | Solidity below 0.8.x without checked math | Recent 0.8.x compiler and tests that still cover business limits |
| Oracle manipulation | Price or exchange rate is attacker-influenced | A spot price from a thin pool is used in one transaction | Time-weighted or multi-source feeds and deviation bounds |
| Flash-loan economic attack | A correct function breaks an economic assumption | Profit is possible without capital if a price, share, or collateral check is instant | Invariant tests under borrowed capital and delayed settlement |
| Unchecked external call | A failed call is ignored and state still commits | A call or send return value is discarded |
Check return values and prefer pull payments where they fit |
| Proxy storage collision | An upgrade writes over existing state | Implementation and proxy share a storage slot or a layout changes | Storage gaps, layout diffs, and disabled implementation initializers |
| Signature replay | A valid signature is reused across chains, contracts, or nonces | Chain ID, contract address, or nonce is missing from the signed hash | Include chain ID, verifying contract, and nonce in the signed data |
Use the table as a review checklist and as the order of questions in a hiring screen. Start with authorization and state transitions, then ask how the design handles external prices, borrowed capital, failed calls, upgrades, and signed messages.
Access control deserves more attention than many interview loops give it. Trail of Bits analyzed 246 smart-contract audit findings and found that access-control issues represented 10% of the findings, compared with 4% for reentrancy; it also reported that 50% of the reentrancy findings were high severity. That breakdown makes a reentrancy-only screen incomplete. Ask candidates to identify who can call privileged functions, whether each role has appropriate authority, and how a role-management failure could either enable unauthorized actions or block emergency maintenance. The figures come from Trail of Bits' audit findings summary.
A real reentrancy path needs more than an external call. The attacker must control a callback, and that callback must reach a relevant function before the contract finalizes critical state. This is why checks-effects-interactions matters: validate conditions, update balances or shares, then make the external call. Review cross-function entry points too. A guard on one withdrawal function won't necessarily prevent reentry into a different function that relies on the same unfinished state.
Consider a share vault that transfers tokens before reducing the caller's recorded shares. An attacker-controlled receiver reenters from its receive hook and withdraws against those shares a second time. A focused test should use a malicious receiver and assert that the second withdrawal reverts once the vault applies its state effects before the interaction.
Compiler protections help, but they have boundaries. Solidity 0.8 introduced default arithmetic overflow and underflow checks, which older versions lack, but those checks can't tell whether a protocol's business rules are sound. A vault can use a recent compiler and still accept a share price or collateral ratio that violates the design.
A strong candidate can explain both the control and what it doesn't prove. Ask them to review a privileged function, trace its callers, and name an adversarial test that would fail if authorization or state ordering is wrong.
Upgrade Models and Who Holds the Keys
Who can change a deployed contract's behavior, under what conditions, and how much time do users get to respond? That's the governance question behind upgradeability. A contract can avoid familiar code defects and still become dangerous if an administrator, multisig, governance vote, or compromised deployment process replaces its implementation.
OWASP's 2026 framework raised business-logic vulnerabilities to its second category and added proxy and upgradeability vulnerabilities as a distinct category. The framework was based on 122 analyzed incidents and approximately $905.4 million in 2025 contract-involved losses, according to the OWASP Smart Contract Top 10. The change underlines that secure code and secure authority are separate design problems.
| Model | Who can change behavior | Response time | User exit | Main risk |
|---|---|---|---|---|
| Immutable deployment | Nobody after deployment | No in-place patch | Users already hold the final code | A defect can only be mitigated by migration |
| Timelocked proxy | Multisig or governance after a delay | Hours to days, set by the timelock | Users can exit during the delay | A captured signer set still upgrades after the wait |
| Emergency pause | A small guardian set | Minutes, if signers are online | Funds frozen until unpause or migration | A pause key can censor or trap withdrawals |
| Staged rollout | Deployer promotes by cohort or cap | Fast for a slice, slower for full total value locked | Later cohorts can refuse the new code | Early cohort losses still hit real users |
| Governance or social recovery | Token voters or a recovery council | Vote and execution delay | Exit before execution if a delay exists | Low turnout concentrates power in a few voters |
Each model trades response speed against control and exit opportunity. An immutable deployment removes upgrade-key risk but leaves migration as the remedy for a defect. A timelock gives users time to react, but it can't make a captured signer set trustworthy. A pause can limit active damage, while also freezing withdrawals. A staged rollout limits how quickly a change reaches all users, but the first cohort still bears risk. Governance and social recovery distribute authority more broadly, though low participation can concentrate effective power among a small group.
A simple failure scenario makes the trade-off tangible. A 1-of-1 proxy admin points the proxy at an implementation that sweeps deposits. The code diff may look clean because the theft isn't in a reentrancy bug or an obvious arithmetic error. It's in who can approve the upgrade. A timelock, a published signer set, and a storage-layout diff reviewed before execution help expose different parts of that risk.
Every proxy also needs engineering controls: disable initialization on the implementation, compare storage layouts across versions, and rerun the same economic invariants in CI and after an upgrade. Monitoring should check whether the upgraded system continues to behave within those invariants once it's live.
Leads should decide and document the upgrade delay, signer set, and user exit window before the first deployment. Emergency patching can limit harm, but speed can reduce user consent. That tension belongs in the product and governance design, not only in the proxy code.
Scanners That Triage but Never Prove Safety
Scanner output looks precise, but a clean result doesn't certify safety. An empirical evaluation of 47,587 Ethereum smart contracts found that only 42% of vulnerabilities in the annotated dataset were detected by all evaluated tools; Mythril had the highest reported accuracy at 27%. In the largest dataset, 97% of contracts were labeled vulnerable, indicating a substantial false-positive burden. Those findings, from an empirical evaluation of Ethereum security tools, make automated analysis a triage layer, not a pass certificate.
A separate study shows why teams shouldn't patch raw alerts indiscriminately. Among 21,212 contracts flagged for reentrancy in a study of 139,424 deduplicated verified contracts, manual examination identified 31 true-positive contracts. More than 99.8% of the tool detections in that experiment were false positives, according to the reentrancy-detection study. An external call alone doesn't establish an exploit. The reviewer needs to find an attacker-controlled callback and a reachable path that reenters before critical state is finalized.
A scanner finding is a question to investigate. A clean scan is also a question, not an answer.
Run more than one analyzer, then use agreement to prioritize human review. Even when multiple tools flag the same pattern, verify exploitability against the protocol's actual state transitions and economic assumptions. Reproduce the suspected path with an adversarial harness, use stateful fuzzing, and test the conditions under which the contract's invariants should hold.
Static triage works best alongside differential review and property tests. A tool may recognize familiar code patterns, but a property test can check whether a vault remains solvent after a donation, whether its share price changes as intended, or whether borrowed capital can break a collateral rule. These are protocol-level properties, not just syntax patterns.
Researchers who examined 516 exploitable bugs across 167 real-world contracts from 2021–2022 concluded that more than 80% of the exploitable bugs were beyond the capabilities of existing tools, including defects involving business logic, economic assumptions, oracle manipulation, authorization, and cross-contract interactions. The finding appears in Galois' discussion of formal methods for smart-contract security. Tool coverage has a limit precisely where protocol-specific reasoning matters most.
For a practical overview of how teams use scanners as one part of review, see this guide to a smart contract vulnerability scanner. In an interview, listen for the candidate who can explain how they validated or disputed an alert, not just which tool they ran. Someone who treats a clean scan as permission to own a vault isn't ready to own one.
Audits as a Scope Not a Certificate
“Has it been audited?” is a weak endpoint for a security conversation. Ask instead: Which threats were outside the audit's scope, and who watches them after deployment?
In Q1 2026, six audited protocols were still exploited, including one that had undergone 18 prior audits, while smart-contract losses reached $86.2 million. H1 2026 data attributed roughly 76% of stolen funds to infrastructure and operational compromises rather than pure contract bugs, according to TechNext24's report on crypto hacks. An audit that concentrates on Solidity can miss the systems and people with authority over a protocol.
A useful report should explicitly list whether it reviewed or excluded privileged keys, deployment scripts, upgrade administrators, oracle dependencies, bridges, cloud and signer infrastructure, front-end transaction manipulation, and economic attacks. Those boundaries determine what an audit tells a team. If a report doesn't state its assumptions and exclusions, readers can easily mistake a limited code review for assurance about the whole protocol.
Consider a deployment that matches the audited commit, but whose deploy script uses a different initializer. Or imagine a price feed drawn from a spot pool that can be moved within one transaction, while the report never names the script or feed as a dependency. In both cases, code-level findings alone may not reveal the gap. Verify deployed bytecode against the reviewed artifact, and configure an on-chain monitor to page a human when the price deviates beyond an explicit bound.
What a lifecycle review should cover
Hiring managers should be able to recognize a lifecycle, not just a final audit PDF:
- Threat model before coding: Document privileged roles, dependencies, intended invariants, and likely abuse paths.
- Independent review: Ask a reviewer outside the implementation work to challenge the design and code.
- Invariant and property tests: Check that essential properties survive adversarial inputs and sequences of transactions.
- Deployment verification: Compare the deployed bytecode and initialization state with the reviewed artifact.
- Key-management controls: Make authority visible and constrain the people and processes that can exercise it.
- Incident response and monitoring: Define a runbook, watch on-chain behavior, and make it clear who receives alerts.
Every audit report should publish its exclusions, assumptions, privileged roles, upgrade paths, dependency risks, and post-deployment detection commitments. An audit badge can't communicate those boundaries on its own. Teams that want a deeper approach to specifying contract behavior can use this guide to smart contract formal verification.
In an interview, give the candidate a sample report and ask them to start with the exclusion list. Then ask what would page a human at 2 a.m. Strong answers name a signal, an owner, and a response path. The best follow-up is concrete: what would that alert detect that the audit didn't cover?
A Workflow Interviewers Can Verify
A strong interview asks candidates to demonstrate a secure-development workflow, not recite vulnerability names. Ethereum's security guidance recommends version control, pull requests, at least one independent reviewer, development-environment tests, static-analysis tools before each merge, a warning-free compiler build, and architecture notes in NatSpec. The Ethereum smart-contract security guidance gives teams a practical baseline to turn into visible evidence.
Five proof points to ask for
Version control: Ask the candidate to show a contract repository with a clear change history. Code should live in version control so reviewers can see what changed and why.
Pull request: Ask where a new change enters the review process. Every change should go through a pull request, with at least one independent reviewer.
Independent review: Ask the candidate to explain a review comment they received or gave. The useful signal is whether they can defend a decision, identify a risk, and respond to critique without treating the first implementation as settled.
Testing: Ask them to run or describe tests in a development environment. Then ask for one invariant that would catch a donation attack or a double withdrawal.
Deployment: Ask them to show how a release is built, checked, and documented. A deployment process should be repeatable, and the team should be able to verify which artifact went on-chain.
Compiler discipline is another concrete signal. Ethereum's guidance recommends a recent Solidity 0.8.x release without known severe bugs because that version family introduced default overflow and underflow checks. Build with a stable release and inspect warnings with the latest release, while remembering that compiler checks don't test authorization or business logic. A candidate should be able to state the exact compiler version and configuration used in a code sample, then distinguish what the compiler catches from what tests must cover. The Ethereum compiler security guidelines outline this version discipline.
Make the interview tasks practical: review a privileged function and identify its callers; show the CI job that blocks a merge; explain a storage-layout diff on an upgrade; and write or describe a property test that should fail when a donation distorts a vault's share price. Ask which tools run before merge, such as Aderyn, Mythril, or Slither, and what the candidate does when a scanner alert doesn't reproduce.
A small portfolio repo can show all of that better than a list of named vulnerabilities. Build a vault with failing-then-fixed tests, a pull-request review comment, a scanner report you challenged with a harness, and a one-page threat model. Pairing that kind of work with practical guidance on writing secure code gives an interviewer something specific to assess. For another way to think about structured technical assessments, see this resource on assessing engineering skills with AI avatars.
Enforcing the workflow in CI is the difference between naming Slither and showing readiness to work on a protocol.
Show the Workflow Then Search Security Roles
Build a small, reviewable proof of work over three days. The point isn't to create a production vault. It's to show how you turn security requirements into tests, review gates, and explicit assumptions.
- Day one: Choose a small vault and write three invariants: solvency, the expected share-price behavior after a donation, and no double withdrawal when a malicious receiver calls back.
- Day two: Add Aderyn or Slither to the pull-request workflow, require a clean compiler-warning gate, and run the invariant tests before merge.
- Day three: Write a one-page threat model listing privileged roles, the upgrade delay, oracle dependencies, and what's explicitly out of scope.
That packet gives a protocol hiring loop evidence to grade: the tests, the CI gate, the risk boundaries, and your reasoning about trade-offs. It also gives you a sharper basis for choosing roles. A smart-contract title can describe very different work, from product implementation to audit support, protocol security, or infrastructure.
Blockchain Jobs lists 6,934 open roles across crypto, DeFi, and Web3, including 1,696 at the Senior level. Listings show the employer, location, salary range when the poster provides one, category, and contract type, so you can compare roles against the work you want to do. Filter toward Security, Engineering, and Quality Assurance rather than treating every smart-contract title as the same job. You can also sign up for daily email alerts for new blockchain and Web3 jobs, so your search doesn't depend on repeatedly refreshing a board.
Prefer teams that explain audit exclusions, upgrade signers, and monitoring responsibilities over teams that offer an audit badge without those details. Finish the repo first, then apply where the job description asks who holds the keys and how changes are tested.
If you've built a small security workflow, use it to find roles where protocol teams value evidence, not just tool familiarity. Visit Blockchain Jobs to explore blockchain, DeFi, Web3, and security roles, and set up daily email alerts so new opportunities reach you as they're posted.
