# FORAY — Custody-Disciplined Demonstration Anchors — Ops Log — v0.2

**Supersedes:** `foray-custody-material-ops-log-v0_1.md` (preserved, not deleted). **Reason:** the RETROACTIVE section's custody-recovery status for both 2026-07-14 anchors moves from IN PROGRESS to a truthful terminal/interim state, per the 2026-07-24 pre-image custody recovery session (`foray-api/custody-recovery/RECOVERY-FINDINGS.md`). All other entries carried forward unchanged from v0.1.

Companion ops log to `docs/proofs-material/`, in the style of `foray-api/docs/ops/anchoring-wallet-log-v0_1.md`. Covers the session that produced Record A and Record B (custody-disciplined demonstration anchors), the auth-probe incident that preceded them, the F1 re-issue anchors, and the retroactive entries for the 2026-07-14 production anchors whose custody material was found missing.

**No key material — private key, seed phrase, or any derivative of either — is ever recorded here, under any circumstance.** Salts are recorded by design (public demonstration artifacts, per task instruction) — salts are proof material, not key material. The one exception, noted where it occurs below: a recovered salt that belongs to a *different, never-broadcast* signing of the same body is named for completeness and explicitly flagged as unusable for verification — it is not treated as if it were a demonstration-anchor salt.

---

## 2026-07-23 — INCIDENT: auth-probe request inadvertently enqueued and broadcast a real anchor

**What happened:** ahead of Task 2 (real mainnet anchoring for Records A and B), a pre-flight step attempted to confirm a newly rotated `ANCHOR_CONSUMER_TOKEN` was live by sending an authenticated `POST /api/anchor` request with an empty JSON body (`{}`), on the assumption the endpoint had a validation-only or dry-run mode for a probe like this. **It does not.** `handleAnchorPost` has no such mode — any authenticated request with a non-empty body is hashed, signed, and enqueued as a real anchor job against the production wallet, unconditionally on content. The probe was accepted, and the two-byte body `{}` was treated as a genuine record to anchor.

**Root cause:** an incorrect assumption in the pre-flight instruction (this is an advisory-session error in how the probe was specified, not a code defect and not a CC-execution error) — that a "validation-level response" existed as a possible non-mutating outcome for this endpoint. It does not; the only non-mutating outcomes are `404` (`ANCHOR_MODE` off) and `401` (auth failure). Any `200` is a real, production-signing side effect.

**Captured response (complete custody material for the incidental artifact):**

```json
{
  "status": "enqueued",
  "jobId": "8fcbb730-15ad-4472-8cd3-fa07a0e1c233",
  "txHash": "44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
  "leafSalt": "4b63b0c9473e2e1c03b6781cdca24818c27fcffdd20596f1dcc386953378669b",
  "expectedAnchoredValue": "1ff18bda8067e873a951cb00ee034e3603fcfc72d61fbc61adb7008c89b166b2",
  "address": "kaspa:qr2kfwx69r8t5tmwrcny2wte07wx5ywnewa4l2c0wu4zjwlpgejax8rsacjwn",
  "fee": "168800",
  "spentUtxo": {
    "transactionId": "d6d704ed865e6aaa69e37e77e88077abff6279af4c2c19043157dd6f22838a5b",
    "index": 0
  },
  "extension": {"ext_version": 0, "ext_digest": null}
}
```

`txHash` is `44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a` — the well-known SHA-256 of the two-byte string `{}`. Nothing sensitive was anchored; the body committed to is a meaningless empty object.

**Disposition (Operator-directed, 2026-07-23):** rather than attempt to cancel or ignore the queued job — which per defect D1 (no UTXO reservation) would leave the wallet's UTXO state ambiguous for whatever came next — the Operator directed that the probe job be broadcast to completion first, verified, and logged honestly as an incidental artifact of this session, before any of Record A or Record B's real anchoring began. This preserves the serial-execution discipline (never two unbroadcast jobs) by resolving the accidental job to a clean terminal state before starting the intended work.

**Resolution — confirmed on Kaspa mainnet:**

