# Independent Settlement Attestation (Sample)

**Subject payTo:** `0xd779cE46567d21b9918F24f0640cA5Ad6058C893`
**Chain:** Base (`eip155:8453`)
**Window:** `2026-06-16T20:04:09.667639` to `2026-07-16T20:04:09.667639` (trailing 30 days)
**Generated:** 2026-07-16
**Ledger source:** independent Base settlement ledger, `payments.db` (read-only)
**Product:** Independent Settlement Attestation, 249 USDC

> This is a sample run on SmartFlow's own receiving address (the `keyshop` payTo).
> It is published so a prospect can see the exact structure of what they receive.
> Because the subject is our own public address, nothing here frames any third party.
> Even a five-cent window ships with full SQL: the point of the sample is the method,
> not the volume.

**Address provenance:** the subject address is the constant `PAY_TO` in
our keyshop service source (`keyshop.py`, line 45:
`PAY_TO = "0xd779cE46567d21b9918F24f0640cA5Ad6058C893"`),
the payment-receiving address advertised in the keyshop x402 402 challenge.

**Window derivation:** the upper bound is the most recent settlement timestamp
in the ledger; the lower bound is that value minus 30 days.

```sql
-- 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 `' '`, that space-separated form would admit extra
boundary-day rows. Use the `T`-format literal above.

---

## 1. Attested fields

| Field | Value |
|---|---|
| Settled count (window) | **1** |
| Settled volume | **0.05 USDC** |
| Distinct payers | **1** |
| Top-1 payer share (stated, not smoothed) | **100.00%** (1 of 1 payment; 0.05 of 0.05 USDC) |
| Top-5 payer share | **100.00%** (only 1 payer exists) |
| First seen (window) | 2026-06-18T07:00:19.211223 |
| Last seen (window) | 2026-06-18T07:00:19.211223 |
| Cadence | single settlement; no recurring cadence in window |
| Wash-flagged share | 0 of 1 (clean) |
| Catalog visibility | **listed historically, not currently observed**: 2 Bazaar endpoints carry this payTo, last observed 2026-06-12 and 2026-06-04; neither has appeared in a catalog scan since, while the catalog scan itself remains live (latest scan 2026-07-16) |

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

---

## 2. Settled count and volume

```sql
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.

---

## 3. Distinct payers and concentration

Concentration is stated as observed, never averaged or smoothed.

```sql
-- 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
```

```sql
-- 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
```

**Result:** a single payer accounts for the whole window.

| Rank | Payer | Tx | Volume USDC | Share |
|---|---|---|---|---|
| 1 | `0x9cc42f3d9245b867acccd630b43f906c1665b176` | 1 | 0.05 | 100.00% |

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.

---

## 4. Continuity (first seen, last seen, cadence)

```sql
-- 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
```

```sql
-- 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;
```

**Per-day settlement:**

| Day | Tx | Volume USDC |
|---|---|---|
| 2026-06-18 | 1 | 0.05 |

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):**

```sql
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.

---

## 5. Wash-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.

```sql
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.

---

## 6. Catalog-visibility check

This reconciles on-chain settlement against the subject's presence in the
public Bazaar catalog. Catalog source: `x402-network-mapper/mapper.db`,
table `bazaar_endpoints` (read-only).

```sql
-- 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
```

```sql
-- Listed endpoint detail
SELECT resource_url, first_seen, last_seen, times_seen,
       last_network, last_asset, last_scheme
FROM bazaar_endpoints
WHERE lower(last_pay_to) = lower('0xd779cE46567d21b9918F24f0640cA5Ad6058C893');
```

**Listed endpoints:**

| Endpoint | First seen | Last seen | Times seen | Network | Scheme |
|---|---|---|---|---|---|
| `https://api.smartflowproai.com/bazaar/health-check` | 2026-04-16T16:13:34Z | 2026-06-12T15:00:01Z | 227 | eip155:8453 | exact |
| `https://api.smartflowproai.com/bazaar/decision` | 2026-04-16T16:13:34Z | 2026-06-04T15:00:01Z | 194 | eip155:8453 | exact |

```sql
-- 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.

---

## 7. Methodology 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.

---

## 8. Reproducibility

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.

*Sample attestation on our own receiving address; client reports are identical in structure.*