# merkle-row sample receipts (live, anchored 2026-05-08)

Both samples in this directory were anchored on BSV mainnet via
`POST https://app.satsignal.cloud/api/v1/anchors` against the
`agent-runs` matter. The cryptographic objects in each `*.json`
file here are byte-for-byte identical to what the server hashed
into the on-chain transaction — the client-computed Merkle root
matches the server's response exactly.

## merkle-row-v1 (standard, manifest mode)

- **bundle_id:** `de04a33002354793`
- **txid:** [`4fc609d83c59fb173848f879ff78148dea3f797ddc2bf65a8c670ba84a8d383d`](https://whatsonchain.com/tx/4fc609d83c59fb173848f879ff78148dea3f797ddc2bf65a8c670ba84a8d383d)
- **leaf_count:** 5
- **root:** `46788ed6fed1498de0b8af5129479afc08b76f67f812702db416501eb358f216`
- **artifacts:**
  - `standard-rows.jsonl` — the five eval-result rows (input)
  - `standard-anchor-body.json` — the literal POST body (output of the helper)
  - `standard-anchor-response.json` — the API's 200 response
  - `standard-reveal-row-2.json` — single-row reveal payload for row index 2
- **client-recomputable:** Re-run `merkle_row.py build-standard --rows-jsonl standard-rows.jsonl --matter-slug agent-runs --label "merkle-row-v1 sample"` and you get the same items[] sha256s and the same Merkle root.

## merkle-row-sealed-v1 (sealed-style, commitment mode)

- **bundle_id:** `007dff5816814594`
- **txid:** [`d623cb94d09c6d02b11fcd239667e12fab0929ce281b79b7e0964053a6c4dcc8`](https://whatsonchain.com/tx/d623cb94d09c6d02b11fcd239667e12fab0929ce281b79b7e0964053a6c4dcc8)
- **commit-doc sha (on-chain commitment):** `f3dd742039a4c287d23f735cb59833f669d1ff96dc50fab0c173a24608ef3584`
- **leaf_count:** 5
- **root:** `a67956a2d0ca871b665da9d99fb1ac2dc3690d9484bcac23dd09c2c5ae477bf7`
- **artifacts:**
  - `sealed-commit.json` — the commit doc + anchor sha/file_size
  - `sealed-anchor-response.json` — the API's 200 response
  - `sealed-reveal-row-2.json` — single-row reveal payload for row index 2
- **public lookup:** `https://proof.satsignal.cloud/lookup_hash?sha=f3dd742039a4c287d23f735cb59833f669d1ff96dc50fab0c173a24608ef3584` resolves to `{bundle_id, txid, anchored_at}` without auth.
- **client-recomputable:** The deterministic master-salt hex used for this sample is `fd5c7c8a3eb4126b9d2a47e8a1cc9f0b76b231d7e8f0a1b2c3d4e5f6a7b8c9d0`; rebuilding via `merkle_row.py build-sealed --rows-jsonl <bids> --master-salt-hex fd5c7c…c9d0` reproduces the same root and on-chain sha.
- **what to verify locally:** `merkle_row.py verify-sealed --reveal sealed-reveal-row-2.json --commit-doc sealed-commit.json` returns `{"verified": true, "details": {root_match, row_binding, leaf_commitment, merkle_path}}`.

## A note on the .mbnt bundle

The full `.mbnt` bundle file is workspace-private (browser-session-gated
download) and not hosted publicly here. Auditors verifying a row reveal
do not need the `.mbnt` for `merkle-row-sealed-v1` — the reveal payload
is self-contained (row + salt + proof + root). For `merkle-row-v1`,
re-running `build-standard` against the same rows reproduces the leaf
hashes that the server's `proofs.json` would carry; an offline
verifier can stitch row → leaf → root → on-chain commitment without
fetching the bundle.