Sample attestation, run on our own address

This is the exact artifact a client receives, executed against SmartFlow's own receiving wallet (the keyshop payTo). Even a five-cent window ships with full SQL. The point of the sample is the method, not the volume: every field is stated as observed, never smoothed, and the whole document is signed Ed25519.

00Window derivation

The upper bound is the most recent settlement timestamp in the ledger; the lower bound is that value minus 30 days.

-- Window boundary (upper = latest ingested settlement)
SELECT MAX(timestamp) AS window_end FROM payments;
-- window_end = 2026-07-16T20:04:09.667639

The lower-bound literal is constructed, not copied from SQL output: take window_end, subtract 30 days from the date part, and keep the exact YYYY-MM-DDTHH:MM:SS.ffffff text format, giving '2026-06-16T20:04:09.667639'. Note for reviewers re-running verbatim: sqlite's datetime(MAX(timestamp),'-30 days') returns 2026-06-16 20:04:09 (space separator, no microseconds). Because the ledger compares timestamps as text and 'T' sorts above ' ', the space-separated form would admit extra boundary-day rows. Use the T-format literal.

01Attested fields

Every number above is reproduced with its exact SQL in the sections that follow.

02Settled count and volume

SELECT COUNT(*)                        AS settled_count,
       COALESCE(ROUND(SUM(amount_usdc),2),0) AS settled_volume_usdc
FROM payments
WHERE lower(to_wallet) = lower('0xd779cE46567d21b9918F24f0640cA5Ad6058C893')
  AND timestamp >= '2026-06-16T20:04:09.667639';
-- settled_count = 1
-- settled_volume_usdc = 0.05

Result: 1 settled payment totalling 0.05 USDC in the 30-day window.

"Settled" here means a confirmed USDC transfer to the subject payTo that this ledger observed on Base within the window. It is an on-chain settlement fact, not an invoice, quote, or catalog listing.

03Distinct payers and concentration

Concentration is stated as observed, never averaged or smoothed.

-- Distinct payers
SELECT COUNT(DISTINCT from_wallet) AS distinct_payers
FROM payments
WHERE lower(to_wallet) = lower('0xd779cE46567d21b9918F24f0640cA5Ad6058C893')
  AND timestamp >= '2026-06-16T20:04:09.667639';
-- distinct_payers = 1

-- Top payers by volume (top 5)
SELECT lower(from_wallet) AS payer,
       COUNT(*)           AS tx,
       ROUND(SUM(amount_usdc),2) AS vol_usdc
FROM payments
WHERE lower(to_wallet) = lower('0xd779cE46567d21b9918F24f0640cA5Ad6058C893')
  AND timestamp >= '2026-06-16T20:04:09.667639'
GROUP BY lower(from_wallet)
ORDER BY vol_usdc DESC
LIMIT 5;
-- 0x9cc42f3d9245b867acccd630b43f906c1665b176 | 1 | 0.05

Top-1 concentration is 100%. Top-5 concentration is also 100% because only one payer exists. This is the point of stating concentration rather than smoothing it: a single-payer window is disclosed plainly.

04Continuity (first seen, last seen, cadence)

-- First and last settlement in window
SELECT MIN(timestamp) AS first_seen,
       MAX(timestamp) AS last_seen
FROM payments
WHERE lower(to_wallet) = lower('0xd779cE46567d21b9918F24f0640cA5Ad6058C893')
  AND timestamp >= '2026-06-16T20:04:09.667639';
-- first_seen = 2026-06-18T07:00:19.211223
-- last_seen  = 2026-06-18T07:00:19.211223

-- Settlements per day (window, at most 30 rows)
SELECT substr(timestamp,1,10) AS day,
       COUNT(*)               AS tx,
       ROUND(SUM(amount_usdc),2) AS vol_usdc
FROM payments
WHERE lower(to_wallet) = lower('0xd779cE46567d21b9918F24f0640cA5Ad6058C893')
  AND timestamp >= '2026-06-16T20:04:09.667639'
GROUP BY day
ORDER BY day;

First seen equals last seen: the window contains one settlement event on 2026-06-18, then no further settlement through the window end. There is no recurring cadence to report.

-- Settlement record (for reviewer reproduction)
SELECT tx_hash, block_number, chain, amount_usdc, timestamp,
       COALESCE(is_facilitator_mediated,-1) AS fac_mediated
FROM payments
WHERE lower(to_wallet) = lower('0xd779cE46567d21b9918F24f0640cA5Ad6058C893')
  AND timestamp >= '2026-06-16T20:04:09.667639';
