Three-Ledger Reconciliation — End-to-End Data Flow
The GENIUS Act requires three independent data sources to reconcile to zero variance at the snapshot moment. The diagram below shows how data flows from each source through collection, aggregation, and the reconciliation engine — and what happens when a break is detected.
DATA SOURCES COLLECTION AGGREGATION RECONCILIATION OUTCOME Blockchain RPC ETH · SOL · ARB · BASE POLYGON · OTHER Circle API Transparency endpoint Issuer circulating supply RPAF Attestation Third-Party RPAF Reserve FMV · Mar 2026 totalSupply() per chain ETH: 0xA0b86991… ARB: 0xaf88d065… BASE: 0x833589f… SOL: getTokenSupply() POLYGON: 0x2791Bc… ÷ 10⁶ → USD value GET /v1/stablecoins Parse USDC entries Sum across chains Ingest attestation.json Validate required fields Check permitted assets = Reserve FMV (USD) AGGREGATION On-Chain Total $44,827.4M Issuer Ledger $44,827.4M Reserve FMV $45,186.6M RECONCILIATION ENGINE TEST 1 — RCN-02 |On-chain − Issuer| Variance = $0.00M Tolerance: $0 (GENIUS Act §7) → RECONCILED TEST 2 — RES-03 Reserve FMV / Supply 100.80% Floor: 100.00% (GENIUS §4(a)(3)) +80 bps surplus → ADEQUATE IF VARIANCE > $0 → Log break entry → Alert Risk Officer within 15 min (RCN-04) RCN-01 · RCN-02 · RCN-04 · RES-03 PASS Opinion issued REVIEW Finding raised FAIL Material deficiency Snapshot: 17 March 2026 — 00:00:00 UTC · GENIUS Act §7 Three-Ledger Framework · Controls: RCN-01, RCN-02, RCN-04, RES-03
Why three independent sources? The GENIUS Act addresses what regulators call the "three-ledger problem" — the risk that the blockchain record, the issuer's internal books, and the custodian's reserve ledger could diverge without anyone detecting it. Each ledger can be manipulated independently. Only by comparing all three at the same snapshot moment can an auditor confirm that the reserve backing is genuine. RCN-02 requires this comparison at $0 tolerance — any variance is a reportable exception.
Three Annotated Code Snippets
The three most important and non-obvious steps in the reconciliation engine — not the full implementation, but the logic that matters most from a control design perspective.
Snippet 1 of 3 — Multi-Chain Supply Collection  RCN-02

Each EVM chain requires a separate totalSupply() call to the USDC contract address on that chain. The raw integer returned is denominated in micro-USDC (6 decimal places) — 1,000,000 = $1.00. Solana uses a different RPC method (getTokenSupply) because it has a different token architecture. The aggregate across all chains produces the on-chain supply figure for the left side of the reconciliation bridge.
Python — Multi-Chain totalSupply() Collection (RCN-02)
# EVM chains: call totalSupply() on the USDC contract per chain
# Each chain has a separate contract address — verified against Circle docs
USDC_CONTRACTS = {
    "ethereum": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
    "arbitrum": "0xaf88d065e77c8cC2239327C5EDb3A432268e5831",
    "base"    : "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "polygon" : "0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174",
}

for chain, rpc_url in RPC_ENDPOINTS.items():
    w3       = Web3(Web3.HTTPProvider(rpc_url))
    contract = w3.eth.contract(
        address=Web3.to_checksum_address(USDC_CONTRACTS[chain]),
        abi=ERC20_ABI
    )
    supply_raw = contract.functions.totalSupply().call()  # raw int, 6 decimals
    supply_usd = Decimal(supply_raw) / Decimal("1e6")     # → USD value
    chain_supplies.append(supply_usd)

# Solana uses a different RPC method — getTokenSupply on the mint account
solana_response = requests.post(SOLANA_RPC_URL, json={
    "method": "getTokenSupply",
    "params": [SOLANA_USDC_MINT]
})
amount   = solana_response.json()["result"]["value"]["amount"]
decimals = solana_response.json()["result"]["value"]["decimals"]
chain_supplies.append(Decimal(amount) / Decimal(10 ** decimals))

# Sum across all chains → on-chain supply for reconciliation bridge
on_chain_total = sum(chain_supplies)   # Control: RCN-02
Snippet 2 of 3 — Three-Ledger Variance Calculation  RCN-01  RCN-02  RES-03

The variance calculation is intentionally simple — the complexity is in ensuring the inputs are genuinely independent. The GENIUS Act requires $0 tolerance between the on-chain ledger and the issuer ledger. The coverage ratio must be at or above 100% at all times. Both tests run at the same snapshot moment so results are comparable.
Python — Variance Calculation & Coverage Ratio (RCN-02, RES-03)
# TEST 1: On-chain vs issuer ledger variance — RCN-02
# GENIUS Act §7 requires zero variance at the snapshot moment
# Tolerance is $0 — even $1 of unexplained difference is an exception
VARIANCE_TOLERANCE = Decimal("0.00")

