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 reported by Stage 4 as a per-holding match against the statutory enumeration and nothing more: no final GENIUS Act implementing rule exists to check composition against, so no stage reaches a composition conclusion (dated observation, see below).

§4 Execution Hash · Workflow Definition Anchor

execution_hash:computing…

Workflow Stages · 4 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 STAGE 3 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
}

4 TERMINAL node

Stablecoin Reserve 3-Source Recompute art-603-stablecoin-reserve-3source-recompute

Granular recompute across three independently sourced, caller-declared legs. The reserve ratio is recomputed from the issuer's per-asset-class breakdown rather than the stated top-line figure, with an internal check that the lines actually sum to the total claimed. Weighted-average maturity is recomputed from that same breakdown and compared against the maturity figure reported in the EDGAR N-MFP Part 1 series summary, which is an extraction and is labelled as one. Each holding is flagged against the statutory GENIUS eligible-asset enumeration as a criteria match only, with the statutory catch-all item always INDETERMINATE. Three cross-source reconcile checks then run, each gated on the largest gap between the three declared as-of dates. A recompute of disclosed arithmetic: never a solvency claim, and never a statement that the disclosed figures are true.

MCP Call · recompute_stablecoin_reserve_3source

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "recompute_stablecoin_reserve_3source",
    "arguments": {
      "leg_a": {
        "report_period": "2027-02",
        "period_end_date": "2027-02-28",
        "as_of": "2027-02-28",
        "source_digest": "sha256:aaaa...64hex",
        "total_reserves_usd": 1050000000,
        "outstanding_tokens_reported": 1000000000,
        "token_price": 1,
        "reserves_in_fund_fraction": 0.8,
        "asset_breakdown": [
          {"asset_class": "us_coin_and_currency", "amount_usd": 50000000, "maturity_bucket_days": 0},
          {"asset_class": "treasury_bill_93d_or_less", "amount_usd": 800000000, "maturity_bucket_days": 20},
          {"asset_class": "government_mmf_solely_foregoing", "amount_usd": 200000000, "maturity_bucket_days": 25}
        ]
      },
      "leg_b": {
        "as_of": "2027-02-28",
        "source_digest": "sha256:bbbb...64hex",
        "accession_number": "0001234567-27-000123",
        "total_net_assets": 840000000,
        "wam_days": 21,
        "filing_date": "2027-03-05"
      },
      "leg_c": {
        "as_of": "2027-02-28",
        "source_digest": "sha256:cccc...64hex",
        "onchain_supply": 1000200000
      }
    }
  },
  "id": 4
}

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 as an informational figure. Stage 4 runs the same comparison as a verdicted reconcile check, RECONCILED, DISCREPANT or INDETERMINATE, gated on the gap between the declared as-of dates. Both use a supply figure the caller declares. Nothing on this page reads a blockchain. See the limits below.

Do the reserve lines actually add up to the total the issuer states?

Stage 4 sums the per-asset-class breakdown and reports the recomputed total, the stated total, the percentage delta between them, and whether it sits inside tolerance. The coverage ratio is then computed from the recomputed figure rather than the stated one.

What is the weighted-average maturity, and does the issuer's own breakdown agree with the fund's filing?

Stage 4 reports two separately labelled numbers: a maturity recomputed from the per-asset-class breakdown, and the maturity reported in the EDGAR N-MFP Part 1 series summary, which is an extraction rather than a recompute. A third check compares them, and a ceiling check runs against the 20-day figure from the OCC proposed rule, cited as proposed-rule detail rather than final rule.

Which reserve holdings match the statutory eligible-asset list?

Stage 4 flags each line against the eight-item statutory enumeration, one verdict per holding, MATCHES_CRITERION, DOES_NOT_MATCH or INDETERMINATE, with the statutory item number and label it matched. The catch-all item always returns INDETERMINATE. Concentration detail from the OCC proposed rule is reported in a separate array, visibly marked as provisional. There is no overall eligibility field of any kind.

Three sources measured on three different dates. How far apart are they?

Stage 4 echoes each leg's declared as-of date and source digest verbatim, reports every pairwise gap and the largest of them, and states the threshold applied. A reconcile check whose legs sit further apart than the threshold returns INDETERMINATE naming the exact skew, rather than being compared as though the two figures were same-dated.

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 reaches no requirement verdict; Stage 4 runs the same comparison as one of its three reconcile checks and does return a verdict on it. Neither can tell you the pasted number is the real chain state, because neither 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 handled as a criteria match, never as a conclusion. Stage 1 stays out of that question entirely, checking coverage arithmetic and attestation timing only. Stage 4 flags each disclosed holding against the eight-item statutory enumeration taken from the GENIUS Act text itself, one verdict per line, with the catch-all item always INDETERMINATE and never guessed. That is a per-holding match against statute text rather than a finding that the reserve satisfies GENIUS, and there is deliberately no overall eligibility field to mistake for one. Composition rules in final rule text do not exist to check against on the date stamped below.
Internal consistency is not solvency. Stage 2 shows that published numbers agree with each other, and Stage 4 shows that a per-asset-class breakdown adds up to the total claimed over it. 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.
A recompute and an extraction are different things, and Stage 4 labels which is which. The maturity figure computed from the issuer's breakdown carries the label disclosure_recomputed; the one taken from the fund's filing carries edgar_nmfp_reported. The two are compared, never blended into a single unlabelled number, and that comparison is directional rather than exact whenever the named fund holds only part of the issuer's reserves.
The 20-day maturity ceiling and the 40 percent concentration figure come from a proposed rule rather than a final one. Stage 4 reports them in a separately marked provisional array so they cannot be read as statutory. Re-verify both against the primary source before relying on either.
Three sources measured on three dates are not one measurement. Stage 4 never collapses the three declared as-of dates, reports every pairwise gap, and returns INDETERMINATE on any reconcile check whose legs sit further apart than the stated threshold rather than comparing them as if same-dated.
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.

Stablecoin Examiner Pack