A smart contract audit and continuous smart contract monitoring are not competing purchases. They answer different questions. An audit asks whether the logic, the economics and the intent of one specific commit hold up under human review. Monitoring asks what has happened since, in the code and in production, and whether anyone is watching. A protocol holding user funds wants both.
A building gets a structural survey before you buy it. It also gets smoke alarms. Nobody sells the alarms as a substitute for the survey, and nobody argues that the survey means you can skip the alarms. One is a judgement about whether the structure is sound. The other tells you something is burning right now.
Quick answer
A one-time audit is deep human review of logic, economics and intent against a single commit hash. Continuous monitoring is what comes after: audit-grade scanning re-run on every commit, and detection on live on-chain behaviour. The audit finds what a scanner cannot reason about. Monitoring stops the audit going stale the moment someone merges a pull request.
There are three products here, not two
Most of this argument gets framed as audits against monitoring, which collapses two very different things into one word. Separating them is the whole decision.
| Manual audit | Continuous scanning | Post-deployment monitoring | |
|---|---|---|---|
| What it reads | Source, documentation, economic design, intent | Every commit and pull request | On-chain transactions and state, live |
| What it concludes | Whether the logic does what it is meant to, and what happens when someone attacks the incentives | Whether a change reintroduces a known class of flaw or expands the risk surface | Whether something abnormal is happening now |
| When it runs | Once, against a commit hash | Before every merge | Continuously, after deployment |
| Where it sits | Before a launch or a major release | In your CI pipeline | On the chain |
| What it costs | From $5,000 | From $399 a month | Quoted per protocol |
| What it cannot do | Stay true after the next merge | Reason about intent | Prevent anything. It tells you |
An audit report is a statement about a commit hash, and that is a feature rather than a limitation: it is what makes the report checkable against reality. The question is not whether the report expires. It is how far the deployed bytecode has drifted from the commit it describes, and whether anyone is measuring that distance.
What actually changes after the report ships
“The code changed” is too coarse to plan around. Here is what actually moves, and what each thing does to a report that was accurate the day it was signed.
| What changes | A normal example | What it does to the audit |
|---|---|---|
| New commits to in-scope files | A fix, a feature, a refactor | The bytecode running is no longer the bytecode reviewed |
| A proxy upgrade | A new implementation behind the same address | The address is the same. The code is not |
| Parameters and configuration | A fee, a cap, a collateral factor, an oracle heartbeat | The code is unchanged. The assumptions it was reviewed under are not |
| Roles and permissions | A new signer, or a permission granted for one job and left in place | Access control was reviewed against the roles that existed on the day |
| Dependencies and libraries | A router, a wrapper, a token standard, a compiler version | Code you did not write, and did not put in scope, changed underneath you |
| New integrations | A second oracle, a bridge, a new pool | The trust boundary moved outward |
| Governance actions | A proposal that ships code or retunes a parameter | A change with no pull request and no review window |
None of that is negligence. Every line is a normal Tuesday at a protocol that is still being built.
Four protocols, four different ways a report went stale
These are not stories about auditors, and none of them is a story about incompetence. In each case something moved after the review, and what moved is different every time. That is the point: audit decay is not one failure mode, it is at least four.
| Protocol | What moved | Gap between the change and the loss | Primary record |
|---|---|---|---|
| Euler | The code, through governance | 8 months | The protocol’s own upgrade proposal, and the transaction |
| Ronin | A permission. No code changed at all | 3 months after it stopped being needed | Sky Mavis’ own post-mortem |
| Curve pools | Nothing on their side. The compiler | About 2 years | A published CVE |
| Nomad | A value set during a routine upgrade | 6 weeks | Nomad’s own root cause analysis |
Euler: the change was itself an improvement
On 6 July 2022, Euler’s governance published eIP 14, a set of contract upgrades. Among them, in the proposal’s own words, was a donateToReserves feature: “This allows users to donate some of their ETokens to the reserves. This may be useful for certain wrapper contracts, and potentially could be a better way to burn ‘dust’ in an account (for gas refund purposes).”
It went through governance. It was published in public, on a forum, with code diffs attached. It was housekeeping.
Eight months later, on 13 March 2023, that function was the entry point for the exploit. The transaction is on chain, in block 16,817,996, timestamped 08:50:59 UTC.
Nothing about that eight-month window would have raised its hand. The change was deliberate, documented and small.
Ronin: no code changed at all
Sky Mavis’ own post-mortem is worth quoting exactly:
“This traces back to November 2021 when Sky Mavis requested help from the Axie DAO to distribute free transactions due to an immense user load. The Axie DAO allowlisted Sky Mavis to sign various transactions on its behalf. This was discontinued in December 2021, but the allowlist access was not revoked.”
A permission was granted to solve a load problem, stopped being needed a month later, and was still live in March 2022, when 173,600 ETH and 25.5m USDC left the bridge.
The same document says something else that belongs in this article more than anywhere else: “The hack occurred on March 23rd 2022, and was discovered on March 29th by the Sky Mavis team. We didn’t have a proper tracking system for monitoring large outflows from the bridge, which is why the breach wasn’t discovered immediately.”
Six days. No code scanner would have caught the stale permission, because no code changed. What would have shortened those six days is somebody watching outflows.
Curve pools: nothing changed on their side either
In July 2021, a storage allocation change in the Vyper compiler broke named re-entrancy locks. It stayed latent through two further releases and was fixed in 0.3.1 at the end of November 2021, and the flaw is now catalogued as CVE-2023-39363, affecting versions 0.2.15, 0.2.16 and 0.3.0.
Vyper’s own technical post-mortem is blunt about what happened next: “While bug was identified and patched by the v0.3.1 release, the impact to protocols using the vulnerable compilers was not realized at the time and they were not explicitly notified.”
On 30 July 2023, roughly two years after those compiler versions shipped, several Curve pools built with them were drained. Curve’s own post-mortem lists the pools and the amounts, including 6,106.65 WETH from pETH/ETH and 7,258.70 WETH plus 4,821.55 alETH from alETH/ETH.
The source code never changed. Re-reading it would not have found this, because the flaw lived in the translation from source to bytecode. What surfaces a problem of that shape is dependency and toolchain tracking, and that is a monitoring job rather than an audit job.
Nomad: the monitoring was live and watched the wrong thing
Nomad’s Replica upgrade reached production on 21 June 2022, in block 15,003,660. An initialiser set a value that had the effect of making unproven messages acceptable. Six weeks later the bridge was emptied: on chain, the bridge contract held about 87.46m USDC at 22:22 UTC on 1 August 2022 and roughly 78,600 USDC forty minutes after that.
Nomad had monitoring. From their root cause analysis:
“The Nomad Watchers observe and respond to compromises of the Updater key, but do not yet watch for suspicious activity arising from smart contract bugs. Because the vulnerability existed within the smart contracts’ process function, the messages required no fraudulent Updater signature, and therefore did not trigger Watchers.”
This is the case that keeps the rest of the article honest. Detection is only ever as good as what it is tuned to fire on. “Do you have monitoring” is the wrong question. “What does it fire on, and who answers” is the right one.
What continuous scanning genuinely catches
Continuous scanning is audit-grade static and AST (abstract syntax tree) analysis, run in your CI pipeline on every commit and pull request rather than once at the end. What it reliably finds:
- Known classes reintroduced in a diff. A new function without access control, an unprotected initialiser, an external call before a state update, an unchecked return value.
- Changes that expand the audited surface. A new external call, a new dependency, a new role, a swapped proxy implementation. Not findings, but a signal that the scope of your last review just moved.
- Regressions against your own report. Something that was fixed coming back in a later refactor.
- Dependency and compiler drift, which is the Curve case above.
- Divergence between the deployed bytecode and the commit your report names, which takes about two minutes to check.
Post-deployment monitoring is the other half, and it works on behaviour rather than code: griefing patterns, loss socialisation, unusual volume and slippage, access control irregularities, flash loan sequences, governance manipulation and oracle price deviation, with detection tuned to a protocol’s own logic instead of generic thresholds. What it produces is an alert with a severity and a documented escalation path.
What neither of them catches
- Intent. A scanner has no idea what your protocol is supposed to do. Logic that behaves correctly according to the code and incorrectly according to the business intent is invisible to a detector, and catching it needs a person who has read your documentation and argued with your assumptions.
- Economic and incentive design. Whether a liquidation is profitable to trigger early, whether a fee can be farmed, whether your pool can be pushed into a state the maths never anticipated.
- Genuinely novel classes. A detector fires on patterns someone has already characterised. The first instance of anything is found by a human, a bug bounty researcher, or an attacker.
- Everything off chain. Keys, signers, deployment pipelines, a compromised laptop. Ronin is the whole answer here, and no amount of contract review touches it.
- Prevention. Monitoring is a smoke alarm, not a sprinkler system. It shortens the gap between something happening and someone knowing, and Ronin’s own answer to that gap was six days. Shortening it is worth a great deal of money. It is still not a stop.
That list is why continuous scanning does not replace a manual audit, and why it is dishonest to sell it that way. The classes a scanner cannot reach are exactly the classes that empty a protocol.
When a change needs a human again
What matters is whether a change moved something the report was reasoning about. This is the working answer.
| The change | Scanner picks it up | Needs human review |
|---|---|---|
| A fix to a finding in your own report | Yes | Included. Two rounds of fix verification come with the audit |
| An edit inside an audited file, no new logic | Yes | Usually not |
| A parameter or configuration change | Flags it | Only if it moves an assumption the report rested on, such as a collateral factor or an oracle heartbeat |
| A new role or signer | Flags it | Yes, wherever it touches funds or upgrades |
| A dependency, library or compiler upgrade | Yes, as drift | Yes, if that dependency sits in a value path |
| A new external integration: oracle, bridge, pool | Flags the call | Yes. The trust boundary moved |
| A new contract added to an audited system | Yes | Yes, the contract and its interfaces |
| A proxy implementation swap | Yes | Yes |
| Redeploy to another chain | Yes | Yes, for chain differences and configuration |
| A structural refactor or rewrite | Yes | Full re-audit |
Most rows in that table are cheaper than the word “re-audit” suggests. A Fidesium manual audit includes two rounds of fix verification and one month of continuous scanning after delivery, so the first “we fixed it, is it fixed” cycle is already paid for. After that, scanning runs from $399 a month and manual work is priced against the diff rather than against the whole repository. A delta review of one changed file is not a new audit and should never be quoted as one.
So which do you actually buy
| Where you are | What to do first |
|---|---|
| Pre-mainnet, code frozen, launch date set | A manual audit. Nothing else answers the question an investor or an exchange is asking |
| Shipping weekly against an already audited codebase | Continuous scanning in CI, so the distance between the report and production stays small and visible |
| Live, holding user funds, nothing re-reviewed since launch | Both, and start with monitoring. A live protocol with nobody watching is the cheapest gap to close |
| About to add an integration, a chain, or a proxy upgrade | Human review of that change specifically. It is smaller and cheaper than a fresh audit |
| Asked for security evidence by an exchange, investor or enterprise buyer | The report, plus a record of what has been re-checked since |
“Security is a process, we deliver it” is Fidesium’s line, and the half people skip is that a process has to start somewhere. It starts with a proper audit.
Fidesium’s manual smart contract audits are line-by-line human review, chain agnostic with an EVM specialism, covering logic and economic risk, with two rounds of fix verification and one month of continuous scanning included. They start at $5,000, and the reports are public: the audit portfolio is the work itself rather than a summary of it. Each audit is minted as an on-chain NFT, so what was reviewed, and when, is a record rather than a PDF in a shared drive.
What keeps that report true is what happens next. Scanning on every commit and pull request before code ships, and post-deployment monitoring tuned to your protocol once it has. If you want the mechanics of how a report loses accuracy over time, we have written that up separately.
None of it makes a contract safe, and any firm telling you otherwise is selling something. What it does is keep the gap between what was reviewed and what is running small enough to see.
Frequently asked questions
Is continuous monitoring a replacement for a smart contract audit?
No. They do different jobs. An audit is human review of logic, economics and intent against one commit, and it finds the classes of problem a scanner cannot reason about. Monitoring keeps that review from going stale as the code, its dependencies and its permissions change. A protocol holding user funds wants both.
What is continuous smart contract monitoring?
It is two things that often get called by one name. Continuous scanning re-runs audit-grade static and AST analysis on every commit and pull request, before code ships. Post-deployment monitoring watches live on-chain behaviour after it ships, and alerts on activity that does not match the protocol’s own logic.
Do I need a new audit after changing my smart contract?
Not for every change. Fixes to findings in your own report are covered by the fix verification included with the audit, and an edit inside an audited file with no new logic usually needs nothing more than a scan. Human review is warranted when a change moves an assumption the report rested on: a new role or signer, a new external integration, a proxy implementation swap, a dependency in a value path, a redeploy to another chain, or a structural refactor.
My audit was six months ago and the code has not changed. Is it still valid?
Not automatically. In July 2023 several Curve pools were drained because of a flaw in the Vyper compiler that built them, catalogued as CVE-2023-39363. Those contracts had not changed at all. Dependencies, libraries, compilers and integrated protocols all move underneath code that is standing still.
What does continuous scanning actually catch?
Known vulnerability classes reintroduced in a diff, changes that expand the surface your last audit covered, regressions against previous findings, dependency and compiler drift, and divergence between the bytecode deployed on chain and the commit your report names.
What can continuous monitoring not catch?
Intent, economic and incentive design, genuinely novel vulnerability classes, and anything that happens off chain such as keys, signers and deployment pipelines. It also prevents nothing on its own. Monitoring shortens the time between something happening and someone knowing about it.
How much does continuous smart contract monitoring cost?
Fidesium’s continuous scanning starts at $399 a month and manual audits start at $5,000, with one month of scanning included after an audit is delivered. Post-deployment monitoring is quoted per protocol, because the detection logic is built against that protocol’s own behaviour rather than generic thresholds.
Does a bug bounty do the same job as monitoring?
No. A bug bounty buys you researchers looking for problems in your code, which is closest to the audit end. Monitoring watches what is happening on chain right now. They overlap very little, and an unmanaged bounty programme mostly produces triage work rather than security.