variance = abs(on_chain_total - issuer_supply)

if variance > VARIANCE_TOLERANCE:
    # Reconciliation break — log to break log, escalate to Risk Officer
    # Risk Officer must be alerted within 15 minutes (RCN-04)
    raise_exception(
        control="RCN-02",
        message=f"Variance ${variance:,.2f}M exceeds $0 tolerance"
    )
    reconciled = False
else:
    reconciled = True   # On-chain == issuer ledger: PASS

# TEST 2: Coverage ratio — RES-03
# GENIUS Act §4(a)(3): reserve FMV must equal or exceed outstanding supply
# OCC NPRM Part III §3(b): 100% floor, computed daily
COVERAGE_FLOOR = Decimal("1.0000")   # 100.00%

coverage_ratio = (reserve_fmv / on_chain_total).quantize(
    Decimal("0.0001")
)
surplus_usd = reserve_fmv - on_chain_total

if coverage_ratio < COVERAGE_FLOOR:
    # Critical finding — reserves insufficient
    # Monthly RPAF attestation cannot be signed until resolved
    raise_critical(
        control="RES-03",
        message=f"Coverage {coverage_ratio:.2%} below 100% floor"
    )

# March 2026 result: coverage_ratio = 1.0080 (+80 bps) → PASS
# surplus_usd = $359.2M
Snippet 3 of 3 — Exception Escalation & Break Log  RCN-04

The distinction between running a control and evidencing that it ran is exactly what OCC examiners probe. The break log entry is not optional — it is the evidence that the reconciliation control operated on its prescribed schedule and that any exceptions were documented, investigated, and resolved. This is the gap most stablecoin issuers fail at: they run the reconciliation but have no formal break resolution process with documented evidence.
Python — Exception Escalation & Break Log (RCN-04)
def escalate_exception(snapshot, control_id, message):
    """
    Log exception to break log and alert Risk Officer.
    OCC NPRM requires Risk Officer notification within 15 minutes.
    Break log entry is the evidence that RCN-04 operated.
    Control: RCN-04
    """
    # Timestamped break log entry — this is the evidence the OCC examiner
    # will request when reviewing the reconciliation control (RCN-04)
    break_entry = {
        "timestamp"    : datetime.now(timezone.utc).isoformat(),
        "snapshot_date": snapshot.snapshot_datetime,
        "control_id"   : control_id,
        "description"  : message,
        "status"       : "OPEN",
        "owner"        : "Risk Officer",
        "disposition"  : None,   # populated on resolution
        "resolved_at"  : None,   # populated on resolution
    }

    # Persist to break log — in production: database write + audit trail
    write_to_break_log(break_entry)

    # Alert Risk Officer — OCC requires notification within 15 minutes
    # In production: email + Slack + PagerDuty
    send_alert(
        recipient=RISK_OFFICER_EMAIL,
        subject=f"[{control_id}] Reconciliation Exception — {snapshot.snapshot_datetime}",
        body=message,
        sla_minutes=15
    )

# ── RESOLUTION WORKFLOW (called when exception is closed) ─────────
def resolve_break(break_id, disposition, resolver, reviewer):
    """
    Record resolution of a reconciliation break.
    Every exception must have: timestamp, disposition code,
    resolver sign-off, and reviewer sign-off.
    This evidence is what the RPAF attestation depends on.
    """
    update_break_log(break_id, {
        "status"      : "CLOSED",
        "disposition" : disposition,   # e.g. "Timing difference — resolved T+1"
        "resolver"    : resolver,      # person who investigated
        "reviewer"    : reviewer,      # independent sign-off
        "resolved_at" : datetime.now(timezone.utc).isoformat(),
    })
// Layer 3 — Full Implementation
Request the Full Reconciliation Script
The complete Python implementation — all data collection functions, the full three-ledger reconciliation engine, exception escalation, break log persistence, control scoring, and the audit opinion generator. Fully annotated with regulatory context throughout.
  • 653 lines · Python 3.10+ · Dependencies: web3, requests, python-dotenv
  • Point-in-time audit context — designed for GENIUS Act §7 compliance
  • API keys as environment variables — no hardcoded credentials
  • Extensible to USDT, PYUSD, RLUSD, and MiCA frameworks
I will follow up personally within 24 hours.
Alignment with the Audit Work Program: The control IDs referenced throughout this page (RCN-01 RCN-02 RCN-04 RES-03) map directly to the audit work program tabs in the USDC Reserve Integrity Audit Dashboard. The process flow diagram above is the technical implementation of the reconciliation controls assessed in that work program. The monitoring system and the audit work program are two sides of the same engagement.