Audit Evidence &Receipts Layer
Every execution of the NEXUS-120 Engine produces a cryptographically hashed record — a complete, sealed snapshot of protocol state and the verdicts it produced. These records are deterministic, tamper-evident, and committed to a public repository. They exist so that protocol claims do not depend on trusting any interface, dashboard, or team. Any party with access to the public repository can reproduce, verify, and dispute the record independently.
What a receipt is
A receipt is not a log entry. It is not a monitoring artifact. It is a deterministic execution record — the engine’s sealed account of what it read, what it computed, and what it concluded. Given the same inputs, the same outputs can be reproduced exactly. It captures inputs, outputs, and execution context in a single hashed object that can be verified, compared, and replayed. It is evidence, not interpretation.
Together these constitute a complete execution record. The package is hashed, the hash is committed alongside the package to a public repository, and both are accessible independently of this interface. A receipt can be verified, replayed, and audited by any party with access to the public repository and the engine source code. This interface shows you the data. The repository holds the proof. They are not the same thing.
Why receipts exist
The protocol does not ask you to trust this dashboard, this API, or this team. Receipts are the mechanism by which that trust requirement is eliminated.
This page, the /api/status endpoint, and the /api/receipts API all serve derived data. They can be wrong, cached, or manipulated. The canonical record is the package committed to the public GitHub repository. Receipts exist so that any discrepancy between this interface and on-chain reality is detectable.
An auditor with access to the nexus-receipts repository and the Arbitrum Sepolia RPC can independently reproduce every verdict. The engine source code is public. The chain state is public. The packages are public. No part of this process requires trust in a centralized party.
If a verdict is contested — if a stakeholder believes SOV_001 should have passed when it failed, or vice versa — the receipt is the record of what occurred. The hash prevents retroactive modification. The timestamp and block number anchor it to a specific, verifiable chain state.
Institutional reviewers require evidence that does not depend on a live system being available. Receipts are static, downloadable, and verifiable without RPC access. Each package is a self-contained state record sufficient for offline audit.
The audit trail is permanent. Packages accumulate over time, anchored to specific block heights and timestamps. This creates a verifiable history of protocol behavior that cannot be selectively edited — only appended to. An auditor reviewing protocol behavior in two years will have the same evidence chain available as one reviewing it today.
Three record formats
The NEXUS-120 Engine produces three categories of execution record. Each has a different scope, frequency, and primary consumer.
Complete point-in-time protocol snapshots generated on an hourly schedule via GitHub Actions. Each package contains all input fields (chain state, oracle status, protocol parameters), all output fields (pillar verdicts, fail classification, overall verdict, rationale), and a SHA-256 hash of the canonical JSON. These are the primary artifacts of the audit trail.
Published to: NEXUS120-Official/nexus-receipts/packages/ · API access: /api/receipts
WHY IT MATTERS: This is the record that makes all other surfaces auditable. Without AUD_001, /status and /api responses are unverifiable claims.
The result of a 5-year forward stress simulation across 5,000+ market scenarios. The engine runs the full risk lattice on each evaluation cycle and records the pass/fail result. The SOV_005 verdict is embedded in each AUD_001 package as sov_005_verdict. A PASS means the protocol survives all simulated scenarios above the safety threshold. SOV_005 does not affect overall_verdict — it is informational, not a blocking condition.
Embedded in: AUD_001 packages · Field: sov_005_verdict · Non-blocking: informational only
WHY IT MATTERS: SOV_005 FAIL with PASS overall_verdict is a meaningful signal — healthy now, structurally exposed under stress. The distinction is recorded, not hidden.
Raw execution traces produced by the engine on each evaluation tick. These records include the internal decision state at each step of the pillar logic: inputs received, thresholds evaluated, conditions checked, and the final determination. Runtime traces are the most granular evidence of engine behavior and form the basis for AUD_001 package generation.
Source: NEXUS-120 Engine runtime logs · Repository: NEXUS120-Official/nexus-receipts
WHY IT MATTERS: If an AUD_001 verdict is disputed, runtime traces are the step-by-step record of how the engine arrived at it. They are the audit trail behind the audit trail.
How to use receipts
Six concrete patterns for consuming the audit evidence layer. Each identifies the primary artifact, the key field to act on, and what the pattern enables.
Download the AUD_001 package directly from GitHub. Recompute SHA-256 over the raw field. Compare against package_hash. Inspect pillar verdicts and fail classification. No API access required — the repository is the source of truth.
package_hash integrity checkFeed the receipt inputs back through the open-source engine to reproduce the exact verdict. The engine is deterministic — the same inputs produce the same outputs. A replay mismatch indicates engine version drift or input data inconsistency.
Track sov_003_fail_count.economic across consecutive packages. Any increase from 0 indicates a real economic stress event. Compare timestamps for gaps — a missing hourly package indicates engine downtime, not protocol failure.
economic: 0 sustained over timeWhen a verdict is contested, the receipt is the record of what occurred. The hash prevents retroactive modification. The block number anchors the record to a specific, verifiable chain state. The verdict rationale captures the engine's determination at that moment.
verdict_rationale + block_numberReceipts are static, downloadable, and verifiable without RPC access. Provide the repository URL and package filenames to an auditor. Each package is a self-contained evidence record — no live system access is needed to review protocol history.
AUD_001_PACKAGE_{timestamp}.jsonAggregate collateral_ratio_pct, sov_003_fail_count, and overall_verdict across packages for time-series analysis. All timestamps are ISO 8601 UTC. Packages are sorted newest-first via /api/receipts.
timestamp_utc + collateral_ratio_pctVerification model
Each receipt is sealed with a SHA-256 hash computed over the canonical package JSON. The hash is committed to the public repository alongside the package. Verification requires only the package and a SHA-256 implementation — no external trust.
// Step 1 — Obtain the package from the public repository (no API required)
// https://github.com/NEXUS120-Official/nexus-receipts/tree/main/packages/
// Step 2 — Read the canonical package JSON
const pkg = JSON.parse(fs.readFileSync('AUD_001_PACKAGE_20260320T120000Z.json', 'utf-8'))
// Step 3 — Recompute SHA-256 over the raw field
// package_hash in the raw file is bare hex SHA-256 (no prefix)
const canonical = JSON.stringify(pkg.raw)
const computed = crypto.createHash('sha256').update(canonical).digest('hex')
// Step 4 — Compare against the recorded hash
const recorded = pkg.package_hash // bare hex: "f3af2d25..."
const valid = computed === recorded // must be true — mismatch indicates tampering
// Step 5 — Cross-reference chain state
// block_number and timestamp_utc can be independently verified on Arbitrum Sepolia
// via any public RPC or block explorer — no trust in this API required
// Step 6 — (optional) Follow the receipt index to individual pillar receipts
// Each entry in pkg.receipt_index has { pillar, file, hash }
// Verify each pillar receipt hash against the corresponding file in pillar-receipts/Where receipts fit
This protocol exposes three distinct intelligence surfaces. Each has a different function, a different trust model, and a different role in the verification chain.
Real-time protocol state. Live verdict, oracle quality, collateral ratio, pillar pass/fail. Mutable — reflects current chain state on each cache miss. Suitable for monitoring and decision support, not as an evidence record.
Function: interpretation →
Programmatic access to protocol state. Verdict semantics, field definitions, integration policy, trust model. Responses are derived from live or cached chain data. Not an evidence surface.
Function: access →
Cryptographic execution records. Hashed, committed, publicly verifiable. Immutable — the record cannot be changed after publication without detection. This is the only surface that constitutes proof.
Function: proof →
/status tells you what the protocol is doing right now — live, mutable, derived. /api-docs tells you how to read that signal programmatically and what each field means. /receipts tells you what the protocol has actually done — sealed, committed, independently verifiable. The first two surfaces are claims. This surface is proof.
AUD_001 audit packages
The 10 most recent AUD_001 packages from the public nexus-receipts repository. Each row is a sealed, cryptographically hashed execution record — a complete point-in-time account of protocol state and the verdicts the engine produced. Click any row to inspect the full package JSON, fail classification breakdown, and SHA-256 hash. The canonical source is the GitHub repository — this display is a convenience layer only.