Proof of Reserve / Backing Proofs

Proof of Reserve (PoR) is a core safety and trust primitive in Goldie. The protocol is designed to make backing claims:

• Publishable on-chain (tamper-evident)
• Monitorable (freshness and revocation are machine-checkable)
• Composable (tokens can plug in a backing verifier)

Goldie currently supports two on-chain reserve-record patterns:

• Document-based PoR: PreciousMetalReserveProof, with token-facing checks exposed through IBackingVerifier (via PreciousMetalBackingVerifier)
• Continuous CRE PoR: PoRConsumerV2, which stores the latest DON-produced reserve health report and emits monitoring events

This page describes three practical operating modes for producing proofs, with a strong focus on an automated custody-partner model using Chainlink and Chainlink CRE.

Presentation-friendly summary: Goldie does not claim “the chain can see vault gold.” Instead, it makes reserve evidence tamper-evident, time-bounded, and continuously monitorable, with clear responsibility boundaries for institutions.

At a glance

• Current reserve state is on-chain: document-based proofs live in PreciousMetalReserveProof; continuous CRE reports live in PoRConsumerV2.
• Freshness is enforceable or observable: document proofs expire after a maximum age (30 days in the reference implementation), while CRE reports refresh every 30 seconds and can be monitored for staleness.
• Revocation is explicit where applicable: document-based proofs can be revoked with a reason; CRE reports are superseded by newer reports rather than revoked.
• Evidence integrity is verifiable (auditor and self-attestation paths): manifest hash + Merkle-rooted document bundle + IPFS CID anchored on-chain.
• Near-live reserve health (Chainlink CRE path): structured report written to PoRConsumerV2 every 30 seconds via the KeystoneForwarder — no document bundle, no IPFS.
• Three operational modes: Chainlink CRE automation (custody partner API), independent auditor, or issuer self-attestation.

Options compared

What the on-chain module stores (and why)

This section describes PreciousMetalReserveProof — the contract used by Option 2 (auditor) and Option 3 (self-attestation). For Option 1 (Chainlink CRE), the relevant contract is PoRConsumerV2, which stores backingRatioBps, vaultWeightMg, tokenSupplyMg, reserveStatus, and aiRiskScore — no manifest or IPFS fields.

For the auditor and self-attestation paths, the PoR contract stores only the latest proof per token to keep gas costs low. Full proof history is emitted in events for indexing.

For each token, the latest proof includes:

• proofId: either an EAS attestation UID (when EAS integration is enabled) or a meaningful internal id (the manifestHash)
• timestamp: when the proof was published
• backingRatioBps: backing ratio in basis points (10000 = 100%) computed as goldWeightMg / tokenSupply
• manifestHash: integrity hash of a structured manifest (describing what is being proven)
• manifestCID: an IPFS CID to retrieve the manifest
• revoked: whether the latest proof has been invalidated

The publish transaction also includes a filesRoot Merkle root for a document set (audit report, custody statement, bar list extracts, etc.), enabling verifiable “document bundles” without putting the full content on-chain.

Freshness and minimum backing constraints

The reference implementation enforces:

• A freshness window: proofs expire after a maximum age (30 days).
• A minimum backing ratio: proofs below 95% backing revert.

These constraints make “no proof” and “stale proof” states explicit and monitorable.

What the protocol records

At a protocol level, PoR records are designed to be verifiable without trusting a single off-chain database, but the exact record depends on the operating mode:

• Auditor / self-attestation paths: IPFS CID(s), integrity hashes, filesRoot, timestamps, and optionally EAS UIDs
• CRE path: vaultWeightMg, tokenSupplyMg, backingRatioBps, reserveStatus, aiRiskScore, and report events written by the DON
• Validity semantics: timestamps and freshness rules for document-based proofs; near-live report cadence and event history for CRE
• Revocation: document-based proofs can be revoked with a reason; CRE uses updated reports and state transitions instead of document revocation
• Deterministic integrity where documents exist: manifestHash + filesRoot allow third parties to check that downloaded auditor/custodian files match what was published

What the protocol does not prove

The protocol does not “see” vaults. It does not independently prove real-world custody or audit truth.

Instead, it provides an auditable on-chain record of:

• who published a document-based proof or reserve report,
• what evidence bundle they pointed to (for auditor/self-attestation paths) or what reserve data they reported (for CRE),
• when it was published,
• whether a document-based proof is expired,
• whether a document-based proof was revoked,
• and how reserve health changed over time.

This is intentionally narrow: it makes proof publication and monitoring objective, while allowing deployments to choose how the evidence is produced.

Three operating modes

These three options do not all write to the same contract. Option 1 (Chainlink CRE) writes continuous reserve reports to PoRConsumerV2, while Options 2 and 3 publish document-based proofs into PreciousMetalReserveProof. The main differences are who is authorized to publish, how the evidence is produced, and what gets written on-chain.

Option 1 (recommended for continuous PoR): Custody partner reporting via Chainlink CRE

In this model, the vault custody partner exposes reserve data via API. Chainlink CRE connects directly to that API and delivers near-live reserve health reports on-chain — no manual step, no single operator.

This is not the same as the manifest/IPFS anchoring model used by the auditor path. CRE writes structured reserve data directly to a dedicated receiver contract (PoRConsumerV2) via the KeystoneForwarder. It does not produce IPFS document bundles or call createReserveProof().

