DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path protocols/grantha/GRANTHA_FORAY_ANCHORING_DECISION-v0_2.md

GRANTHA — FORAY Anchoring Decision — v0.2

Version. v0.2 Date. 2026-07-12 Status. Decision sheet [OPERATOR-SHEET], uncommitted. Supersedes v0.1 (same session) and reconciles it with the parallel GRANTHA_FORAY_ANCHORING_SHEET-v0_1 of unknown provenance found in outputs (Project Log v0.2, Entry 2026-07-12-C). Stele's corrected record offers: FORAY anchors GRANTHA's grant-state-change stream as ordinary FORAY transactions — tamper-evident proof a grant changed at time T, never enforcement. Adoption is the Operator's call. v0.2 delta — one substantive reversal. v0.1 recommended a flat Action-only schema carrying a plaintext type field. That is withdrawn. The parallel sheet is correct that a public type field (issuance vs. raise-pending vs. revoked, visible on-chain) leaks under the hidden-topology threat model — a burst of visible raise-pendings is an incident broadcast, and event-type-plus-timing is org-map material GRANTHA exists to eliminate. v0.2 adopts the uniform blinded envelope: nothing on-chain distinguishes one event type from another. This is the more important of the two documents' schema positions and it wins. v0.1's flat-mapping reasoning is preserved as a prior position in §3 so the reversal is legible. Grounding. GRANTHA Discovery Record v0.12 (commit e53e413): emission-points discipline, Decision J3 (state-changes anchored; one-vs-two channel deliberately open), A5/A6, two-clocks, OVA pattern-leak findings (J1.7, by identifier — bodies not restated). AGENTIC_ID_TO_GRANTHA_CORRECTION-v0_1 (2026-07-12): FORAY is a stateless notary — protocol + witness + anchor. FORAY Protocol Specification v4.1.2 via the FORAY skill, read at source this session. KIP-21 substrate facts on record (lane = tx.subnetwork_id; depth-check maturity; ≤50 lanes/block, ≤1e9 gas/lane/block). The Stele offer is grounded on the Operator's relay this session.


1. The size of the decision

Be precise about what is actually being decided. GRANTHA's record already commits to FORAY as audit substrate, emission on grant state-changes only, anchored state-changes as the proof layer (J3), and FORAY as sole chain-facing component. Declining the offer would reopen J3, for which no replacement proof layer exists on the record. So the real content is not "anchor or not" — it is (a) ratifying the offer as a cross-project interface commitment under FORAY's now-fixed stateless-notary standing, and (b) the stream definition.

The correction fixes FORAY's standing: anchoring proves a grant changed at time T; it never enforces, never holds grant state. Enforcement freshness rides GRANTHA's own replication fabric (Grant-Check Contract v0.2 §6); anchoring is proof, on its own clock. The two clocks stay separate by design.

2. Decision sheet — adoption [OPERATOR-SHEET]

| | | |---|---| | Question | Does GRANTHA adopt FORAY anchoring of its grant-state-change stream as an interface commitment, under FORAY-as-stateless-notary? | | Options | (a) Adopt. Consistent with J3; gives Stele the change-at-T proof its contract wants; grant-state truth stays wholly GRANTHA's. (b) Decline — reopens J3, no candidate replacement on the record. (c) Adopt-with-reservation: adopt events-anchoring now, hold the state-root question (§5) open. | | Recommendation | (c) — (a) plus honesty about the one sub-question that genuinely lacks data. Adoption is near-forced by the record; recording it as an Operator decision matters because Stele builds against it. Caveat added in v0.2: threat finding U1 (compromised authorizer as silent oracle) gives the state-root channel independent security weight, so the reservation in (c) is no longer only a benchmark question — see §5. | | Decider | Operator. | | Status | OPEN. §3–§5 are contingent on adoption. |

3. Anchor-worthy events

