# Smart contract security

Canonical: https://www.web3sec.news/services/smart-contract-security
Provider: Raiders (https://www.web3sec.news/about)

Challenge the assumptions, permissions, and economic edge cases in the code that moves value.

## Who this is for

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.

### Diagram: Verify transaction meaning outside the interface.

A trusted-looking signing screen is not proof of the action being signed.

![A transaction proposal must be independently decoded and compared with intended chain, destination, value, function and permissions before the signer authorizes it on a trusted device. The signing interface alone is insufficient evidence.](https://www.web3sec.news/diagrams/signing-verification.svg)

[Full-size SVG](https://www.web3sec.news/diagrams/signing-verification.svg) · [PNG download](https://www.web3sec.news/diagrams/signing-verification.png)

Original explanatory control model; not a reconstruction of private incident evidence.

## Outcomes

- 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.

## Scope

- 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.

## Process

### 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.

## Illustrative deliverables

These describe possible work products, not past client findings or promised outcomes.

### 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.

## Boundaries

- 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.

## 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.

[Discuss this work](https://www.web3sec.news/contact) · [Approach](https://www.web3sec.news/approach)