Core idea:

• Custody partner remains the source of truth — CRE reads from their API, it does not replace them.
• Chainlink CRE runs as a DON workflow: multiple nodes fetch independently, reach consensus via median aggregation, and deliver a signed report on-chain.
• PoRConsumerV2 stores the latest reserve health report and emits events for monitors and dependent contracts.

What the DON writes on-chain each cycle:

Practical flow:

1. A CRE cron workflow triggers every 30 seconds.
2. Each DON node independently fetches vault custody data from the partner API.
3. Nodes reach consensus via median aggregation on vaultWeightMg and tokenSupplyMg.
4. Each node independently queries Gemini Flash for an AI risk score; the DON resolves consensus via median.
5. The signed report is delivered through the KeystoneForwarder to PoRConsumerV2.onReport().
6. A separate incident response workflow reads the latest report: if reserveStatus is CRITICAL and the issuer is still active, it sends a suspension command to CREComplianceExecutor, which calls IssuerRegistry.suspendIssuer().
7. A recovery workflow watches for reserves restoring to ≥ 100% and reactivates the issuer automatically.

Why this option is powerful:

• Near-live: reserve health is on-chain within 30 seconds of any vault state change.
• No single point of failure: DON consensus means no single node can corrupt the result.
• Autonomous enforcement: suspension and recovery happen on-chain without a multisig committee or manual approval.
• AI-augmented: risk scoring runs inside the DON under consensus — not an off-chain bot.

What this option does not provide (compared to the auditor path):

• No manifestHash / filesRoot / IPFS document bundle — there is no signed audit report.
• No EAS attestation UID — there is no independent third-party attester.
• The custody partner's API is the data source; its reliability is a trust assumption.

For deployments requiring formal audit sign-off, Option 1 (CRE) and Option 2 (auditor) are complementary: CRE provides continuous near-live monitoring, while periodic auditor attestations provide the independent assurance layer.

Option 2: Independent auditor publishes attestations (auditor-controlled)

In this model, an external audit firm (or accredited reviewer) is granted a PoR publishing role by the token authority. The auditor produces an audit report and then publishes the proof reference on-chain.

This is the document-based anchoring path: the auditor publishes a structured manifest, document bundle root (filesRoot), and IPFS CID via createReserveProof() on PreciousMetalReserveProof. In other words, this is where bar manifests, custody statements, audit PDFs, and similar files belong.

Goldie supports an optional integration with the Ethereum Attestation Service (EAS):

• When EAS mode is enabled, the on-chain proofId becomes the EAS attestation UID.
• The PoR contract can also revoke the attestation (and mark the proof revoked) when required.

This option works well when:

• proofs are periodic (e.g., monthly),
• the auditor must be the primary attester,
• or a compliance program requires an independent signer.

Option 3: Issuer self-attestation (issuer-controlled)

In this model, the issuer publishes their own backing proofs. This can be appropriate for early-stage deployments, private issuances, or pilots where the issuer can still provide documentary evidence but does not yet have a custody partner integration or independent auditor pipeline.

Like Option 2, this is also a document-based anchoring path: the issuer packages documentary evidence, anchors manifestHash / filesRoot / manifestCID on-chain through createReserveProof(), and can optionally pair that proof with an EAS attestation.

Even in self-attestation mode, the protocol still provides:

• integrity anchors (manifestHash, filesRoot, CID),
• explicit freshness rules (proofs expire),
• and revocation semantics.

For some deployments, self-attestation is paired with EAS so third parties can verify the attestation issuer and schema on-chain.

Freshness and monitoring

All PoR modes are monitorable, but they are monitored differently.

Monitoring checklist: auditor and self-attestation paths

• Freshness: the latest proof timestamp is within the validity window (or hasValidProof(token) is true).
• Revocation: the proof is not revoked (and if revoked, a reason exists).
• Backing ratio: the latest proof reports a backing ratio at or above the configured minimum.
• Evidence integrity:
  • the downloaded manifest hashes to manifestHash,
  • the supporting documents are covered by filesRoot via Merkle inclusion proofs,
  • and the manifest CID resolves to the expected content.
• Producer identity: who published the proof (issuer or auditor) is visible via transactions/events; if EAS mode is enabled, the proof id is an EAS UID.

Monitoring checklist: Chainlink CRE path

• Report freshness: PoRConsumerV2 continues receiving updated reports on the expected cadence (every 30 seconds in the current workflow).
• Reserve health: backingRatioBps and reserveStatus remain within acceptable thresholds.
• Source consistency: vaultWeightMg from the custody API stays aligned with on-chain tokenSupplyMg.
• DON-produced risk signal: aiRiskScore and its reasoning remain within expected bounds for the issuer.
• Autonomous enforcement: when reserveStatus becomes CRITICAL, incident-response workflows suspend the issuer; when reserves recover to ≥ 100%, recovery workflows reactivate the issuer.
• Producer identity: reports arrive through the trusted KeystoneForwarder into PoRConsumerV2, and downstream compliance actions are visible on-chain via events.

Diagrams

Chainlink CRE continuous PoR flow

Rendering diagram…

Proof publishing options and monitoring

Rendering diagram…