# §7.7 Promotion Tracking: v0.1.0-draft → v0.1.0-normative

**Date**: 2026-05-16
**Author**: autonomous web4 session (legion, Sprint 54 C3)
**Subject**: `web4-standard/core-spec/mcp-protocol.md` §7.7 Exchange Rate Negotiation
**Current status**: WIP v0.1.0-draft (2026-05-14)

---

## 1. Current State Summary

§7.7 specifies the **referent-grounded exchange rate negotiation** protocol —
how two sovereign societies arrive at mutually agreed settlement terms for
cross-society R7 actions that carry non-zero ATP cost.

**Settled (architecture)**:
- Rates are referent-grounded, not abstract bilateral (`§7.7.1`)
- Per-transaction scoping is the default; standing agreements are fallback (`§7.7.2`)
- The Treasurer role holds rate authority (`§7.7.2`, per `society-roles.md` §2.4)
- Form-vs-substance split: spec dictates message format and flow; strategy is sovereign (`§7.7.4`)
- Oracle is third-party input, not authority (`§7.7.6`)

**Normative-draft (wire format may evolve)**:
- Message schemas: `rate_proposal`, `rate_counter`, `rate_accept`, `rate_reject` (`§7.7.3`)
- Negotiation flow steps 1–6 (`§7.7.2`)
- Error code table: 7 failure modes (`§7.7.7`)

**Informative (guidance only)**:
- Per-transaction vs. standing trade-offs (`§7.7.5`)
- Oracle reference guidance (`§7.7.6`)

Per-subsection conformance markers were introduced by PR #200 (pending review)
classifying each subsection's normative force.

---

## 2. Hard Prerequisites

These must be resolved **before** promotion can be considered:

| # | Prerequisite | Status | Dependency |
|---|---|---|---|
| P1 | **PR #200 merges** — fixes §7.4↔§7.7 structural contradictions (F2/F3/F4/F12). Without this, §7.4's normative envelope cannot express §7.7 negotiation outcomes. | Pending review | Blocks all promotion |
| P2 | **F11 resolved** — settlement-amount signing authority (Treasurer vs PolicyEntity). §7.4 `atp_settlement` has no stated signer; §7.7.3 acceptance is Treasurer-signed; §7.3 reputation is PolicyEntity-signed. The role-separation seam must have an unambiguous answer. | Open (audit finding) | May depend on PR #200 landing first |
| P3 | **F8 verified** — §7.4↔§4.1 header-field reconciliation (`sender_society` vs `society`, `agency_chain` vs `proof_of_agency`). Operator commit `2e1e8b11` reportedly resolved this; needs verification that the resolution is consistent with §7.7's Treasurer-addressed messages. | Likely resolved | Verify post-merge |

---

## 3. Open Design Questions

These require operator (or multi-party) decisions before the wire format can stabilize:

| # | Question | Options | Impact on §7.7.3 schema |
|---|---|---|---|
| Q1 | **Counter-offer depth limits** — can counter-offers be countered indefinitely, or is there a protocol-level round limit? | (a) Unlimited, timeout-governed; (b) Max N rounds (society-configurable); (c) Max 1 counter before accept/reject | Affects whether `responds_to` can reference a counter (chain) or only the original proposal |
| Q2 | **Oracle authority model** — when both societies reference the same Oracle, is the Oracle's response binding or advisory? | (a) Always advisory (current §7.7.6 text); (b) Binding if both societies opt in; (c) Binding for the referent-price, advisory for the rate | Affects whether `reference_standard` in the proposal is a trusted attestation or informative citation |
| Q3 | **Standing-agreement termination semantics** — §7.7.5 says "24h default" for unilateral termination notice. Is this protocol-invariant, society-configurable, or agreement-specific? | (a) Protocol-invariant minimum; (b) Each agreement carries its own termination clause; (c) Society governance law sets it | Affects whether `validity_window` needs a `termination_notice_hours` field |
| Q4 | **Rate-rejection accountability** — does rejecting all proposals without counter-offer incur any protocol-level consequence, or is stonewalling a valid strategy? | (a) No consequence (sovereignty includes refusal); (b) Repeated rejection degrades T3 temperament for the Treasurer role; (c) Timeout triggers automatic fallback to standing/oracle | Affects whether the error-code table needs a `repeated_rejection` failure mode |
| Q5 | **Multi-referent proposals** — can a single proposal bundle multiple referents (e.g., "GPU-time + egress") or must each referent be a separate negotiation? | (a) One referent per proposal (current schema implies this); (b) Array of referents with independent rates; (c) Composite referent with defined decomposition | Affects `referent` field cardinality in §7.7.3 |

