Protocol changelog

Changes to the Zanii protocol specification. Every 1.x version describes "v": 1 objects; see GOVERNANCE.md for what each kind of change means. Each released version is frozen verbatim in versions/.

1.3 — 2026-10-19 · frozen

Decimals in payloads (§3). Non-integer numbers are encoded as RFC 8785 specifies instead of being refused, so tool inputs and outputs with prices, coordinates or scores can be recorded. Python reproduces ECMAScript's number form byte for byte (checked over 257,612 values and in @zanii/conformance 0.2.0). Every payload valid under 1.2 hashes exactly as before; only payloads 1.2 refused are newly accepted. A 1.2 verifier still verifies every 1.3 receipt; it cannot run verifyPayload on a payload holding a decimal.

1.2 — 2026-10-19 · frozen

All additions are optional fields or conventions over existing "v": 1 objects; a 1.1 verifier accepts every 1.2 receipt.

• Risk level (§3). An optional risk field (low, medium, high, critical) says what is at stake in an action. Policies can match on it; verifiers never reject on it.
• Session close (§15). A receipt with target zanii.session.close marks the end of a run, so a verifier can tell a run that finished from one that was cut off. Audit bundles report whether the newest receipt closes its session.
• Payload encoding, two edge cases made explicit (§3). Integers outside ±(2^53−1) are rejected, and object keys order by UTF-16 code units. Both were already implied by RFC 8785; the Python SDK now follows them as the TypeScript SDK did, so the two hash identical bytes for every payload either accepts.
• Conformance vectors. @zanii/conformance publishes language-neutral must-accept and must-reject cases for every verification step. Both reference SDKs pass all of them.
• Formal model. A TLA+ model of the log and its monitor (formal/), checked with TLC: history stays append-only even under a dishonest operator, and the monitor raises no false alarms under concurrent appends.

1.1 — 2026-09-29 · frozen

Specified the payload encoding (§3). A payload_hash commits to the payload's RFC 8785 JCS bytes: keys sorted, no whitespace, raw UTF-8, a missing payload encoded as null, and non-integer numbers rejected rather than encoded. Before 1.1 this step was undefined, and the two reference SDKs had chosen different serialisers, so the same payload hashed differently in each. Receipts written under the rule carry the additive "payload_encoding": "jcs"; receipts without it are pre-1.1 and are checked with the legacy verifiers, which report which earlier encoding matched.

1.0 — 2026-09-05 · frozen

The baseline: delegation certificates and scopes (§2), signed hash-chained action receipts with salted payload commitments (§3–§4), the RFC 6962 transparency log with inclusion and consistency proofs (§5), revocation (§6), on-chain anchoring (§7), audit bundles carrying the anchors their receipts need (§8), cross-organisation co-signed receipts (§9), reputation and payments (§10), selective disclosure (§11), owner confirmation of irreversible actions (§12), infrastructure co-signatures (§13), and N-party swarm receipts (§14).