// Layer 1 — Process Flow
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.
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.
// Layer 2 — Key Logic
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
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.
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.
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.