Smart contracts

A scan is not an audit

The distinction matters enough to draw before anything else. A professional audit is weeks of manual, protocol-specific reasoning by people who read your whole system, model your economics, and are accountable for what they sign. A Sentinelleai contract scan is automated: deterministic analyzers, a panel of AI models, and, where the target and chain allow it, a real transaction against a fork or testnet copy of your contract. It is the closest thing this platform offers to an audit. It is not one.

What you can submit

• Pasted source, or a whitepaper and governance notes alongside it for context.
• An uploaded project: multiple files or a whole folder. Build artifacts (compiler output directories), vendored dependencies (OpenZeppelin, forge-std, Solmate and similar), and test or mock files are filtered out automatically, the same way a firm scopes a review: source contracts only.
• A deployed contract, by chain and address. The verified source is pulled from that chain's own block explorer, and a proxy is followed through to its implementation before anything is analyzed.

Where an address is given, the platform can also compile the fetched source with the matching compiler version and compare the result to the bytecode actually deployed at that address, confirming whether the source about to be audited is the source that is really live, a proxy, or has drifted from it.

The pipeline

Every run follows the same order, and each stage's output feeds the next.

1. Deterministic tiers. Slither and Aderyn run first (Mythril, a symbolic-execution tier, is an operator-enabled add-on and is not enabled on the hosted service today), alongside an authority matrix (who may call what, who moves value, and whether the code matches its own documentation), deployed-drift detection (does the bytecode on chain still match this source), a fork-diff pass that flags the lines actually changed in a forked protocol, economic reasoning about spot-price and oracle dependencies, and upgrade/governance analysis of timelocks and who can shorten them. These findings reach the panel and the Judge as ground truth, not as a suggestion.
2. The multi-model panel. Several AI models, each briefed with a different viewpoint (a developer, an attacker, an economist, a historian of past incidents, a formal-methods reasoner, a protocol-design reviewer, and a reachability reviewer), read the source and the deterministic findings and each produce their own report. A Judge then consolidates all of them, weighing impact against likelihood. If too few models return a usable report, whether from a provider outage or exhausted credits, the run is marked degraded rather than presented as a full panel; it never fabricates a verdict to fill the gap.
3. Grounding. A deterministic pass, with no further model calls, checks every location a finding cites (a line number, a function name) against the real source. A finding that cites a line past the end of the file, or a function that does not exist, is flagged as low-confidence rather than silently trusted or silently deleted.
4. On-chain proof. Where the chain and finding allow it, the platform deploys the actual audited contract on a fork or a testnet and attempts one real transaction per finding: the call a finding claims is possible. The result is a transaction hash: the call moved value it should not have, or it reverted. Both outcomes are evidence. This is deliberately narrow. An attack here is a function call with literal arguments, inspected before it is ever signed, not free-form code the platform writes and runs unsupervised.

Supported ecosystems

Verdicts and score

A scan resolves to PASS, CAUTION, or FAIL, alongside a numeric score. PASS is withheld (the run is downgraded to CAUTION) when the run's own coverage, execution, or grounding data does not support the claim that the code was actually reviewed: a thin run cannot earn a clean verdict just because nothing was found. FAIL and CAUTION stand on their findings alone. See Reading a report for how severity and confidence are assigned to each individual finding.

On-chain proof and the testnet gate

For a deployed EVM contract, the on-chain proof step is not an optional extra layered on top of the scan; it is treated as part of what the scan delivers. It runs against a fork of that mainnet at a recent block, so the contract is exercised against its real deployed state — no funded testnet is needed, which is what lets every EVM mainnet in the footprint be proven the same way. A small class of findings depends on a live mempool — front-running and sandwich behaviour — and cannot be reproduced on a fork; only those are proven on a sibling testnet, and only then does the platform first check, live, that the testnet has a funded internal faucet, refusing the scan if that check cannot get an answer rather than reporting an unproven result as complete. This testnet gate does not apply to Tron or Starknet contract scans.

Deep verification add-on

A further, optional pass runs mutation testing and Echidna invariant fuzzing against your own repository's own test suite, not the panel, and not a generic analyzer. Mutation testing removes one guard at a time from your contracts and re-runs your tests to see whether anything notices; invariant fuzzing runs your own fuzz and invariant tests far deeper than your CI configuration usually allows. Neither tier invents a property or a test on your behalf.

This add-on only runs where your repository actually qualifies: a Foundry project with a green baseline test suite for mutation testing, an existing invariant harness for Echidna. A free pre-flight check confirms that before anything is charged. A repository that does not qualify is told exactly what is missing rather than being charged for a run that could not produce a result.

Scheduled audits

A contract or a saved source snapshot can be re-audited on a recurring daily, weekly, or monthly schedule. When the schedule targets a deployed address, each run re-fetches the live verified source rather than replaying a stale copy. Each schedule can also override the default alert behavior (silence, alert on FAIL only, or alert on any verdict change) independently of your account-wide alert settings.

1. 1

   Run or submit an audit

   Go to /audit and submit source, a project, or a deployed address.
2. 2

   Choose what runs

   Executable (Foundry) verification is on by default; the adversarial on-chain campaign is off by default, since it signs real transactions on a testnet or fork.
3. 3

   Read the verdict

   The report shows the deterministic findings, the panel's consolidated findings, coverage, and, when run, the on-chain proof outcome for each attempted finding.
4. 4

   Schedule it, optionally

   Turn a completed audit into a recurring one from the same page, with its own alert override.

What it stops short of

• No weeks-long, protocol-specific manual review, and no economic modelling beyond the four incident-class checks the deterministic tier runs.
• No formal verification of arbitrary invariants. The deep-verification add-on replays and deepens invariants your own team already wrote; it never invents or proves new ones.
• The multi-model panel can degrade: if too few models return usable output, the run says so rather than presenting a full panel that did not happen.
• Mythril (symbolic execution) is an operator-enabled add-on because of its cost: it is neither installed nor enabled on the hosted service today, so no report here includes a Mythril result.
• On-chain proof executes one literal function call per finding, never free-form, model-written code, and only where the chain, the finding, and (for cross-chain findings) the fork setup allow it.
• Cross-chain relay proof only ever runs against local forks of both chains, never a live bridge or a real counterparty chain.
• Cronos has no explorer API we can reach: its verified source is fetched through Sourcify when the contract is verified there, and otherwise has to be uploaded.
• A PASS verdict is not a certification, and the report says so on every copy, including its printable version.