Eight event types, superseding the five-point emission note (GRANTHA_FORAY_EMISSION_POINTS-v0_1, 2026-06-24). Lineage of the count: v0.1 note had five (issuance, administrative issuance, delegation, revocation, conditional expiry); I8 split revocation and added raise-pending (six); clamp mechanics added release and narrow-adjust (eight). The parallel sheet reached the same expansion from the other side, naming clear-pending as its seventh — that is this set's release, same event, different name.

  1. Issuance
  2. Administrative issuance
  3. Delegation
  4. Raise-pending — the oversight assertion: observer O, time T, condition C, grant G, evidence E
  5. Narrow-adjust — scope change while pending
  6. Release (= the parallel set's clear-pending) — pending → active. A pending that vanishes without an anchored release is an audit hole: the trail would show containment raised and never lifted, which both understates risk (silent un-clamp by a captured authority) and overstates it (grants that look clamped forever). Raise/release symmetry on the anchor is also what makes flap detection (threat review U12) auditable.
  7. Revoked — the confirm-kill, or pre-authorized catastrophic escalation
  8. Acted-on expiry

Checks never anchor. Denies never anchor (A6; firmness still an open Operator call, unchanged here).

3a. Schema — the reversal, stated plainly

v0.1 position (withdrawn): a flat Action-only FORAY transaction per event, carrying a plaintext type field and salted refs, with the argument that flat mapping avoids the readable grant-graph that FORAY's arrangement_refs[] chain would rebuild.

What was right in v0.1 and is kept: the rejection of the reference-chain mapping. Linking each state-change back to an issuance Arrangement via arrangement_refs[] rebuilds a readable grant lifecycle on the audit substrate; salting parties doesn't help because the linkage is the leak. That reasoning stands.

What was wrong in v0.1: it stopped one step short. A flat mapping with a visible type still leaks the event kind and, by timing, the event rhythm. Under assume-breach / hidden-topology that is itself org-map material. The parallel sheet caught this.

v0.2 position (adopted): the uniform blinded envelope.


{
  "transaction_id": "GRANTHA_<stream_seq>",
  "schema_version": "4.1",
  "entity": "hash_<salted GRANTHA instance/lane ref>",
  "transaction_type": "grant_state_change",
  "actions": [{
    "id": "ACT_<stream_seq>",
    "foray_core": {
      "anticipation_refs": [],
      "type": "grant_state_change",     // uniform — never the specific event kind
      "settlement_status": "completed",
      "terms": {
        "commitment": "H(event_body)",  // fixed-size; hides kind, grant, actor, evidence
        "stream_seq": "<monotonic counter>"
      }
    }
  }],
  "foray_metadata": { "protocol_version": "4.1.2", "kaspa_commitment": { } }
}

4. Cadence

The two-clocks problem is the whole of the cadence question: emission is instant-local; anchoring is bundle-windowed; the gap is security-relevant for containment events.

5. Events-only vs. events-plus-state-root — reweighted

v0.1 and the parallel sheet both left this open on benchmarks. v0.2 reweights it: threat review U1 (a compromised authorizer answers checks with forged scope, and single-channel event-anchoring leaves no trace because a fabricated answer corresponds to no state-change) makes the anchored state root a security control, not only an assurance-vs-cost tradeoff. The state root is what lets a consumer verify an answer against something the authorizer cannot forge alone.

So the channel decision has two inputs now, and they may not agree: benchmarks (proving cost, proof-tx cadence — need a build phase) and U1 (which argues for the root regardless of cost). Events-only machinery is a subset of the state-root design, so adopting under §2 option (c) forecloses nothing — but the reservation should be resolved on U1's security weight, not parked on benchmarks alone. [OPERATOR-SHEET — channel decision, now security-load-bearing; [DEFERRED] proving-cost inputs to build phase.]

6. Open items

| # | Item | Marker | Decider / blocker | |---|---|---|---| | 1 | Adoption as interface commitment | [OPERATOR-SHEET §2] | Operator | | 2 | Blinded envelope ratification (reverses v0.1) | [OPERATOR-SHEET §3a] | Operator | | 3 | Commitment-opening proof mechanics | [DEFERRED] | §4.1 fork | | 4 | Cadence constants | [DEFERRED] | seqcommit-accessor.md pull | | 5 | Events-only vs. state-root | [OPERATOR-SHEET §5] | Operator; U1 security weight + build-phase benchmarks | | 6 | Off-chain body availability | named dependency | FORAY-side, unsolved |


DUNIN7 · GRANTHA · anchoring seam · consumes FORAY GRANTHA — FORAY Anchoring Decision — v0.2 — 2026-07-12