Our contract is about to go live, and once published it cannot be recalled
Short answer
The first half of 2026 recorded 207 crypto incidents, 125 of them contract exploits — the most frequent attack type. A pre-launch audit traces reproducible attack paths, tests behaviour under stress, and re-checks after fixes. For one core contract the process takes 1–2 weeks.
Typical duration: 1–2 weeks for one core contract
USD 5,000 for contracts up to 500 lines · retest included
What this looks like
- The launch date is announced and there is no audit yet
- An exchange or investor asks for an audit report before proceeding
- The contract was written fast to catch market momentum
- Some parts can be changed after launch, but who may change them is unclear
- Nobody watches the contract once it is live
Why this happens
On-chain contracts differ from ordinary software in one decisive way: mistakes cannot be quietly patched overnight. Everyone can read them, including those looking for a gap, and funds that leave rarely come back.
That is why launch-date pressure is the most common source of loss in this space. What prevents loss is not the author's cleverness but the time spent trying to break it first.
How we solve it
- 01
Read the rules
We restate the rules that should hold, then compare them against what the code actually does. The gap between them is usually where the hole is.
- 02
Property & stress testing
Not just the happy path — random values and extreme conditions run repeatedly to surface the unthought-of.
- 03
Trace attack paths
Every finding comes with a reproduction, not a note saying "potentially risky".
- 04
Check authority
Who may change what after launch, and what happens if that key ends up elsewhere.
- 05
Retest
After fixes, re-checked and the final report issued.
- 06
Monitoring
Once live, anomalies are watched and an emergency stop path is prepared.
Numbers from our own work
125 of 207 crypto incidents in H1 2026 were contract exploits
Losses fell in the same period — credited to routine audits, bug bounties, and monitoring
We build and we audit; contracts are tested by people who understand how they were written
Mistakes we keep seeing
- Announcing a launch date before the audit is scheduled
- Treating the audit as a stamp instead of a remediation process
- Keeping upgrade authority on a single key held by one person
- Going live and then monitoring nothing afterwards
Questions we are asked most
How long does an audit take for one contract?
One to two weeks for a core contract. Interlocking systems take longer and are estimated once scope is clear.
What do we receive at the end?
A report with findings by severity, a reproduction for each, remediation steps, and the retest result after fixes.
Is the retest after fixes included?
Yes, one retest is included.
We were audited by someone else already. Do we still need this?
It depends what the earlier audit covered. If the system changed after it, the changed parts have never been reviewed by anyone.
What if we are already live and only now suspect a problem?
Contact us immediately. Post-exploit handling runs in a different order — saving the remaining funds first, fixing afterwards.
Updated 29 July 2026 · Neuraltan
If this is happening to you
Tell us the situation. We will say plainly whether this is worth doing now, and how long it takes.