Proof of Reserve & Reserve Attestation Infrastructure

A financial audit and on-chain proof of reserve answer the same question on different timescales. An audit gives a signed opinion about one past date, weeks after the period closes; proof of reserve publishes the reserve-to-supply relationship continuously, verifiable by anyone against the blockchain. The differences are frequency (every update versus quarterly or annually), verifiability (anyone can check the chain versus reading a report), latency (minutes versus a lag that can reach 90 days), and scope (a live backing ratio versus a full opinion on controls and valuation). The two are complementary, not competing: an auditor still attests the figures, and the infrastructure makes that attestation continuously visible between reports. MiCA asks asset-referenced token issuers for both: an independent audit of the reserve every six months (Article 36(9)) and a reserve disclosure updated at least monthly (Article 30).

Under MiCA, an e-money institution issuing an e-money token (EMT) safeguards the funds it receives under the E-Money Directive, with at least 30% always held in separate accounts at credit institutions and the rest in highly liquid instruments in the same currency (Article 54). If the EBA classifies the token as significant, Article 58 moves the issuer onto the reserve, custody and investment rules written for asset-referenced tokens (Articles 36 to 38) and requires an independent audit of the reserve every six months; a national authority can impose the same rules on a non-significant EMT. Asset-referenced token (ART) issuers carry those rules from the start and must update the amount in circulation and the value and composition of the reserve on their website at least monthly (Article 30). Read as infrastructure rather than legal advice, these rules imply an operational pipeline: reserve data pulled from segregated accounts and custody, written on-chain so it is tamper-evident, reconciled against circulating supply, and packaged for the issuer's disclosures and its independent auditor. That is the system Protofire builds; interpreting your specific obligations belongs with your counsel.

The GENIUS Act, the United States framework for payment stablecoins, centers reserve reporting on three requirements: a monthly public reserve report, examination of that report by an independent auditor, and reserves held in eligible high-quality assets, principally cash and short-dated US Treasuries. Meeting that standard at scale is a data problem before a compliance one: reserve composition has to be pulled from custodians and fund administrators, reconciled against circulating supply, and surfaced every month for an auditor to sign. A real-time, on-chain data pipeline turns that monthly report from a fire drill into a continuous readout. The Act was signed into law on 18 July 2025, but its implementing rules from the US banking regulators were not finalised in time, so it takes effect on 18 January 2027; we scope each engagement against the rules as they are finalised.

A reserve attestation system is a pipeline of five components, and Protofire builds and operates every layer. A custodian API adapter reads reserve balances from the source of truth: a bank API, a custody platform, a SWIFT feed, or a tokenized-fund net-asset-value feed. A Chainlink Proof of Reserve external adapter brings that data on-chain through a decentralized oracle network; as a Chainlink core contributor we build and maintain these adapters, and we built the one behind Cache.gold's proof of physical gold custody before its CGT tokens ceased to be backed by gold on 30 September 2025. An on-chain aggregation contract in Solidity, deployed across EVM networks, runs the reconciliation engine: it compares reserves against circulating supply on every update, publishes the ratio, and flags any drift. A compliance dashboard renders the data for treasury, finance, and risk teams, with monitoring and alerting on any deviation. An automated reporting pipeline packages the figures for the independent attestor and regulators on cadence, and we keep it running after launch. What we do not do is sign the attestation, that is the independent auditor's role, by design. The oracle layer is one component here; teams that only need oracle feed integration for a DeFi contract should see oracle integration.

Three kinds of issuer need this most: EMT and stablecoin issuers, who owe monthly reserve reports under the GENIUS Act and reserve, safeguarding and audit rules under MiCA; tokenized-fund managers, whose NAV and share supply have to reconcile continuously for institutional holders; and RWA issuers, backing tokens with Treasuries, credit, commodities, or real estate that holders cannot see directly. The decision-makers are usually the CFO, the Chief Compliance Officer, and the Head of Treasury. The qualifying conditions, which we check before building, are concrete: a live token in circulation, a custodian or banking relationship with an accessible API or data feed, and a regulatory or holder-driven demand for verifiable reserves. Where the custodian has no usable data feed, we say so in scoping rather than after launch.

For a euro e-money token, our euro stablecoin issuance blueprint covers the reserve, monitoring and disclosure operation behind the token, and the reserve-capped mint controls blueprint shows minting that fails closed, with supply reconciled against safeguarded reserves.

Custodian API access and data format are usually the longest dependency, not contract complexity, so we sequence them first. We confirm the exact timeline and scope after a short discovery call.