| Field | Value |
|---|---|
| Kaspa tx id | `0f86f45b59ced7d9e049c5542d161b2d372028fc3515b9f5cf78f1d928b9ab42` ([explorer](https://explorer.kaspa.org/txs/0f86f45b59ced7d9e049c5542d161b2d372028fc3515b9f5cf78f1d928b9ab42)) |
| Broadcast (`block_time`) | 2026-07-23T22:50:19.294Z |
| Confirmed (`accepting_block_time`) | 2026-07-23T22:50:19.705Z |
| On-chain `payload` | `1ff18bda8067e873a951cb00ee034e3603fcfc72d61fbc61adb7008c89b166b2` |
| Verification | **PASS** — on-chain payload byte-identical to `expectedAnchoredValue` |

**Process correction going forward:** confirming an `ANCHOR_CONSUMER_TOKEN` is live must use a request this endpoint actually rejects non-destructively — e.g. an intentionally malformed/oversized body expected to 4xx before signing, or (preferably) a dedicated read-only auth check if one is ever added. An empty-object body is not such a request.

---

## 2026-07-23 — Record A anchored: accounts-payable settlement (finance demonstration record)

**Purpose:** custody-disciplined demonstration anchor, three-panel exhibit `docs/proofs-material/foray-custody-exhibit-record-a-v0_1.md`. Full custody sheet: `docs/proofs-material/foray-custody-sheet-record-a-v0_1.md`.

**Body hash:** `ec89688430e34143c316019e679513b896280315b821a3171ca3b4848dbf658a` (`docs/proofs-material/record-a-body.json`). Live-validated (`{"valid": true, "errors": [], "warnings": []}`) before submission.

| Field | Value |
|---|---|
| Kaspa tx id | `f997e394660a81ae1709ec644d436606512e04fb390f53c7127b9e225164aaf1` ([explorer](https://explorer.kaspa.org/txs/f997e394660a81ae1709ec644d436606512e04fb390f53c7127b9e225164aaf1)) |
| Spent UTXO | `0f86f45b59ced7d9e049c5542d161b2d372028fc3515b9f5cf78f1d928b9ab42:0` (the incident-probe tx, above) |
| Broadcast (`block_time`) | 2026-07-23T22:51:00.608Z |
| Confirmed (`accepting_block_time`) | 2026-07-23T22:51:01.154Z |
| On-chain `payload` | `8a11800a538021c48ef92aeb3eafa9fcfa1f5722b8b73a411fff0a2b1c77695c` |
| Verification | **PASS** — on-chain payload == `expectedAnchoredValue` == independently recomputed commitment (leaf/ABH recomputation from `txHash` + `leafSalt` + lane `direct`, `windowId` recovered by brute force) |

**Serial discipline:** this job's `POST /api/anchor` request followed the incident probe's full confirmation; broadcast and confirmed before Record B's request was made.

**Superseded 2026-07-24 as demonstration material — see the entry below.** This anchor's `transaction_id` (F1) was a manufactured descriptive value (`AP_2026_Q3_INVOICE_08341`), not the originating system's real key. Per Operator ruling 2026-07-23, F1 must carry the client key verbatim until the F-wire migration gives F2 its own dedicated field. **This anchor itself remains a valid, verified, custody-complete anchor** — nothing about its on-chain state, its verification result, or its custody material is retracted. It is superseded only as the record this project points to for the "F1 is the linkage" demonstration.

---

## 2026-07-23 — Record B anchored: agent action under a grant (governance demonstration record)

**Purpose:** custody-disciplined demonstration anchor, three-panel exhibit `docs/proofs-material/foray-custody-exhibit-record-b-v0_1.md`. Full custody sheet: `docs/proofs-material/foray-custody-sheet-record-b-v0_1.md`.

**Body hash:** `498c9553341df8bc6b28a09147198bd830bd470a1b2b0165f1cb85d7986e5a6f` (`docs/proofs-material/record-b-body.json`). Live-validated (`{"valid": true, "errors": [], "warnings": []}`) before submission — re-validated after the Gate-1 de-personalization correction (grantor name changed to a fictitious party).

| Field | Value |
|---|---|
| Kaspa tx id | `ebb75c73a42ad0f630d2fdf07312d36d99fd0ea7c5e77bbf2c13e21594fdfe45` ([explorer](https://explorer.kaspa.org/txs/ebb75c73a42ad0f630d2fdf07312d36d99fd0ea7c5e77bbf2c13e21594fdfe45)) |
| Spent UTXO | `f997e394660a81ae1709ec644d436606512e04fb390f53c7127b9e225164aaf1:0` (Record A's own confirmed tx) |
| Broadcast (`block_time`) | 2026-07-23T22:52:45.795Z |
| Confirmed (`accepting_block_time`) | 2026-07-23T22:52:46.387Z |
| On-chain `payload` | `a9d6e455aa1d826d093e39e4ced9cb496b9eaf96b14e0e9f00d55f6a3b034777` |
| Verification | **PASS** — on-chain payload == `expectedAnchoredValue` == independently recomputed commitment |

**Serial discipline:** this job's `POST /api/anchor` request followed Record A's full confirmation; its `spentUtxo` chains directly from Record A's own confirmed tx, corroborating that no second unbroadcast job ever existed.

**Anchor chain this session, in full:** probe (`0f86f45b…`) → Record A (`f997e394…`) → Record B (`ebb75c73…`), each spending the prior confirmed transaction's UTXO — a live, on-chain demonstration of the serial discipline defect D1 requires in the absence of UTXO reservation.

**Superseded 2026-07-24 as demonstration material — see the entry below.** Same basis as Record A's supersession note above: `transaction_id` (F1) was a manufactured value (`GOV_2026_Q3_AGENTACTION_0091`), not the originating `LogEntryID`. **This anchor itself remains a valid, verified, custody-complete anchor.**

---

## 2026-07-24 — Record A re-issued and anchored: accounts-payable settlement, originating key as F1

**Purpose:** re-issue of the finance demonstration record per Operator ruling 2026-07-23 — F1 (`transaction_id`) now carries the originating system's real key (`TranID`) verbatim, not a manufactured descriptive id. Exhibit `docs/proofs-material/foray-custody-exhibit-record-a-v0_2.md`. Full custody sheet: `docs/proofs-material/foray-custody-sheet-record-a-v0_2.md`.

**Body hash:** `5b106984710c31538beadea650d4f3091b2629e59a34189751bdcda15b316630` (`docs/proofs-material/record-a-body-v2.json`, `transaction_id: "AP-2026-08341"`). Live-validated (`{"valid": true, "errors": [], "warnings": []}`) before submission — the schema imposed no format constraint requiring mutation of the client key.

| Field | Value |
|---|---|
| Kaspa tx id | `1bd7bfc63ee77ea877ee30f0033a4b3e1a7a335422deaeed29c08af98a34eb45` ([explorer](https://explorer.kaspa.org/txs/1bd7bfc63ee77ea877ee30f0033a4b3e1a7a335422deaeed29c08af98a34eb45)) |
| Spent UTXO | `ebb75c73a42ad0f630d2fdf07312d36d99fd0ea7c5e77bbf2c13e21594fdfe45:0` (v0.1 Record B's own confirmed tx — the last confirmed anchor in the wallet's history at submission time) |
| Broadcast (`block_time`) | 2026-07-24T00:19:37.368Z |
| Confirmed (`accepting_block_time`) | 2026-07-24T00:19:37.728Z |
| On-chain `payload` | `d06b29f7c36bdbb01e6ea11588070675eb4efa28d9e1d32ac4c922efb41d6a0e` |
| Verification | **PASS** — on-chain payload == `expectedAnchoredValue` == independently recomputed commitment (leaf/ABH recomputation from `txHash` + `leafSalt` + lane `direct`, `windowId` recovered by brute force) |

**Serial discipline:** `anchor-submissions.json` confirmed as the last entry before this job that the wallet's most recent confirmed anchor was v0.1 Record B (`ebb75c73a42a…`); this job's `spentUtxo` chains directly from it. Broadcast and confirmed before Record B v0.2's request was made.

---

## 2026-07-24 — Record B re-issued and anchored: agent action under a grant, originating key as F1

**Purpose:** re-issue of the governance demonstration record per Operator ruling 2026-07-23 — F1 (`transaction_id`) now carries the originating system's real key (`LogEntryID`) verbatim. Exhibit `docs/proofs-material/foray-custody-exhibit-record-b-v0_2.md`. Full custody sheet: `docs/proofs-material/foray-custody-sheet-record-b-v0_2.md`.

**Body hash:** `99c283898b7e3938209891149302e036b4de280aa89597e43d2acc46ad433b78` (`docs/proofs-material/record-b-body-v2.json`, `transaction_id: "GOV-2026-0091-LOG"`). Live-validated (`{"valid": true, "errors": [], "warnings": []}`) before submission.

| Field | Value |
|---|---|
| Kaspa tx id | `375f4468e358a27bf64d0cd61356400aedb16be722a1f389855b26590157edd5` ([explorer](https://explorer.kaspa.org/txs/375f4468e358a27bf64d0cd61356400aedb16be722a1f389855b26590157edd5)) |
| Spent UTXO | `1bd7bfc63ee77ea877ee30f0033a4b3e1a7a335422deaeed29c08af98a34eb45:0` (Record A v0.2's own confirmed tx) |
| Broadcast (`block_time`) | 2026-07-24T00:20:24.127Z |
| Confirmed (`accepting_block_time`) | 2026-07-24T00:20:25.139Z |
| On-chain `payload` | `e2930eeeb7ad8c712ac3a606916ed0764f749d1284775b7b7f55993091f57e4f` |
| Verification | **PASS** — on-chain payload == `expectedAnchoredValue` == independently recomputed commitment |

**Serial discipline:** this job's `POST /api/anchor` request followed Record A v0.2's full confirmation; its `spentUtxo` chains directly from Record A v0.2's own confirmed tx.

**Anchor chain across both sessions, in full:** probe (`0f86f45b…`) → v0.1 Record A (`f997e394…`) → v0.1 Record B (`ebb75c73…`) → v0.2 Record A (`1bd7bfc6…`) → v0.2 Record B (`375f4468…`) — five transactions, each spending the immediately prior confirmed transaction's UTXO, an unbroken live demonstration of the D1 serial discipline across two separate work sessions.

---

## 2026-07-24 — Pre-image custody recovery attempt for the 2026-07-14 anchors

**Purpose:** time-sensitive recovery effort (`ANCHOR_BODY_STORE` KV TTL for any stored body closes 2026-08-13) to locate the body and `leafSalt` for both 2026-07-14 anchors, ahead of that clock. Read-mostly session; no production writes made. Full findings: `foray-api/custody-recovery/RECOVERY-FINDINGS.md` (gitignored — recovered material stays out of any repository pending an Operator ruling on the F-2 custody model's permanent-storage question).

**Task 1 — KV store.** `wrangler kv key list` against `ANCHOR_BODY_STORE` (namespace `foray-anchor-bodies`, id `8ebe8024045b483aa31f17ce3a5f1fc6`, read from the `wrangler.toml` binding) returned **zero keys** — the namespace is entirely empty. Consistent with, not contradicting, `docs/design/foray-body-availability-design-v0_2.md`'s own INV-1 finding (dated 2026-07-14): the KV-backed ingestion path did not exist yet on the date either anchor was created.

**Task 2 — session residue.** Searched shell histories, all Claude Code session transcripts (global and project-local, including subagent transcripts), `/tmp`, `~/Desktop`, `~/Downloads` (dated files and the two docs a prior session's own search had already named). Located the exact original requests for both anchors in session transcript `a135dcc8-1bcd-4a45-884e-0817002e6318` (2026-07-14).

**f23d499a — recovery is structurally impossible, not merely unsuccessful.** The anchor was created via `POST /api/wp2-anchor-test` with body `{"label":"FORAY production go-live anchor"}` — confirmed by matching `jobId` (`4933d9dd…`) and `expectedAnchoredValue` (`c9659241…`) exactly against `anchor-submissions.json`. This endpoint's response has **no `txHash` field and no `leafSalt` field** (confirmed by reading the full, unabridged transcript content). It derives its commitment from the label string server-side and discards the salt within the request, per the endpoint's documented design. There was never a body, and the salt was never returned or persisted for this anchor — this is not evidence lost, it is evidence that was never created.

**d6d704ed — body recovered and hash-verified; `leafSalt` not recovered.** The original signing request (`jobId ea0171ce-52dc-447c-93e7-105cf830fb36`, matching `anchor-submissions.json` exactly) is captured in the same transcript, including the literal `--data-raw` body sent to `POST /api/anchor`: `FORAY body-availability design v0.2 endpoint verification, direct mode`. Saved to `foray-api/custody-recovery/d6d704ed-body.txt` and independently re-hashed via stdin:

```
$ sha256sum < d6d704ed-body.txt
85133280aca92bd53c049d469425247f237e3623a24285bca38569bc43e22d50
```

**Exact match to the recorded `txHash`.** The `leafSalt` itself was not recovered: the transcript's own read-back script printed only a boolean (`'leafSalt' in r and len(r['leafSalt']) == 64` → `True`), never the value, and the source file (`/tmp/reanchor-response.json`) no longer exists on disk. A *different* job's salt for the same body text (`f6236a69-22d3-41d3-8ceb-ece871ef5d0a`, a race-condition casualty that never broadcast — see `foray-api/docs/ops/foray-api-known-issues-v0_1.md` D1/D2) was found in full, including its actual `leafSalt` value, but its `expectedAnchoredValue` does not match `d6d704ed`'s on-chain payload — a fresh salt is drawn per signing, so this value is explicitly **not** usable to verify `d6d704ed` and is recorded in the findings only as a flagged near-miss, never treated as if it were the real salt.

**Task 3 — verification.**

- **f23d499a: 0 of 2 material recovered.** No PASS/FAIL is possible or meaningful — there is nothing to recompute from. What remains verifiable, unchanged from the 2026-07-23 report: the on-chain payload matches the broadcaster's own record.
- **d6d704ed: 1 of 2 (body only).** The recovered body proves the body existed and its SHA-256 equals the anchor's own recorded `txHash` — confirmed. It cannot reproduce the on-chain commitment (`8f579ab0…`), which additionally requires the (unrecovered) `leafSalt` and the (unrecovered) `windowId` per `buildDirectAnchorCommitment`. No PASS/FAIL is reportable; this is the honest terminal state of a body-without-salt recovery, named exactly, not rounded up or down.

**Process note:** this recovery effort — like the custody-disciplined demonstration anchors above — exists to show the gap concretely rather than leave it abstract. It closes the "in progress" status honestly: one anchor's material is now precisely characterized as unrecoverable by construction; the other's is precisely half-recovered, with the recovered half hash-verified and the missing half named exactly.

---

## RETROACTIVE — 2026-07-14 production anchors: custody status as of 2026-07-24

These entries record what a prior custody-verification session (2026-07-23, pre-image custody verification report) found for FORAY's first two published-on-site mainnet anchors, and — as of this version — the outcome of the 2026-07-24 recovery attempt above. Filed here retroactively because no entry for either anchor exists in `foray-api/docs/ops/anchoring-wallet-log-v0_1.md`, which stops at 2026-07-13.

### 2026-07-14 — First production anchor (`f23d499a…`)

**Kaspa tx id:** `f23d499a3fadda70aebe0038d9f5351706015825cfccf37bb42abeefa280a664` ([explorer](https://explorer.kaspa.org/txs/f23d499a3fadda70aebe0038d9f5351706015825cfccf37bb42abeefa280a664)). Published on `foray.dunin7.com` as "First production anchor — 2026-07-14."

**What is known:** the on-chain `payload` (`c9659241b170995340b95e17d7f26219cabcb21a6f9af800c399d971a2633f0e`) matches `foray-api/broadcaster/anchor-submissions.json`'s recorded `expectedAnchoredValue` for job `9ffdebeb-a7f7-4ff8-9f96-4a27a8783091` exactly — the broadcaster's own record is confirmed accurate against the chain. **New as of 2026-07-24:** the exact originating request is now identified — `POST /api/wp2-anchor-test` with `{"label":"FORAY production go-live anchor"}` (session transcript `a135dcc8…`, job `4933d9dd…`, matching `anchor-submissions.json` exactly) — and its full, unabridged response contains no `txHash` and no `leafSalt` field at all.

**What is missing, and why it is unrecoverable:** the pre-image body and its `leafSalt` were never created for this anchor — the endpoint used derives its commitment from a label string server-side and discards the salt within the request, by design. This is a structural fact about how the anchor was made, not a search gap. Per `docs/design/foray-body-availability-design-v0_2.md` §3.4, FORAY's design never retains the salt server-side past the request; here, no salt or body existed past the request to begin with.

**Custody recovery status: NOT RECOVERABLE — closed, terminal.** Exhaustively searched (KV store, shell histories, all Claude Code session transcripts including subagents, `/tmp`, `~/Desktop`, `~/Downloads`) and the root cause of unrecoverability is now identified with certainty, not merely presumed. `ANCHOR_BODY_STORE`'s TTL is not applicable to this anchor — no body was ever stored there for it to expire. This entry is now a closed, terminal record, not an open item.

### 2026-07-14 — Body-availability end-to-end proof (`d6d704ed…`)

**Kaspa tx id:** `d6d704ed865e6aaa69e37e77e88077abff6279af4c2c19043157dd6f22838a5b` ([explorer](https://explorer.kaspa.org/txs/d6d704ed865e6aaa69e37e77e88077abff6279af4c2c19043157dd6f22838a5b)). Published on `foray.dunin7.com` as "Body-availability end-to-end proof — 2026-07-14," with the site's own claim: "the record body was stored under its own hash and retrieved by that hash; re-hashing the retrieved body reproduced the address exactly."

**What is known:** the on-chain `payload` (`8f579ab0946cfb75bb8f24c5f57af0a9d1e4ec90a7a56a27e4d76794d4db9775`) matches `anchor-submissions.json`'s recorded `expectedAnchoredValue` for job `ea0171ce-52dc-447c-93e7-105cf830fb36` exactly. **New as of 2026-07-24:** the pre-image body itself is recovered from session transcript `a135dcc8…` (the literal `--data-raw` string sent to `POST /api/anchor`) and independently re-hashed — `sha256sum` of the saved file equals the anchor's recorded `txHash` (`85133280…`) exactly, confirming this is genuinely the body that was hashed for this anchor.

**What is still missing:** the `leafSalt` itself. The transcript's own read-back script printed only a boolean confirming the field's presence, never its value, and the underlying `/tmp` file no longer exists. A different job's salt for the same body text exists in residue but belongs to a different (never-broadcast) commitment and is not usable here — see the recovery-session entry above for the full accounting.

**Custody recovery status: PARTIALLY RECOVERED — body recovered and hash-verified; salt not recovered; not upgradeable to full verification.** This is now a precise, bounded gap rather than an open-ended one: exactly one component (the salt) is missing, its absence is fully accounted for, and no further search is expected to change this — the responsible transcript and file have been read in full. The site's specific claim (a retrieval round-trip was demonstrated on 2026-07-14) remains itself unverifiable going forward, since the retrieval side of that claim was never captured either — but the body's authenticity as the pre-image for this anchor's `txHash` is now established with certainty.

**Process note, both retroactive entries:** the custody-disciplined demonstration anchors above (2026-07-23 and 2026-07-24 entries) remain the corrective demonstration — proof that when the discipline is followed from the start, the resulting anchor is fully self-verifying with no gap. These two 2026-07-14 anchors predate that discipline; this version closes out what can and cannot be recovered after the fact, rather than leaving both marked "in progress" indefinitely.

---

DUNIN7 — Done In Seven LLC
FORAY — Custody Material Ops Log — v0_2 — 2026-07-24