OpenChainGraph Suite · OCG v0.8.13 · Digital-Asset Rails

Stablecoin Examiner Pack

Note (dated 2026-08-08): a chain composes independent computations performed in an analytical order. No step's output is carried into the next step by the execution model; each step computes from its own declared inputs. This is true of every chain on this site.

Three landed nodes, run in the order an examination tends to run them: check the issuer's published monthly reserve disclosure against the arithmetic and attestation requirements the GENIUS Act sets out, recompute the published Proof-of-Reserves independently, then pin the sanctions-screening decision to the exact versioned dataset it ran against. Each stage emits its own hash-anchored artifact, and the pack emits one composite artifact over the three. What comes out is the evidence an examination asks a stablecoin issuer to produce. It is not a certification, and none of it is a solvency opinion.

OpenChainGraph · 3 Nodes, Linear compliance mandate Hash-Anchored §4 On-Chain Supply Is A Declared Input Client-Side · Zero PII · Zero Network Read

Not a compliance certification, not an audit opinion, not a solvency opinion, and not a regulatory filing. Every figure below is SUPPLIED by the user and treated as asserted: no stage fetches anything, looks anything up, or reads any blockchain. The pack produces the evidence a stablecoin examination asks for; whether that evidence satisfies any regulator is the regulator's call, never this page's. Reserve-asset composition is deliberately out of scope: no final GENIUS Act implementing rule exists to check composition against (dated observation, see below).

§4 Execution Hash · Workflow Definition Anchor

execution_hash:computing…

Workflow Stages · 3 Nodes · Linear

1 ROOT node

GENIUS Act Reserve-Disclosure Conformance Monitor art-582-genius-reserve-disclosure-conformance-monitor

GENIUS-shaped conformance over an issuer's published monthly reserve disclosure, covering 1:1 coverage arithmetic and attestation presence and timeliness, each with its own verdict of MET, NOT_MET or INDETERMINATE. Permitted-asset composition stays out of scope while no final rule text exists to check it against. The on-chain supply figure is a caller-declared number compared against the reported outstanding-token count: informational, never a requirement verdict.

MCP Call · check_genius_reserve_disclosure_conformance

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "check_genius_reserve_disclosure_conformance",
    "arguments": {
      "report_period": "2026-07",
      "period_end_date": "2026-07-31",
      "outstanding_tokens_reported": 4200000000,
      "token_price": 1,
      "total_reserves_usd": 4212500000,
      "attestation_present": true,
      "attestation_date": "2026-08-14",
      "examiner_registered": true,
      "examiner_name": "SYNTHETIC-CPA-LLP",
      "onchain_supply_check": 4200000000
    }
  },
  "id": 1
}

2 STAGE 2 node

Proof-of-Reserves Verifier art-584-proof-of-reserves-verifier

Independent recompute of the issuer's published Proof-of-Reserves data, covering a bounded Merkle-sum inclusion path, a liability-side branch aggregation, and the coverage ratio between the two recomputed sums, with an optional cross-check against a caller-declared published reserve figure. Consistency here concerns the internal arithmetic of what was published. It is never a statement about solvency, and never a statement that the published data is truthful.

MCP Call · verify_proof_of_reserves_consistency

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "verify_proof_of_reserves_consistency",
    "arguments": {
      "reserve_proof": {
        "leaf": {"hash": "a1b2c3...", "sum": 4212500000},
        "path": [{"hash": "d4e5f6...", "sum": 0, "position": "right"}],
        "expected_root": {"hash": "9f8e7d...", "sum": 4212500000}
      },
      "liability_branch": {
        "leaf": {"hash": "0011aa...", "sum": 4200000000},
        "path": [{"hash": "bb22cc...", "sum": 0, "position": "left"}],
        "expected_root": {"hash": "77ee55...", "sum": 4200000000}
      },
      "published_reserve_figures": {"total_reserves_usd": 4212500000}
    }
  },
  "id": 2
}

3 TERMINAL node

Sanctions Screening Evidence Pack art-585-sanctions-screening-evidence-pack

