From repository to public report.
00trust runs specialized AI agents over your contract code, combined with fixed, repeatable checks. It produces a structured report, binds it to the exact contract hashes that were audited, and lets you publish it on a page anyone can verify.
Before people trust a contract, they want an audit.
Smart contracts hold user funds and, on Midnight, private data. Today an audit is hard to get for most builders.
- /01
Audits are expensive.
A manual audit by a known firm is out of reach for most small teams, hackathon projects and early-stage builders. Many contracts go live with no review at all.
- /02
You need to know the right people.
There are few auditors, and even fewer who know Compact, Midnight's contract language. A new builder often does not know who to ask.
- /03
A self-audit counts for nothing.
A team that reviews its own contract gives users no reason to trust it. The value of an audit comes from an independent party publishing what it saw.
- /04
Audits go stale.
An audit covers one version of the code. Once the contract changes, users rarely know whether what is deployed is still what was audited.
Never “certified”. Always specific.
We audited this source code, at this commit, compiled with this compiler version to these hashes, on this date. Here is what we checked and here is what we found.
00trust never says a contract is “certified”, “approved” or “safe”. Every statement is tied to the audited version. A different version is a different audit.
- /01
Security
Vulnerabilities in contract logic, access control and state handling.
- /02
Confidentiality
Private data that could leak to the public ledger.
- /03
Protection of funds
Paths that could lock, drain or misdirect user assets.
- /04
Upgrade and maintenance
Who can change the contract after deployment, and how.
Nine steps, one account.
Sign up with email or a Cardano wallet. One account holds several projects, each with its own audits and public history.
- 01
Create an account
Sign up with email or with a Cardano wallet. One account can hold several projects.
- 02
Create a project
Name, short description, links, one or more GitHub repositories and a target network.
- 03
Connect GitHub or upload
Install the read-only GitHub App on the repositories you select, or upload an archive. Pick the branch or exact commit and the files in scope.
- 04
Pay in ADA
Sign a payment from your Cardano wallet. The audit unlocks once the transaction is confirmed.
- 05
First run
The agents return findings with severity, location and suggested fix, an acceptance score and a critical-issue score.
- 06
Fix and rerun
Fix the findings on GitHub and start a new run on the new commit with one of the remaining runs.
- 07
Generate the report
Generate the final report once no critical issue remains open. Remaining findings can be acknowledged with a comment.
- 08
Download or publish
Download the PDF and JSON, keep the report private, or publish a public audit page and a README badge.
- 09
New version, new audit
When the contract changes, start a new audit. Older audits stay visible with their own hashes and dates.
Nine agents. One job each.
A coordinator merges the agents’ findings and removes duplicates. A finding only reaches the report if it points to a real location in the code and the review agent can confirm it.
- 01
Scope agent
Maps the contract: circuits, ledger state, witnesses, entry points, who can call what.
- 02
Access control agent
Owner checks, roles, authentication of callers, privileged circuits.
- 03
Privacy agent
What becomes public on the ledger, use of disclose, witness data handling, linkability between transactions.
- 04
Funds agent
Token flows, balances, locked or unreachable funds, double spending paths.
- 05
Logic agent
State transitions, edge cases, arithmetic, assertions that can be bypassed.
- 06
Maintenance agent
Maintenance authority, verifier key replacement, upgrade and recovery paths.
- 07
Dependency agent
Compiler version, imported libraries, known issues in dependencies.
- 08
Review agent
Rechecks every finding from the other agents and discards those it cannot confirm in the code.
- 09
Report agent
Writes the final report in plain language, with locations and suggested fixes.
Every run goes through the same stages.
Each run audits one commit. You get a notification when it finishes.
- 01
Read
Read the files in scope at the selected commit directly from GitHub through the API. No clone.
- 02
Build
Compile the contracts with the pinned compiler version in a temporary, isolated space, only to produce the hashes.
- 03
Hash
Record the hash of each compiled artifact and each circuit's verifier key.
- 04
Load memory
For a rerun, load the previous commit, previous findings and their status, the contract map and the agents' notes.
- 05
Diff
For a rerun, compute what changed since the previous audited commit: files, circuits and lines.
- 06
Static checks
Run fixed, deterministic rules: pattern checks, known bad practices, configuration checks.
- 07
Agent analysis
Run the specialized agents in parallel on the code, the diff, the static check results and the audit memory.
- 08
Review
The review agent confirms or rejects each finding, and checks it against previous verdicts.
- 09
Scoring
Compute severity counts and scores with the public formula.
- 10
Save memory
Store the new findings, verdicts, contract map and agents' notes for the next run.
- 11
Result
Show findings and changes since the previous run to the owner in the dashboard.
- 12
Cleanup
Delete the temporary build files and any uploaded archive.
- queued
- building
- analyzing
- reviewing
- done
- failed
Same code. Same verdict.
A rerun is not a fresh audit. The agents start from where they stopped: previous commit, findings, verdicts, contract map and notes. Source code itself is never stored; only commit hashes and code fingerprints.
Same code, same verdict.
An unchanged code block keeps its findings, severity and wording from one run to the next.
A finding cannot disappear on its own.
A finding is only resolved when the code behind it changed and the review agent confirms the fix.
Severity cannot drift.
The severity of an unchanged finding cannot go up or down between runs.
Every change has a reason.
Any status change records the commit, the diff and the reasoning behind it.
New findings need new code.
A new finding must point to code that changed, or to code that interacts with it. Otherwise it is flagged as a late finding, with an explanation.
Version changes are visible.
If the agent version or rule set changed between runs, the report says so and labels any finding that comes only from that change.
A public formula. The same meaning on every report.
Acceptance score = 100 − Σ weights of open findings (minimum 0)
The critical-issue score counts open critical findings. It must be zero before a report can be generated.
| Level | Weight | Example |
|---|---|---|
| Critical | blocks | Anyone can call withdraw and empty the contract. |
| High | 15 | An admin key with no rotation path. |
| Medium | 5 | Transactions can be linked to the same user. |
| Low | 1 | Unused state, unclear error messages. |
| Info | 0 | Suggestions for readability. |
72%
- Criticalblocks generation
- High15 points
- Medium5 points
- Low1 point
PDF to read. JSON to verify.
Every report gets a unique ID and a report hash: the hash of the JSON report. That hash is what gets anchored on-chain.
- 01
Summary
Project, repository, commit, compiler version, audit date, network.
- 02
Scope
Files and circuits included and excluded.
- 03
Hashes
Compiled artifacts and verifier keys per circuit.
- 04
Scores
Acceptance score, counts per severity.
- 05
Findings
Severity, title, description, file and line, impact, suggested fix, status.
- 06
Owner comments
Shown apart from the audit findings.
- 07
Method
Agents, models and versions used, static rule set version.
- 08
Run history
What changed between runs.
- 09
On-chain anchor
Registry transaction and report hash.
- 10
Limits
What the audit does not cover.