Smart contract
security audit
Review code, business logic and asset flows in an agreed contract revision. Receive a report with findings, risk explanations and remediation recommendations.
A short description of your project is enough to start.
01 / REVIEW SCOPE
What does a contract security review cover?
A smart contract audit examines whether code implements its intended rules and where its behaviour could enable unwanted actions. We first identify assets, roles and trusted dependencies.
Access and administration
Administrative permissions, function restrictions, role changes and contract upgrades. Review who can change rules and control assets.
Accounting and assets
Deposits, withdrawals, rewards, vesting, rounding and boundary values. Compare implementation with the intended business rules.
Calls and dependencies
Reentrancy, external contracts, oracles and transaction ordering. TON reviews also consider message flows and sender validation.
Complementary review methods
| Method | What it contributes | Scope considerations |
|---|---|---|
| Manual review | Examine product rules, roles and sequences of actions. | Requires specifications, architecture and expected behaviour. |
| Automated analysis | Find common patterns and explore behaviour through tests. | Findings need manual validation; tools cannot infer all business requirements. |
| Formal verification | Check explicitly stated properties using formal methods. | Properties, the model and verification scope are agreed separately. |
We review ERC-20 tokens, ERC-721 and ERC-1155 NFTs, vesting, staking, and DeFi, DEX and DAO logic within an agreed scope. Each type has distinct accounting, access and contract-interaction rules.
02 / DELIVERABLES
A defined scope for meaningful findings
We define the contracts and flows in scope before starting. A contract review does not automatically cover the website, backend, wallets or infrastructure.
-
Code and environment
Repository, commit, compiler version, build instructions and tests.
-
Expected behaviour
Mechanics, roles, asset flows and valid states.
-
Review boundaries
Contracts, dependencies and integrations, with explicit exclusions.
-
Report and discussion
Findings, severity, technical reasoning and recommendations.
-
Retest
An agreed review of changes and updated statuses for the revised code.
03 / COST AND TIMELINE
Audit cost follows the code and review depth
Line count is only one factor. Contract interactions, economic logic, external dependencies and test readiness also affect the effort.
Scope and complexity
Contracts, roles, networks, custom logic and third-party components.
Review depth
Manual analysis, tools, additional tests and specified properties.
Readiness and retest
Documentation, reproducible builds and remediation review scope.
04 / REVIEW DELIVERABLE
What your audit report contains
The report should help your team reproduce issues, fix them and understand what was outside the review. The deliverable structure is agreed before work starts.
REPORT STRUCTURE · NO CLIENT PROJECT DATA
- Scope
- Repository and commit, contract list, methods and review limitations.
- Finding
- Title, severity, file and function, and conditions required for the issue.
- Reasoning
- Product impact, technical explanation and reproduction steps where applicable.
- Recommendation
- Suggested remediation and related changes to consider.
- Retest status
- The reviewed fix revision and whether the issue is resolved, partially resolved or still open.
05 / ARCHITECTURE AND VALIDATION
A review of a specific product revision
Source code and the configuration in which it operates both matter. Deployment, trusted roles and follow-up work are discussed explicitly.
Deployed contracts
Review the address and available source, including proxy and implementation details. Missing source or context limits the assessment.
Changes after review
New code or parameters can change behaviour. We identify which changes require further assessment.
Operations
Administrative keys, upgrade procedures and external services are considered as dependencies and separate risk areas.
An audit helps identify vulnerabilities but cannot guarantee that every issue has been found or certify complete security. Findings apply to the agreed code revision and review scope.
Technologies and integrations
Solidity and EVM
Permissions, external calls, accounting and upgradeable contract behaviour on Ethereum and compatible networks.
Analysis tools
Slither for static analysis, Mythril for symbolic analysis and Echidna for property-based fuzzing. Tools are selected for the code.
TON and message flows
Sender checks, replay handling, states and error processing. Review boundaries follow the TON architecture.
Technologies
Blockchains
Technical references: Smart contract security · Slither · Echidna
06 / PROCESS
How we work
-
Define scope
Agree on code, flows, access and exclusions.
-
Review
Combine manual analysis with suitable tools.
-
Discuss findings
Explain the issues and proposed remediation.
-
Review changes
Perform the agreed retest of the revised code.
07 / PORTFOLIO
Our development experience
All projectsExamples from our product portfolio. Each case describes the work delivered.
08 / FAQ
Before you start
What does a smart contract audit cover?
The agreed code revision, business logic, roles, asset flows and dependencies. Manual review, automated methods and retest scope are defined before work starts.
Can you check a contract using its address?
You can start with the network and address. A full review needs source code and intended behaviour. We consider proxies, implementations and configuration, and explain limitations when code is unavailable.
What do you need before starting an audit?
A repository link and commit, build instructions, tests, architecture, roles and external dependencies. If materials are incomplete, we first agree on what needs preparing.
How does an audit differ from an automated scanner?
A scanner helps detect known patterns. Manual review examines product-specific rules, action sequences and whether tool findings are valid. The methods complement each other.
Does an audit guarantee complete security?
No. The assessment is limited to a code revision, available information and an agreed scope. External services, operations and later changes can introduce additional risks.
Do you verify fixes?
Yes, the scope and process for a retest are agreed separately. We review changes against the recorded revision and update finding statuses. New features may require a broader review.
What determines audit cost and timeline?
Logic complexity, code size, networks, dependencies, documentation and review depth. Retesting and formal verification of selected properties are scoped separately where needed.
FREEBLOCK / LET’S TALK
Start with your project.
Share the network, repository link or contract address and a description of the mechanism. We will identify the review boundaries and materials needed for an estimate.