Binds a caller-declared sanctions-screening decision to the exact versioned dataset it ran against, by comparing a caller-computed digest of the artifact actually screened with the caller-declared published digest for that dataset version. This is evidence of process reproducibility, meaning the decision ran against that exact byte-identical list version. It is never evidence of screening adequacy: whether the list, thresholds and matching logic were any good remains the screening provider's problem.

MCP Call · build_sanctions_screening_evidence_pack

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "build_sanctions_screening_evidence_pack",
    "arguments": {
      "screening": {
        "query": "SYNTHETIC-COUNTERPARTY-01",
        "match_count": 0,
        "decision": "cleared"
      },
      "dataset_ref": {
        "dataset_id": "consolidated-sanctions",
        "version": "20260801-1200",
        "digest_algo": "sha256",
        "published_digest": "3b1f0a...64hex"
      },
      "caller_computed_digest": "3b1f0a...64hex"
    }
  },
  "id": 3
}

What An Examiner Asks For · What This Pack Hands Over

Show me the reserves covered the tokens outstanding at period end.

Stage 1 coverage arithmetic: reserves, liabilities, coverage ratio and any shortfall, with a per-requirement verdict and a reproducible hash over the exact inputs used.

Who examined the monthly report, and did it land inside the statutory window?

Stage 1 attestation check: days between period end and publication, whether a registered public accounting firm is named, and the window applied.

Did anyone check the Proof-of-Reserves arithmetic, or was the published root taken on trust?

Stage 2 recomputes the inclusion path and the liability branch from the published data and reports whether the recomputed sums agree with the published root and the declared reserve figure.

Which version of the sanctions list was that decision actually screened against?

Stage 3 pins the decision to a dataset id, version string and digest, and reports whether the digest of what was screened matches the published digest for that version.

Does the circulating supply on chain match what the issuer reported?

Stage 1 compares the two numbers and reports the delta, using a supply figure the caller declares. Nothing on this page reads a blockchain. See the limits below.

Limits Worth Stating Plainly

On-chain supply is a declared input, never a read. The caller pastes a circulating-supply number; Stage 1 compares it numerically against the reported outstanding-token count and reports a match or a delta. It reaches no requirement verdict. The pack cannot tell you the pasted number is the real chain state, because it never asks a chain. Reading supply directly from a light client is a named follow-on that depends on a Helios read sidecar shipping in AINumbers Helm, and it is not built here.
Reserve-asset composition is out of scope on purpose. Stage 1 checks coverage arithmetic and attestation timing only. Checking which assets are permitted needs final rule text to check against, and none exists on the date stamped below.
Internal consistency is not solvency. Stage 2 shows that published numbers agree with each other. An issuer can publish internally consistent numbers that are wrong. Whether the underlying data is truthful is the attestor's problem, not this recompute's.
Process reproducibility is not screening adequacy. Stage 3 shows that a screening decision ran against a specific list version. It says nothing about whether that list, those thresholds, or that matching logic were fit for the purpose.
Nothing here is a certification. The pack produces evidence. Deciding whether the evidence discharges a duty belongs to the examiner and the regulator.

Dated observation, checked 2026-08-08 against the Federal Register: no final GENIUS Act implementing regulation exists from any primary regulator. The OCC instrument remains a proposed rule (doc 2026-04089, published 2026-03-02, comments closed 2026-05-01). Two OCC comment windows were open on that date: PPSI reporting forms and instructions (doc 2026-11856, comments close 2026-08-11) and stablecoin licensing and registration application forms (doc 2026-15088, comments close 2026-10-05). The statutory effective date is the earlier of 2027-01-18 or 120 days after final regulations publish, so with no final rule the 120-day clock has not started. This is a research finding as of the date shown, not a legal conclusion, and it goes stale the moment a rule finalises. Check the primary sources yourself before relying on it.

Export Workflow Artifact

Download a §4-compliant workflow artifact with execution hash and step definition. Hash is deterministic over canonical {policy_parameters, output_payload} per RFC 8785/JCS.