Proof of Audits
Start

Contest for discovery · Proof for protection

Turn contest findings into proof that stays verifiable after deployment.

Proof of Audits is the contest platform whose output does not expire — we turn validated contest findings into permanent, verifiable living proof that stays useful after deploy. Pre-audit, T4–T1 core, post-audit, Native scorer, then a living Trust Passport.

Start Protocol Assessment Already deployed?Explore Example Passport
Planning a new auditCreate a protocol evidence plan

Pre-audit readiness, T4–T1 core routing, post-audit fix proof, and a Native score path into a Trust Passport.

Start protocol assessment Already auditedVerify what still applies

Import the report, reviewed commit, remediation trail, build inputs, and deployment addresses without discarding prior work.

Review import decisions Already deployedCheck the system live now

Use the separate External ITS path for current-code, authority, operator, exit, and publication evidence.

Explore deployed review
A visual representation of protocol evidence connected across code, controls, and monitoring
Repository-backed exampleAtlas Lending - Native Example
1098 / 1400
What this score meansACTIVE with DIAMOND evidence

Repository, commit, contracts, chain IDs, and excluded scope are pinned before scoring.

Pre-auditcomplete
Fix reviewcomplete
Deployment5/5 exact
MonitoringWATCH_ACTIVE

Native protocol journey

Onboarding → pre-audit → core → post → score.

Five connected stages. Press any card for what happens, who does it, what evidence you receive, and what can block completion — then open the full product page for that stage.

01/ 05·Onboarding
01 · Onboarding
Product UI page

Declare the protocol and freeze intake evidence

You submit protocol identity, repository scope, chains, complexity inputs, prior audits if any, and the review you want. Nothing is scored yet — this creates the case and the evidence envelope.

Protocol founder or security lead submitting through Proof of Audits intake.

What you get

  • Protocol identity and contact
  • Repository / commit scope
  • Chain and deployment context
  • Requested review path

What blocks progress

  • Ownership cannot be verified
  • Repository or scope is missing
  • Contact cannot answer technical questions
  • Intake conflicts with an existing case

Technical surface

  • protocol/onboarding form
  • Scope and chain fields
  • Complexity inputs
  • Submission receipt
Start protocol onboardingNative pricing

One evidence trail from submitted code to live deployment.

Select a proof state to see the problem it solves, the action Proof of Audits takes, and the evidence your protocol receives.

01 of 08

Locked snapshot & scope

Scope locked

Before any core auditor starts, Proof of Audits locks your snapshot, checks readiness gates, maps risks, builds the invariant registry, clusters the code, and writes the core-audit brief. Scope is frozen. Gaps are listed. Auditors do not walk in cold.

View supporting methodology
Evidence rule

Score starts with a locked baseline - no moving source, no silent mutations before review.

Proof received

The full pre-audit pack: locked scope, readiness result, risk map, invariants, cluster plan, and a brief that drives routing.

Trust Passport

The score opens into evidence.

A protocol state is useful only when a visitor can see what is complete, what is missing, and which change would make it stale.

Native v5 / 1400
Repository-backed example
1098 / 1400: ACTIVE

This is the existing Atlas Lending repository example. It contains 19 recorded outputs, 5 exact deployments, and 4 submitted auditor-confidence records.

Start onboardingExplore live protocol evidence

Lifecycle proof

Keep every review tied to the exact code and decision that produced it.

  • Pre-audit plans and invariants
  • Core coverage by file, contract, and commit
  • Fix verification with deployment matching

Authority and people

Show who can change the system and who is accountable for each critical role.

  • Upgrade, multisig, timelock, and bypass mapping
  • Wallet-based critical-role binding
  • Role-specific interviews and evidence review

Operational review

Run one governed queue with visible evidence requirements and human decisions.

  • Evidence-bound skill jobs
  • Tool receipts and remaining-work queue
  • Reviewer approval before scoring or publication

Trust after launch

Keep the published record useful when code, controls, or operating history changes.

  • Exit simulations and user-control evidence
  • Release and upgrade discipline
  • Incident response, recovery, and proof history

Controlled lifecycle

Three review jobs. One evidence score.

Pre-audit makes the boundary testable, core audit reviews each risk surface at the right depth, post-audit proves remediation, and the native scorer explains the approved evidence without mixing score families.

01 / 05

Who performs it

Declare the protocol and freeze intake evidence

Protocol founder or security lead submitting through Proof of Audits intake.

You submit protocol identity, repository scope, chains, complexity inputs, prior audits if any, and the review you want. Nothing is scored yet — this creates the case and the evidence envelope.

Start protocol onboarding
Evidence produced
  • Protocol identity and contact
  • Repository / commit scope
  • Chain and deployment context
  • Requested review path
What can block completion
  • Ownership cannot be verified
  • Repository or scope is missing
  • Contact cannot answer technical questions
  • Intake conflicts with an existing case
View technical outputs
  • protocol/onboarding form
  • Scope and chain fields
  • Complexity inputs
  • Submission receipt

Structured routing

Route each risk surface to the right review depth.

Structured routing, auditor matching, four-layer coverage, and pricing impact are one system — swipe the segments to see how ownership, skills, depth, and funding fit together.