-- 0xc58d17fe5b9f90498b60f37038dc2744ba5efea86831d3e3c22f4de2e7fba469
--   | block 47486722 | base | 0.05 | 2026-06-18T07:00:19.211223 | fac_mediated = -1 (unknown/null)

The tx hash above is a public Base transaction: any reviewer can spot-check it against a Base explorer or node, independent of this ledger.

05Wash-flag disclosure

The attestation reports gross settlement, and separately discloses how much of it carries a wash flag in this ledger, so the reviewer can judge for themselves.

SELECT COALESCE(wash_flag,'(clean/null)') AS flag,
       COUNT(*)                           AS tx,
       ROUND(SUM(amount_usdc),2)          AS vol_usdc
FROM payments
WHERE lower(to_wallet) = lower('0xd779cE46567d21b9918F24f0640cA5Ad6058C893')
  AND timestamp >= '2026-06-16T20:04:09.667639'
GROUP BY flag;
-- (clean/null) | 1 | 0.05

Result: 0 of 1 settlement carries a wash flag. The single window payment is clean.

06Catalog-visibility check

This reconciles on-chain settlement against the subject's presence in the public Bazaar catalog. Catalog source: a separate Bazaar snapshot store (mapper.db), read-only.

-- Is the payTo present in the catalog at all?
SELECT COUNT(*) AS listed_endpoints
FROM bazaar_endpoints
WHERE lower(last_pay_to) = lower('0xd779cE46567d21b9918F24f0640cA5Ad6058C893');
-- listed_endpoints = 2

-- Catalog scan liveness (so "not seen since" is meaningful)
SELECT MAX(last_seen) AS latest_catalog_scan FROM bazaar_endpoints;
-- latest_catalog_scan = 2026-07-16T15:00:02Z

Finding: the payTo is listed historically, not currently observed. Two endpoints carried it and were re-observed hundreds of times into June; the last catalog sightings are 2026-06-12 and 2026-06-04, both before this settlement window even opens (2026-06-16). Neither endpoint has appeared in any catalog scan since, while the catalog scan itself remains live (latest scan 2026-07-16). In a client report this distinction is stated exactly this way: "currently listed (seen in the latest scan)" versus "historically listed (last observed on a stated date)". Catalog presence at any point is not settlement, and settlement does not require catalog presence; the two are measured independently.

07Methodology and caveats

Data source. A single independent Base settlement ledger (payments.db), built from our own block ingestion, queried strictly read-only. Catalog facts come from a separate Bazaar snapshot store (mapper.db), also read-only.

Definition of "settled". A confirmed on-chain USDC transfer to the subject payTo, observed by this ledger on Base, with a timestamp inside the window. One ledger row equals one settlement.

Window. Trailing 30 days ending at the latest ingested settlement timestamp. Timestamps are ledger ingest timestamps derived from block observation, not independent block-clock times; near a window edge, ingest lag of up to roughly one hour can move a borderline payment across the boundary.

Timestamp formats. The ledger stores timestamps as text in mixed formats: older rows end in Z, newer rows carry microseconds with no zone suffix. Window filters are therefore string comparisons, and the boundary literal must follow the T-separated format shown in the window-derivation note above.

Ingest limits. The ledger reflects what our node observed. A payment our ingestion missed is absent here by construction. This is a lower bound on settlement, not a claim of exhaustiveness against all of Base.

ASR does not apply. This is a settlement ledger attestation. It reports what landed on-chain. It carries no Attestation-Success-Rate style success metric, because there is no request-response round trip being scored; there is only settlement fact.

What this report does NOT prove.

• It does not prove intent, identity, or legitimacy of any payer.
• It does not prove revenue quality: 0.05 USDC from one payer is disclosed as exactly that, not smoothed into a friendlier average.
• It does not prove the absence of off-ledger or unobserved settlements.
• It does not reconcile against, or dispute, any third-party indexer's totals; it only states this independent ledger's observation.
• Catalog presence does not imply settlement, and settlement does not imply catalog presence; section 6 shows the two measured independently.

Neutrality. We are not a party to any indexer, platform, or Bazaar operator that this attestation reconciles against, so it stays neutral to any dispute it touches.

08Reproducibility

Every figure above ships with the exact SQL that produced it, run against our independent settlement ledger. A reviewer with a copy of the ledger and the Bazaar snapshot can re-run each block verbatim; the settlement tx hash in section 4 can additionally be spot-checked on-chain against any Base explorer or node, independent of us. All queries are read-only (mode=ro); none mutate the ledger.

A client report is identical in structure: your payTo, your window, the same fixed query set, stated concentration, catalog reconciliation, and the same signature scheme. 48h turnaround.