chore(consistency): full cross-paper re-audit + fix SBT version drift + stale README outlines (#169)

Author: proofmancer

papers/CONSISTENCY_REVIEW.md

@@ -37,7 +37,7 @@ This note adopts the v0.7-PoUA discipline from draft v0.1:
 
 ## Dependencies
 
-- **[PoUA paper](../poua/) at v0.8+**. The attestor-set primitive and threshold-signature mechanics are PoUA's, used here without re-derivation.
+- **[PoUA paper](../poua/) at v0.9.2+**. The attestor-set primitive and threshold-signature mechanics are PoUA's, used here without re-derivation.
 - **[Per-Schema Fees](../per-schema-fees/) at v0.2+**. §3.3 of this note depends on the per-schema fee market being substantive in the supporting paper. v0.1 of this note flags the fee-market composition as an open question; v0.2 closes it.
 - **[Cross-Schema Composition](../cross-schema-composition/) at v0.2+**. §4.5 (sublicensing via meta-schemas) depends on the typed-reference primitive in the composition paper.
 - **[ligate-chain#286](https://github.com/ligate-io/ligate-chain/issues/286)**. The engineering design.

papers/schema-bound-tokens/README.md

@@ -45,7 +45,7 @@ A chain whose runtime already runs attestor sets as first-class state objects ca
 
 ### 1.3 Position relative to PoUA
 
-[PoUA v0.8](../poua/) establishes attestor sets as the primary trust primitive for application-layer correctness, with non-transferable reputation tied to the validators who include valid attestations. Schema-bound tokens reuse the same attestor-set object and inherit the same reputation feedback loop: if an attestor set authorizes a fraudulent mint, the validators who include that attestation are subject to the same reputation mechanics that govern any §A.3 grinding behavior. The reputation layer is not retrofitted to handle tokens; tokens are simply another application of the layered defense PoUA already specifies.
+[PoUA v0.9.2](../poua/) establishes attestor sets as the primary trust primitive for application-layer correctness, with non-transferable reputation tied to the validators who include valid attestations. Schema-bound tokens reuse the same attestor-set object and inherit the same reputation feedback loop: if an attestor set authorizes a fraudulent mint, the validators who include that attestation are subject to the same reputation mechanics that govern any §A.3 grinding behavior. The reputation layer is not retrofitted to handle tokens; tokens are simply another application of the layered defense PoUA already specifies.
 
 ---
 
@@ -97,15 +97,15 @@ This is the priority section: what's actually provable about the primitive once
 
 **Claim.** For any token type $\mathcal{T}$ schema-bound to $\mathcal{A}$, the full set of mint events that contributed to any holder's balance is queryable as a finite set of attestations under $\sigma_{\text{mint}}$ filtered by their `token_id` field matching `token_id(T)`.
 
-**Argument.** Every mint is recorded as an attestation per §2.2. Attestations are stored in the chain's attestation log (per [PoUA v0.8](../poua/) §3.7 system diagram). The token's runtime state (current balances) is derivable from the cumulative sum of mint events minus burn events; both classes are attestations. There is no off-attestation-log state mutation for schema-bound tokens. $\square$
+**Argument.** Every mint is recorded as an attestation per §2.2. Attestations are stored in the chain's attestation log (per [PoUA v0.9.2](../poua/) §3.7 system diagram). The token's runtime state (current balances) is derivable from the cumulative sum of mint events minus burn events; both classes are attestations. There is no off-attestation-log state mutation for schema-bound tokens. $\square$
 
 **Consequence.** Audit infrastructure that already indexes attestations (chain explorers, partner indexers, downstream analytics) gets token-issuance audit for free. No separate issuance ledger needs to be tracked. Investigators reconstructing "who minted what when" use the same queries as investigators reconstructing "who attested what when."
 
 ### 3.3 Composition with the per-schema fee market
 
 **Claim.** A mint event under $\sigma_{\text{mint}}$ pays exactly the per-attestation fee for $\sigma_{\text{mint}}$, plus the standard chain gas for the transaction carrying it. The mint does not pay an additional, separate "token-mint fee" on top of the attestation fee.
 
-**Argument and open question.** The attestation module's per-schema fee market (per the [Per-Schema Fees](../per-schema-fees/) paper, v0.1.1) prices attestations by schema. $\sigma_{\text{mint}}$ is a system schema; its fee is set by governance and not subject to the open-fee-market dynamics that apply to application schemas. The bound mint fee should be calibrated so that:
+**Argument and open question.** The attestation module's per-schema fee market (per the [Per-Schema Fees](../per-schema-fees/) paper, v0.2) prices attestations by schema. $\sigma_{\text{mint}}$ is a system schema; its fee is set by governance and not subject to the open-fee-market dynamics that apply to application schemas. The bound mint fee should be calibrated so that:
 
 - Routine mint volume does not exhaust block space (a fee floor)
 - Adversarial mint flooding (a quorum that controls $\mathcal{A}$ tries to spam mints to inflate $\mathcal{T}$'s supply) is economically deterred (a fee ceiling-equivalent)
@@ -116,15 +116,15 @@ This is the priority section: what's actually provable about the primitive once
 
 **Claim.** Holders of $\mathcal{T}$ retain valid balances when the attestor set $\mathcal{A}$ rotates members or threshold, provided the rotation is performed through the chain's attestor-set management module (not via off-chain key compromise + re-registration).
 
-**Argument.** Mint events are historical attestations. Their validity at the time of mint is determined by the threshold-signature verification under the keys recorded for $\mathcal{A}$ *at the slot of the mint attestation*. A rotation that changes $\mathcal{A}$'s key set at slot $t$ updates the verifier state for attestations at slot $t' > t$ but does not retroactively invalidate attestations at slot $t' \leq t$. The historical attestation log is append-only by construction (per [PoUA v0.8](../poua/) §3.7); rotation events are recorded as their own attestations under the attestor-set management schema. Token balances derived from pre-rotation mints remain in the chain's runtime state regardless of post-rotation key set. $\square$
+**Argument.** Mint events are historical attestations. Their validity at the time of mint is determined by the threshold-signature verification under the keys recorded for $\mathcal{A}$ *at the slot of the mint attestation*. A rotation that changes $\mathcal{A}$'s key set at slot $t$ updates the verifier state for attestations at slot $t' > t$ but does not retroactively invalidate attestations at slot $t' \leq t$. The historical attestation log is append-only by construction (per [PoUA v0.9.2](../poua/) §3.7); rotation events are recorded as their own attestations under the attestor-set management schema. Token balances derived from pre-rotation mints remain in the chain's runtime state regardless of post-rotation key set. $\square$
 
 **Edge case.** If $\mathcal{A}$ is *removed* entirely (governance action, end-of-life), the token type's `mint_authority` is permanently revoked; the runtime can no longer accept new mints (no valid signing quorum exists), but pre-removal balances remain valid. This is the intended end-of-life path for a sunset token, similar to a smart-contract owner renouncing admin in conventional patterns.
 
 ### 3.5 Reputation feedback loop
 
 **Claim.** Bad-faith mints by $\mathcal{A}$ are subject to the same reputation mechanics that govern any §A.3-grinding behavior under PoUA. There is no separate "token issuance reputation" track.
 
-**Argument.** Mint events are attestations under $\sigma_{\text{mint}}$, included by validators in blocks. Per [PoUA v0.8](../poua/) §4.3 the reputation update rewards validators who include valid attestations and exposes them to the standard slashing conditions if those attestations are invalid or detected as part of a grinding pattern (§A.2 / §A.3). If $\mathcal{A}$ issues a fraudulent mint (a mint exceeding a stated cap, or a mint contradicting an off-chain authoritative source), the chain has the same recourse it has for any fraudulent attestation: detect, slash the validator who included it, and trigger appeal via §5.5.5.
+**Argument.** Mint events are attestations under $\sigma_{\text{mint}}$, included by validators in blocks. Per [PoUA v0.9.2](../poua/) §4.3 the reputation update rewards validators who include valid attestations and exposes them to the standard slashing conditions if those attestations are invalid or detected as part of a grinding pattern (§A.2 / §A.3). If $\mathcal{A}$ issues a fraudulent mint (a mint exceeding a stated cap, or a mint contradicting an off-chain authoritative source), the chain has the same recourse it has for any fraudulent attestation: detect, slash the validator who included it, and trigger appeal via §5.5.5.
 
 **Limit of this argument.** The chain detects *invalid* attestations (failed threshold signature) and *graph-shaped misbehavior* (§A.3 bipartite-density). It does not detect *semantically incorrect* mints (the attestor set issues a mint that satisfies cryptographic validity but is contractually unauthorized). Semantic correctness is the schema designer's problem, the same way it is for any application-layer schema. The reputation feedback loop bounds the cost of provably-bad behavior, not the cost of debatable behavior.
 

papers/schema-bound-tokens/schema-bound-tokens.md

@@ -20,9 +20,9 @@ Two schemas covered here:
 
 Licensing is an **application-layer concern that belongs as a schema**, not a chain-layer token primitive. The receipt object stays minimal (claim, attestor, hash); the license is layered on as a separate attestation referencing the original receipt.
 
-## Planned outline
+## Section structure
 
-When v0.1 authoring opens, the paper will follow this section structure. Each is `[**v0.1:** intent annotation]` only at v0.0.
+The paper is substantive at v0.2 and follows this section structure:
 
 1. **Why licensing belongs as a schema, not as a chain-layer token primitive.** Keep the receipt object minimal: a Proof-of-Prompt receipt is a claim that "this prompt produced this output," not a license. License terms vary; the underlying claim does not. Layering license as a separate schema preserves the minimal-receipt invariant.
 2. **Schema design.** Fields, invariants, royalty terms, version-bumping rules. For prompt-licensing: prompt-id, creator-address, royalty-bps, license-type-enum, expiry. For content-licensing: artifact-hash, creator-address, royalty-bps, license-terms-uri, derivative-allowed-flag.

papers/schema-bound-tokens/schema-bound-tokens.pdf

@@ -15,9 +15,9 @@ Ligate Chain is the receipt layer for AI. Receipt creation alone is not enough:
 
 This paper lands the detection narrative honestly. Six paths catch usage at different points in the workflow. Combined, they cover the cooperative-and-discoverable majority. Adversarial cases (deliberate metadata stripping) are a tail risk addressed by watermarking, which is research-grade and pluggable rather than baked in.
 
-## Planned outline
+## Section structure
 
-When v0.1 authoring opens, the paper will follow this section structure. Each is `[**v0.1:** intent annotation]` only at v0.0.
+The paper is substantive at v0.2 and follows this section structure:
 
 1. **Problem statement.** Why receipt creation alone is insufficient. The cooperative-vs-adversarial spectrum: most usage is cooperative (the user wants attribution); a tail is adversarial (the user wants to strip provenance). Different defenses for different points on the spectrum.
 2. **The six-path detection model.**