---

## 4. Implementation Evidence Required

Before a spec section moves from draft to normative, there must be evidence
that the specified wire format is implementable and interoperable:

- [ ] **At least two independent implementations** exercising the full
  negotiation flow (connect → begin_action → rate_propose → rate_accept/counter → settlement)
- [ ] **Cross-implementation interop test** — one implementation's Treasurer
  successfully negotiates with a different implementation's Treasurer
- [ ] **Error-path coverage** — at least one test per §7.7.7 failure mode,
  demonstrating correct error-code emission and recovery
- [ ] **Standing-agreement round-trip** — create, reference in transaction,
  expire, renegotiate
- [ ] **Oracle-referenced negotiation** — end-to-end with a mock Oracle society

Current implementation landscape:
- **Python SDK** (`web4/`): Has ATP/R6/R7 types but no rate-negotiation types yet
- **Rust SDK** (`web4-core/`): Has ATP/R6 but no rate-negotiation types
- **Hestia daemon**: Handles presence-protocol (inward MCP) but does not yet
  implement cross-society exchange (outward MCP)
- **Hardbound**: Not yet at the layer where cross-society ATP settlement occurs

**Gap**: No existing implementation exercises the §7.7 flow. The first
implementation will likely need to be a standalone conformance runner (similar
to `presence-protocol-conformance.json` harness pattern) before being
integrated into a product.

---

## 5. Promotion Gate Checklist

An operator (or future PolicyEntity) evaluates this checklist. All items must
pass for promotion from `v0.1.0-draft` to `v0.1.0-normative`:

### Structural prerequisites
- [ ] PR #200 merged (§7.4 envelope carries referent-grounded shape)
- [ ] F11 resolved (settlement signing authority unambiguous)
- [ ] F8 verification passes (§7.4↔§4.1 header reconciliation consistent with §7.7)

### Design decisions made
- [ ] Q1 decided: counter-offer depth model chosen
- [ ] Q2 decided: Oracle binding/advisory semantics explicit
- [ ] Q3 decided: termination-notice governance tier classified
- [ ] Q4 decided: rejection accountability model (or explicit "no consequence")
- [ ] Q5 decided: single vs. multi-referent proposal cardinality

### Wire format frozen
- [ ] §7.7.3 schemas updated to reflect Q1–Q5 decisions
- [ ] JSON Schemas added to `schemas/mcp-protocol/` (or `schemas/exchange-rate/`)
- [ ] Conformance vectors authored (analogous to `presence-protocol-conformance.json`)
- [ ] Per-subsection markers updated: §7.7.2/§7.7.3/§7.7.7 → "Normative"

### Implementation evidence
- [ ] Two independent implementations pass conformance vectors
- [ ] Cross-implementation interop demonstrated
- [ ] Error-path coverage (all 7 §7.7.7 failure modes)
- [ ] Standing-agreement lifecycle tested
- [ ] Oracle-referenced negotiation tested

### Documentation
- [ ] §7.7 status line updated to `v0.1.0-normative`
- [ ] §7.7 preamble "SHOULD NOT depend" removed
- [ ] CHANGELOG entry for the promotion (per `presence-protocol-CHANGELOG.md` pattern)
- [ ] Cross-references in §7.4, §7.6 updated to reference normative §7.7

---

## Notes

- The presence-protocol v0 (committed 2026-05-16) establishes a discipline
  pattern: spec + schemas + conformance vectors + CHANGELOG as an atomic unit.
  §7.7 promotion should follow the same pattern.
- Questions Q1–Q5 are design decisions, not research. Each has a small
  enumerated option set. An operator can resolve them in a single focused
  session.
- The "two implementations" requirement is the real long-pole. It requires
  either (a) adding rate-negotiation types to two SDKs (Python + Rust/TS) or
  (b) a standalone conformance runner exercising the MCP tool surface directly.
  Pattern (b) exists for presence-protocol and is the likely path.