System part 01

Turn the approved scope into bounded review ownership

Each work unit has a defined code boundary, risk goal, evidence requirement, and independent validation path.

  1. 01Scope and call graph become review units
  2. 02Each unit receives an eligible owner
  3. 03Every finding stays tied to its reviewed boundary
  4. 04Validation cannot be performed by the same reviewer

Historical exploit exposure context.

Compare protocol value at risk with documented incidents. These figures do not predict losses or estimate how much a review will prevent.

Reported 2026 crypto hack losses$1.1B+

Reported by June 11, 2026. The source summarizes multiple incident categories and states that no platform can eliminate risk.

Bitrue, published June 11, 2026
Unverified-contract incidents$36.7M

Chainalysis identified combined losses across protocol-owned contracts whose source was not publicly verified.

Chainalysis, published June 9, 2026

Fix to production path

Prove accepted fixes reached production.

Walk the path from finding to invalidation. Each node is a proof state: remediation, independent decision, reproducible build, deployment match, monitoring, then stale when material conditions change.

01 / 07Finding

Finding

Accepted risk has a bounded owner

The record identifies the exact finding, affected scope, evidence, validator decision, and responsible review boundary.

Evidence stateFinding evidence and validated root cause
FindingRemediationDecisionBuildDeploymentMonitoringInvalidation

Already audited? Verify what still applies.

Keep prior security work, but separate historical evidence from what can still be reproduced and matched to production.

Import Existing Audit
Existing evidenceProof of Audits decision
Audit report
Historical evidence

The report is preserved as prior review evidence, not treated as current production proof.

Reviewed commit
Reproducible or unavailable

The source identity and build inputs are checked before the prior review can be connected to live code.

Remediation commits
Verified, incomplete, or changed

Accepted findings are mapped to fixes and material later changes.

Deployment addresses
Matched, partial, or mismatched

Runtime code, proxies, libraries, and initialization are evaluated separately.

Build configuration
Reproducible or missing

Compiler settings and linked inputs determine whether a bytecode claim can be reproduced.

See what determines the funding plan.

Use the public preview for orientation. Final reviewer counts, deposit, schedule, and exclusions require repository evidence and approval.

Use source lines expected to remain in the approved review scope.
Count implementation contracts and material dependencies.
Current selected scope4,200 source lines, 15 contracts
Preliminary review depthT4 + T3 + T2 + T1
Preliminary reviewer slots66
Engagement preview$49,500
Sequential duration22 estimated days
Pre-audit, 3 reviewer roles$9,900 / 20% of core
Core-audit review pool$49,500
Protocol deposit preview$61,875

$49,500 core pool + $9,900 three-role pre-audit + $1,485 protocol fee + $990 independent T1 review fee.

View preliminary tier breakdown
T442 reviewers$12,375 tier allocation1 review days
T315 reviewers$12,375 tier allocation4 review days
T28 reviewers$12,375 tier allocation3 review days
T11 reviewer$12,375 tier allocation14 review days

These values remain preliminary because browser inputs cannot replace an AST, call graph, whole-function clustering, or reviewer availability. The 22-day figure sums tier durations sequentially; parallel routing can shorten calendar time. The $120 Base attestation-gas reserve is separate. Post-audit is quoted later from the real fix diff. When T1 is selected, the independent final review stays at T1 because no tier exists above T1.

Open the full lifecycle calculator
Open Full Native Pricing

Choose the path that matches your current state.

The same proof system supports new audit planning, existing audit verification, and already-deployed protocol review without mixing their score families.

Planning a new audit
Create a protocol evidence plan

Pre-audit readiness, T4–T1 core routing, post-audit fix proof, and a Native score path into a Trust Passport.

Start protocol assessment
Already audited
Verify what still applies

Import the report, reviewed commit, remediation trail, build inputs, and deployment addresses without discarding prior work.

Review import decisions
Already deployed
Check the system live now

Use the separate External ITS path for current-code, authority, operator, exit, and publication evidence.

Explore deployed review

Accountability continues after publication.

Long-term assurance needs a published process, current evidence states, and independent decisions rather than another brand manifesto.

We remain accountable after publication.

When eligible evidence shows that an in-scope issue was missed, the case is reopened, ownership is reviewed, the public record is updated, and the published accountability policy determines remediation.

Affected code and exploit paths are mapped back to documented review ownership before an independent accountability decision. Assignment alone does not automatically prove negligence.

Read the accountability policy

The same state can reach the wallet.

Protocol evidence should protect more than an investor dashboard. Wallet users can see when deployed code or authority conditions no longer match the reviewed release.

MatchedCurrent proof found
Changed since reviewMaterial drift found
No current proofRequired evidence missing
Explore the browser extension

Inspect the methodology when you need it.

Technical terms, scripts, evidence formats, and policy detail stay available without forcing every visitor to learn the internal operating language first.

Questions protocol teams ask before onboarding.

Short answers first. Each answer links back to a reviewable product or methodology surface.

Build your evidence plan

Create proof that can survive deployment.

Start with your intended scope, or import a prior audit and verify what still applies to the system users reach today.

Create Protocol Evidence Plan Import Existing Audit