Smart Contracts & Audit
Contracts you can deploy without flinching
We write, test and audit the contract layer — the part that is immutable once deployed, holds the funds, and gets read by people looking for a way in.
Talk to us about your projectWhy the contract layer is different
Most software can be patched on a Tuesday. A deployed contract cannot — it is public, immutable by default, and anyone can read it looking for a way in. That changes the order of work: the threat model comes before the feature list, and the tests come before the deploy script.
We also audit contracts we did not write. That is a different job: reading someone else's code without the assumptions its author carried, then writing down what we found and how much it matters. Sometimes the honest finding is that the contract is sound and the real risk sits with whoever holds the admin key.
Capabilities
What the work actually involves
Writing a new contract and reviewing one that already exists share their tooling and almost nothing else, so we scope them separately.
-
Contract design and threat modelling
We list the assets, the actors and what each could try, before any Solidity is written. That document becomes the test plan.
-
Solidity development
Contracts built on audited libraries such as OpenZeppelin rather than hand-rolled access control, because reinvented permission logic is where a surprising number of exploits begin.
-
Test suites that try to break it
Foundry unit tests, fork tests against real mainnet state, and invariant runs that generate random call sequences to break assumptions nobody wrote down.
-
Static analysis and fuzzing
Slither, Mythril and Echidna wired into the CI pipeline, so a regression is caught on the pull request rather than during the audit.
-
Audit of contracts you already have
We read code you already own, deployed or not, and return findings ranked critical through informational, each with the steps to reproduce it.
-
Gas optimisation
Measured with gas snapshots before and after, so a storage layout change is justified by a measurement rather than by habit.
-
Upgradeability and access control
A proxy pattern chosen deliberately or refused deliberately, plus a written list of every privileged function and who holds the key that calls it.
-
Deployment and verification
Scripted deploys to testnet then mainnet, source verified on the block explorer, and every deployed address recorded where your team can find it.
-
Monitoring and incident response
Alerts on the events that matter, plus a pause-and-respond plan written before launch rather than drafted during the incident itself.
What you get
The artefacts you keep
Every engagement ends with things you can hand to an exchange, an investor, or the engineer who inherits this.
- CONTRACTS
- Source, tests and deploy scripts
- The repository, the full test suite, and the scripts that produced each deployed address. Verified on the block explorer, so anyone can read what is actually running.
- AUDIT REPORT
- Findings ranked by severity
- Per finding: what the issue is, how to trigger it, what it could cost you, and the fix we recommend. Informational findings are included rather than quietly dropped.
- THREAT MODEL
- Assets, actors and assumptions
- The document that states what the contract protects and from whom. It is what a future engineer needs before changing a line, and what a serious investor will ask to see.
- OPERATING NOTES
- Keys, pauses and upgrade paths
- Every privileged function, who can call it, what pausing actually stops, and how an upgrade would work if you have one. Written for whoever is on call.
How we work
From threat model to verified on-chain
Timelines below are typical for one contract system. If the design cannot be made safe within the budget, we would rather say so in week one than in month three.
-
Scoping and threat model
1 weekWe map what the contract holds, who can touch it, and what an attacker would try first. The output is a written document, not a call.
-
Design review
1–2 weeksWe check the mechanism holds up before it is written. This step often changes the design and occasionally ends the project — cheaply, which is the whole point of it.
-
Build and test
3–8 weeksContracts written, unit and fork tests, fuzzing and static analysis running in CI, and gas measured as we go rather than argued about at the end.
-
Audit and deploy
2–4 weeksLine-by-line review, a severity-ranked report, then fixes and a re-test of each finding. Testnet first, mainnet only once the report is clear.
Is this the right service for you?
Worth reading before you get in touch — it saves both of us a call.
A good fit if…
- Real funds or real assets will move through the code
- You have contracts written and want them read before mainnet
- You can name every privileged role and who holds those keys
- You need a written report an exchange or investor will accept
Probably not, if…
- You need the whole platform around the contracts — see Custom Blockchain Solutions
- The product is a compensation plan — Blockchain MLM Software fits better
- Nothing genuinely needs a chain — Web & SaaS Platform Development fits
- You want a stamp of approval rather than the findings fixed
Frequently Asked
Questions
Common questions about scoping, auditing and deploying smart contracts.
Mostly the mechanism, not the line count. A standard token built on an audited library is a small piece of work. Custom staking, vesting, lending or reward maths is much larger, because each one needs its own invariant tests and its own threat model. After that it comes down to how many contracts talk to each other, whether you need upgradeability, whether the system depends on an external protocol or a price feed, and whether the code already exists or we are writing it. Tell us your budget and we will scope to it.
For a single contract using a familiar mechanism, expect roughly six to eight weeks from scoping to a verified mainnet address, including the review and the re-test. A multi-contract system with custom economics usually runs three to four months. An audit on its own, against code that already exists, is two to four weeks, plus however long your team needs to fix what we find. That re-test after the fixes is the step most schedules forget to budget for.
No, and it would be dishonest to imply otherwise. What we do is a full internal security review by engineers who write this code daily, with a written report you can share. For a contract that will hold significant user funds, we still recommend an independent third-party audit on top, and we will help you pick a firm and prepare the repository so that engagement costs less. A second set of eyes with no authorship bias is worth paying for.
You hear about it the day we find it, not when the report is finished. Then we work out what can actually be done with the contract as it stands: whether a pause function exists, whether an upgrade path exists, and who holds the key that would use either. If neither exists, the honest answer is a redeploy and a migration of funds and state, which is slow and expensive. That is precisely why the review belongs before the launch rather than after it.
You do, all of it. The repository, the test suite, the deployment scripts and the audit report are handed over and are yours to keep or to publish. We do not retain a private copy and nothing is licensed back to us. If you later want a different team to take over, everything they need is in the handover: the threat model, the tests we measured against, and the list of privileged functions with who can call them.
Yes, and a good share of this work is exactly that. We need the repository, any tests that exist, the deployed addresses if it is live, and an honest account of who holds the admin keys. Generated code is a particular case. It usually compiles and usually passes the tests it wrote for itself, then fails on the things a model cannot see: the economics, the ordering of calls, and what happens when a dependency misbehaves. We review it against the same threat model as anything else.