Expertise / 01
Smart contract security
Challenge the assumptions, permissions, and economic edge cases in the code that moves value.
A trusted-looking signing screen is not proof of the action being signed.
Original Web3Sec diagram. On small screens, scroll the figure or open the full-size version.
Who this is for
A clear question.
A useful outcome.
Protocol teams preparing a release, changing an integration, or revisiting a security assumption after their system has evolved.
A useful contract review starts with what the protocol is supposed to preserve. Who can move assets? Which balances should reconcile? What remains true when an oracle is delayed, an administrator changes a parameter, or an external call behaves unexpectedly? We agree on these questions before choosing tools. The engagement connects implementation behavior to the assets, roles, and economic assumptions that make a defect consequential. Language, chain, protocol type, and available specialist coverage are confirmed during scoping.
What you should leave with
- Understand where a technical defect could violate an agreed protocol invariant and which prerequisites make the failure possible.
- Give engineers findings they can reproduce, assess, and turn into specific code or operational changes.
- Make the remaining assumptions visible to the people deciding whether and how to release.
Review boundary
What the work can cover.
Authorization and upgrade paths
privileged roles, initialization, ownership transfer, emergency controls, and the consequences of a compromised administrator.
Accounting and state transitions
deposits, withdrawals, shares, rounding, decimal scaling, fees, liquidation, and the ordering of dependent operations.
External trust
token behavior, callbacks, oracle freshness, signature verification, cross-contract interactions, and supported integration failure modes.
Economic behavior
economic scenarios relevant to the scoped design, including price manipulation prerequisites, unusual liquidity conditions, and incentives that diverge from the intended workflow.
From context to evidence
How the engagement works.
Establish the review boundary
Provide a pinned source commit, build instructions, architecture notes, intended invariants, deployed addresses if relevant, privileged-role details, and existing tests or previous reports. We identify omitted components and agree on test environments and review depth.
Test behavior and challenge assumptions
Read the important execution paths, compare code against the intended behavior, and use appropriate static analysis, targeted test cases, and invariant exploration. Tool output is triaged against reachable behavior; an alert by itself is not a finding.
Resolve and verify
Discuss consequential observations while there is time to act. The final report explains preconditions, affected paths, evidence, impact, and proposed remediation. An agreed retest examines a specified remediation commit and records any findings that remain unresolved.
Concrete outputs
Deliverables you can use.
Examples below are illustrative. They describe possible work products, not past client findings or promised results.
Threat and trust map
An illustrated account of assets, roles, dependencies, and security assumptions. Illustrative example: a withdrawal flow that depends on an external oracle and an upgradeable accounting module.
Evidence-based findings
A prioritized report with affected code, a reproducible scenario where practical, and engineering recommendations. Illustrative example: a rounding condition that violates a stated share-accounting invariant.
Remediation review
A status record tied to the fixes actually examined, including commit identifiers and any limitations. This is a review of specified changes, not an open-ended assurance over later releases.
Scope and responsibility
Boundaries worth agreeing early.
- Work is limited to the explicitly agreed repositories, commits, chains, and protocol behavior. New features or changes during review require a scope decision.
- Production transactions, privileged actions, and handling of live funds require a separately authorized procedure. Private keys and seed phrases are never review inputs.
- A review does not guarantee that a protocol is exploit-free or that its token, governance, legal structure, or business model is sound.
Before sharing code, customer information, or incident artifacts, agree on confidentiality and a private transfer channel. Keep the initial message high level.
Before we begin
Common questions.
Do you review an entire protocol or a specific change?
Either can be discussed. A focused change still needs enough surrounding context to understand its effects. We agree on the reviewed commit, dependencies, time allocation, and assumptions before work starts.
Will every finding include a proof of concept?
Evidence should make the issue assessable. A test or minimal reproduction is useful when practical and safe; some design or operational findings are better supported by a traced execution path and explicit prerequisites.
What happens when we fix a finding?
When retesting is included in scope, provide the remediation commit and relevant test changes. The review records what was verified and whether the original condition is resolved, partially addressed, or still present.
Go a little deeper
Practical reading.
Connected work
Related services.
Web & API pentesting
Follow the attack paths between identities, application workflows, APIs, and the systems they can reach.
Explore this service →03Incident readiness & response
Prepare the decisions, access, and evidence your team will need when normal assumptions stop holding.
Explore this service →06Security strategy & technical GTM
Connect security priorities, product decisions, and a technical story that stands up to scrutiny.
Explore this service →