LAST UPDATED: SEP 08, 2026 — DATA SOURCE: BASE CHAIN (L2)
SNAPSHOT VERIFIED · 1,712-row API extract · fingerprint e780ad3baa4a · awaiting same-origin monitor status
This dashboard applies the principles of Radical Transparency to our own campaign. Every transaction is recorded on the public blockchain ledger and independently verifiable on Basescan. TX hashes throughout this page are clickable — verify any claim yourself.
$662,511
All income sources · 998 txn
$495,969
All expenditures · 714 txn
$166,541
25.1% reserve ratio
~$28K
Average by calendar month
◈ Income Composition
◈ Expenditure Composition
◈ Monthly Income vs. Spend
$662,511
All income sources · 998 txn
$495,969
All expenditures · 714 txn
$166,541
25.1% reserve ratio
◈ Cash Waterfall — Income builds balance · Expenditures step it down · Final bar = current balance
—
Over date range
—
Over date range
—
Final balance
—
—
◈ Cumulative Raised vs. Spent
Total raised
Total spent
Cash on hand
—
Current trailing week
—
—
—
—
—
of rolling windows
◈ Cash Flow Velocity — 7-day rolling net (income − spend)
◈ Weekly Cash Flow — Income ↑ · Expenditure ↓ · Hover for details
Live blockchain ledger · Base L2 · 162 unique hashes
11 findings
⚠ Issue 1 — 2036 dates with incomplete corrections DATA ENTRY ERROR
Two original entries dated 3/3/2036 and 3/4/2036 (John Smith $500, Carolyn Rogerson $80) were recognized as year-typos. Correction attempts were made: both original records have reversal entries, and re-posted records with 2026 dates now exist. However, the correction is incomplete:
🔧 Remediation:
1. Verify whether the duplicate John Smith reversal is intentional or an error — if duplicate, post one corrective re-entry of +$500
2. Post the missing expense-side correction for John Smith's re-dated entry
3. Confirm Carolyn Rogerson's correction chain is complete (it appears to be)
Transactions are posted in batches — one hash per bank import cycle rather than one hash per donation. A single hash covers as many as 54 ledger rows totaling $18,854. This is not a data integrity problem, but reduces per-transaction auditability.
Top 10 hash groups by transaction count
🔧 Remediation:
Consider adopting a manifest-hash or Merkle root scheme for future batch imports — publish a per-batch manifest listing each individual record with its own checksum, anchored to the batch TX hash. This preserves batch efficiency while restoring per-item verifiability.
✓ Investigated — Chrissy Stone repeat donor NOT AN ISSUE
Two contributions from Chrissy Stone on Apr 17, 2026 — $19.99 and $49.99 — are different amounts consistent with two separate WinRed recurring subscription tiers active simultaneously. No duplication.
🔧 Remediation: None required. Recurring multi-tier donations are a normal WinRed pattern.
✓ Investigated — Category naming differences NOT AN ISSUE
The ledger uses granular bank-import subcategories (e.g., "Swing Wire Media" vs. "Swingwire Media") that a derived dataset might normalize. These are the same vendor at different spelling granularity. No financial correction needed.
🔧 Remediation: None required for existing records. For future imports, consider standardizing vendor names at the point of entry to prevent downstream normalization issues.
⚠ Issue 5 — Donor name variant: Marc / Marck Iacono DATA ENTRY ERROR
Three donations on Apr 13, 2026 appear under two spellings of the same name: Marc Iacono ($250 + $500) and Marck Iacono ($500), totaling $1,250. The Marck spelling is almost certainly a typo. This inflates the unique donor count by one and may affect FPPC reporting accuracy if the donor's legal name is used for threshold tracking.
🔧 Remediation: Correct "Marck" to "Marc" in the ledger by posting a reversal of the misspelled entry and re-posting with the correct name. Combined giving for this donor is $1,250.
⚠ Issue 6 — Donor name typo: "Anaonymous" DATA ENTRY ERROR
One Apr 15, 2026 donation of $20.00 is entered as "Anaonymous" — a misspelling of "Anonymous." This creates a phantom unique donor entry in the ledger distinct from the three correctly-spelled Anonymous donations on the same date.
🔧 Remediation: Correct "Anaonymous" to "Anonymous" in the ledger by posting a reversal and re-posting with correct spelling. All four Apr 15 anonymous donations are ≤$100 and within CA FPPC anonymous contribution thresholds.
The current automated scan flags 116 ledger rows across 56 potential duplicate-signature groups. New September review candidates include repeated rows for Uber $51.99, Redlands Residence Inn $207.96, United Airlines $278.40, and Southwest Airlines $11.20. The scan also finds same-day repeated contributions. Some matches may be legitimate separate transactions, so each should be checked against the bank import before a reversal is posted.
Two $2,500 payments to Late Apex Marketing are categorized as Administrative Expense. Based on the vendor name, these are almost certainly marketing expenditures and should be reclassified as Marketing Expense for accurate FPPC reporting. Reclassification would move $5,000 from administrative to marketing expense without changing total spending.
🔧 Remediation: For each record, post a reversal + corrected re-entry:
☐ Reverse Late Apex $2,500 (4/6/2026) as Administrative, re-post as Marketing — TX 0xcd66f432…
☐ Reverse Late Apex $2,500 (3/6/2026) as Administrative, re-post as Marketing — TX 0x926ad080…
This preserves the immutable audit trail while correcting the classification.
⚠ Issue 9 — source-name variants in the latest upload NORMALIZATION REVIEW
The latest batch contains source-label variants that split the same apparent donor or vendor across separate labels. Current examples include United AIrlines versus United Airlines, Reform CA - Voter GUide versus Reform California - Voter Guide, Susan WHitt, Westin HOtel, and Yolanda WIlliams. These variants do not change total dollars, but they reduce the accuracy of donor/vendor grouping and search.
🔧 Remediation: Add a controlled source-name dictionary at import time and normalize known variants in the presentation layer. Use reversal and corrected re-post entries only where the immutable ledger or required campaign filings must also be corrected.
⚠ Issue 10 — API aggregate and row-level totals do not fully reconcile RECONCILIATION REVIEW
The dashboard follows the ledger API's published aggregate totals, as previously selected. Independently summing the 1,712 returned rows produces differences of -$1,225.01 incoming, -$351.12 outgoing, and -$873.89 net. This does not prove that either result is wrong, but it means transaction count alone is not sufficient to verify synchronization.
MEASURE
API AGGREGATE
ROW SUM
DELTA
Incoming
$662,510.62
$663,735.63
-$1,225.01
Outgoing
$495,969.45
$496,320.57
-$351.12
Net
$166,541.17
$167,415.06
-$873.89
🔧 Remediation: Compare count, aggregate totals, business-date range, and the dataset fingerprint on every server-side monitor run. Investigate the aggregate calculation rules before treating row sums as interchangeable with API totals.
⚠ Issue 11 — records absent from the prior API snapshot SNAPSHOT REVIEW
The current API snapshot adds 501 row IDs but no longer returns 6 rows that appeared in the July snapshot, producing the net increase of 495 rows. The dashboard follows the current API response and therefore excludes the rows below. Their transaction hashes remain independently checkable; confirm whether these removals represent intentional corrections.
🔧 Remediation: Reconcile these six prior row IDs with the source system's correction or deletion history and retain this snapshot comparison as an audit record.