CIP-39: Cowboy Queue System

​

Abstract

​

Background

​

Goal

1. cross-runner message exchange with no consensus write and no chain read on the data path;
2. ordered replay, and at-least-once work delivery in which consumers compete for records rather than receive them in order;
3. push delivery with bounded, explicit backpressure;
4. owner-controlled authorization and revocation through chain authority, applied within a bounded lag;
5. durable commit before acknowledgement, with a signed provider commitment over each committed batch that a party holding that batch can verify;
6. cheap logical room or document creation inside one stream;
7. continued data-plane service for established sessions while the chain is unavailable — bounded by cbqs.max_snapshot_age_blocks for opening new sessions and by grant expiry for holding open ones (§3).

​

Specification

​

1. Terms

​

2. Trust model

​

3. Architecture

        CHAIN (governance + registry plane)
   provider records, stream ownership, admin keys,
   authorization generations, prepaid accounts,
   governance parameters
                 |
                 |  periodic finalized snapshot read
                 v
        +-----------------+          +-------------------------+
        |      cbqsd      | <======> |   runner workloads      |
        | records, lanes, |  push +  |   producers + consumers |
        | groups, leases, |  credit  |   (StreamGrant auth)    |
        | checkpoints     |          |                         |
        +-----------------+          +-------------------------+

SYS_CBQS = 218

• A new session requires a snapshot no older than cbqs.max_snapshot_age_blocks. Past that age the broker MUST refuse OpenSession with ChainStateStale.
• Every grant expires. cbqs.max_grant_ttl_ms caps the lifetime an owner can issue, and §7 requires a broker to terminate a session when its grant expires. That expiry, not the snapshot age, is the guaranteed bound on a revoked or unpaid holder, because it is the one bound that holds even against a broker that never refreshes.

​

4. Chain objects

SigningPublicKey = alg_tag_u8 || key_bytes    // Ed25519 = 1, 32 key bytes

​

4.1 ProviderRecordV2

ProviderRecordV2 {
  version:            u8,      // 2
  chain_instance_id:  Bytes32,
  provider:           Address,
  signing_key:                SigningPublicKey,
  signing_key_since:          u64,   // finalized height at which signing_key took effect
  previous_signing_key:       Option<SigningPublicKey>,
  previous_signing_key_since: u64,   // lower bound of the previous key's interval
  endpoints:          Vec<Bytes>,     // each a wss:// URI, printable ASCII
  accepts_new:        bool,
  max_streams:        u64,
  assigned_streams:   u64,
  metadata_hash:      Bytes32,
}

1. the endpoint list is nonempty and at most cbqs.max_provider_endpoints long;
2. each URI is at most cbqs.max_provider_endpoint_uri_bytes bytes and begins with the byte string wss://, compared byte-exactly; and
3. every byte is in the closed range 0x21–0x7E inclusive — printable ASCII, excluding space and every control byte.

ACCEPT   wss://cbqs.example/ws
ACCEPT   wss://cbqs.example:8443/ws
ACCEPT   wss://[2606:4700:4700::1111]/ws
ACCEPT   wss://198.51.100.7:8443/ws
ACCEPT   wss://cbqs.example/~a!b                 (rule 3: 0x21 and 0x7E both admitted)

REJECT   https://cbqs.example/ws                 (rule 2: scheme)
REJECT   WSS://cbqs.example/ws                   (rule 2: case)
REJECT   wss://cbqs.example/a{HT}b               (rule 3: control byte)
REJECT   wss://cbqs.example/a{SP}b               (rule 3: space)
REJECT   wss://169。254。169。254/ws              (rule 3: non-ASCII)
REJECT   wss://good.example／evil/ws             (rule 3: non-ASCII)

CBQS_PROVIDER_REGISTRATION_CHARGE = 5_000_000_000     // nano-CBY

​

4.2 StreamRecordV2

StreamStatusV2 = Active = 1 | Closed = 2

StreamRecordV2 {
  version:                  u8,      // 2
  chain_instance_id:        Bytes32,
  stream_id:                Bytes32,
  owner:                    Address,
  owner_nonce:              u64,
  admin_key:                SigningPublicKey,
  provider:                 Address,
  authorization_generation: u64,
  status:                   StreamStatusV2,
}

stream_id =
  keccak256(
    "cbqs/stream-id/v2" ||
    chain_instance_id ||
    owner_address_20 ||
    owner_nonce_u64_be
  )

​

4.3 CbqsAccountV2

CbqsAccountV2 {
  version:            u8,       // 2
  owner:              Address,
  provider:           Address,
  balance:            u128,     // nano-CBY held in registry custody
  active_streams:     u64,
  rate_per_block:     u128,     // snapshotted; see §6.1
  last_settled_block: u64,      // finalized height
  suspended:          bool,
}

• the rent clock, the balance, and the solvency flag are shared by exactly the streams one provider serves for one owner, so two of them can never disagree about any of it;
• settle has exactly one provider to pay, so the rent split is a single credit rather than a distribution over an unbounded set, and every instruction’s state-I/O is a fixed pair (§15.1); and
• a provider’s collectible is isolated from the same owner’s streams at other providers. A sibling elsewhere cannot drain the pool this provider is owed from, so the exposure §6.3 discloses is bounded by this provider’s own settlement cadence.

CBQS_MIN_ACCOUNT_TOPUP = 1_000_000_000     // nano-CBY

balance = amount, active_streams = 0, suspended = false,
rate_per_block = 0,
last_settled_block = H            // the finalized height of the creating instruction

​

4.4 Application migration

1. create a new stream naming the new provider;
2. copy or replay the data from a durable source the application controls;
3. issue new grants and redirect clients; and
4. close the old stream only after verifying that the target’s latest checkpoint covers everything the source held.

​

5. Chain instructions

RegisterProviderV2 {
  signing_key:   SigningPublicKey,
  endpoints:     Vec<Bytes>,
  max_streams:   u64,
  accepts_new:   bool,
  metadata_hash: Bytes32,
}

UpdateProviderV2 {
  signing_key:   Option<SigningPublicKey>,
  endpoints:     Option<Vec<Bytes>>,
  max_streams:   Option<u64>,
  accepts_new:   Option<bool>,
  metadata_hash: Option<Bytes32>,
}

CreateStreamV2 {
  owner_nonce: u64,
  provider:    Address,
  admin_key:   SigningPublicKey,
}

UpdateStreamV2 {
  stream_id:                     Bytes32,
  admin_key:                     Option<SigningPublicKey>,
  bump_authorization_generation: bool,
}

CloseStreamV2      { stream_id: Bytes32 }
TopUpAccountV2     { owner: Address, provider: Address, amount: u128 }
SettleAccountV2    { owner: Address, provider: Address }
WithdrawAccountV2  { provider: Address, amount: Option<u128> }   // absent = the whole balance

​

5.1 The provider’s close

CloseStream submitted by the assigned provider MUST first settle the account (§6.1) and is authorized only if, after that settlement, balance < rate_per_block * active_streams — the account cannot fund even one more block of the streams it has. Otherwise it MUST be rejected without effect.

​

6. Billing

• retained_bytes_limit measures the records and their checkpoint receipts (§12), each receipt discarded once the floor passes the last record it attests.
• Delivery cycles are bounded by a product, not by that limit. One cycle exists per (retained record, applicable group), and §9.2 reclaims each with the record it names — so the floor bounds them, but their bytes are not inside retained_bytes_limit. The bound is retained records × cbqs.max_groups_per_stream, and it is stated rather than folded into the byte limit because folding it in would make creating a group evict data: a group starting at At(first_retained_sequence) mints a cycle for every retained record at once, and a byte limit that saw them would advance the floor in response.
• Everything else is bounded by count: lanes by cbqs.max_lanes_per_stream, groups by cbqs.max_groups_per_stream, leases by cbqs.max_groups_per_stream × max_in_flight, and one settings record per stream. The lease figure is a ceiling on the configuration rather than a reachable count: a lease exists only while a delivery is outstanding, so at the §15 defaults the number a broker actually holds is bounded an order of magnitude lower by the delivered rate — 4,194,304 B/s sustained over a 30-second max_visibility_ms, divided by a 152-byte delivery frame, is about 828,000 against a configured ceiling of 16,777,216. The two do not stay in that order: at the §15 maximums the rate-derived figure is the larger of the two, so a provider takes whichever is smaller for the settings in front of it.

​

6.1 Settlement

settle(account, H):                       // charges; changes no counter
  require H >= account.last_settled_block            // else fail closed

  if not account.suspended:
      due = (H - account.last_settled_block)
            * account.rate_per_block
            * account.active_streams                 // checked u128
      if account.balance >= due:
          account.balance -= due
          paid = due
      else:
          paid = account.balance
          account.balance = 0
          account.suspended = true
  else:
      paid = 0                                       // a suspended account accrues nothing

  account.last_settled_block = H
  distribute(paid, account.provider)
  return paid

finalize(account):                        // runs LAST in every handler
  if account.active_streams == 0:
      account.suspended = false                      // nothing is owed
  else if account.suspended
          and account.balance >= account.rate_per_block * account.active_streams:
      account.suspended = false
  if account.balance == 0 and account.active_streams == 0:
      delete account

CBQS_PROVIDER_BPS = 9_000                      // protocol constant

provider_share = paid * CBQS_PROVIDER_BPS / 10000
platform_share = paid - provider_share

​

6.2 Solvency, and what the broker refuses

suspended == false
  AND balance >= (H_snapshot - last_settled_block)
                 * rate_per_block
                 * active_streams          // checked; overflow fails closed

​

6.3 Creation charge, and the write-off

CBQS_STREAM_CREATION_CHARGE = 5_000_000_000     // nano-CBY

​

7. Authorization

StreamGrantV2 {
  version:                  u8,      // 2
  chain_instance_id:        Bytes32,
  stream_id:                Bytes32,
  authorization_generation: u64,
  grant_nonce:              Bytes32,
  holder_signing_key:       SigningPublicKey,
  verbs:                    u16,
  lane_scope:               Any = 1 | Exact = 2 (u64) | Set = 3 (Vec<u64>),
  group_scope:              Any = 1 | Exact = 2 (u64),
  not_before_ms:            u64,
  expires_at_ms:            u64,
  max_message_bytes:        u32,
  max_append_bytes_per_sec: u64,
  signature:                Signature,
}

grant_id = keccak256(stream_grant_signing_bytes_v2(grant))

1. the exact chain_instance_id and stream_id;
2. authorization_generation equal to the snapshot’s value;
3. the admin-key signature over stream_grant_signing_bytes_v2;
4. the time window, allowing at most cbqs.max_clock_skew_ms, evaluated as not_before_ms <= now + cbqs.max_clock_skew_ms and now <= expires_at_ms. The skew is applied to not_before_ms only: a grant already past its raw expires_at_ms MUST be rejected with GrantExpired, because admitting it inside the skew would open a session §7 requires to terminate at once — a session with no usable lifetime, and no single ordering of SessionOpened and GrantExpired for a client to expect. Both comparisons arrange the skew against the broker’s own clock rather than against a grant field, for the reason check 5 gives: the grant’s two timestamps are u64s an unauthenticated peer chose, so not_before_ms - skew underflows at not_before_ms = 0 and expires_at_ms + skew overflows at u64::MAX, while now + skew is bounded by a clock and a governance parameter;
5. not_before_ms < expires_at_ms first, then expires_at_ms - not_before_ms <= cbqs.max_grant_ttl_ms — the ordering is normative because the subtraction is over two u64s an unauthenticated peer chose, and an underflow is a panic in a checked build; and a Set lane scope of at least two and at most cbqs.max_lane_ids_per_grant sorted, unique ids — a one-element Set MUST be rejected, because Exact already expresses it, and a broker admitting both would verify two grant preimages and issue two grant_ids for one authority. That is not forbidden in general — grant_nonce exists so an owner can mint distinct grants over identical terms, and so give each holder a distinct grant_id to name in its session proof — but it should be deliberate rather than a side effect of two spellings of one scope. Distinct grants are not separately revocable: version 2 has no per-grant revocation, and UpdateStream’s two levers both act on the whole stream, so revoking one holder invalidates every outstanding grant at the next snapshot refresh. An owner that needs a smaller blast radius uses shorter expiries, which check 5 bounds;
6. verbs has no bit above 7 set, then the requested verb, and both scope dimensions by intersection — a group scope never widens a lane scope; and
7. the grant’s max_message_bytes and max_append_bytes_per_sec against the stream’s §13 settings, the effective bound being the lower of the two.

SessionProofV2 {
  version:           u8,       // 2
  chain_instance_id: Bytes32,
  stream_id:         Bytes32,
  grant_id:          Bytes32,
  session_id:        Bytes32,
  challenge:         Bytes32,
  signature:         Signature,
}

• proof.session_id and proof.challenge are the exact pair issued for this OpenSession on this connection, and that pair has not already completed a session — so a captured CompleteSession frame opens nothing, and the broker retains at most cbqs.max_sessions_per_connection pairs, which die with the socket;
• the proof arrives before the challenge’s expires_at_ms;
• proof.grant_id == grant_id(grant) for the grant carried in OpenSession, and proof.stream_id and proof.chain_instance_id equal that grant’s; and
• the signature verifies under grant.holder_signing_key.

• the grant’s expires_at_ms passes — this is the bound §3 relies on, and it needs no snapshot refresh to observe;
• the snapshot shows the grant no longer matches (a bumped authorization_generation, a rotated admin key, or a Closed stream), no later than the first request the broker serves after the refresh that observed the change; or
• the connection carrying it closes.

​

8. Lanes

LaneRecordV2 {
  version:       u8,       // 2
  stream_id:     Bytes32,
  lane_id:       u64,
  status:        Active = 1 | Closed = 2,
}

​

9. Records and delivery

AppendRequestV2 {
  lane_id: u64,
  payload: Bytes,
}

RecordHeaderV2 {
  version:   u8,       // 2
  stream_id: Bytes32,
  lane_id:   u64,
}

​

9.1 Producer retries and duplicates

​

9.2 Consumer groups

GroupConfigV2 {
  version:                  u8,       // 2
  group_id:                 u64,      // broker-assigned, §9.2
  lane_id:                  u64,
  start:                    Head = 1 | At = 2 (sequence: u64),
  visibility_timeout_ms:    u64,
  max_visibility_ms:        u64,
  max_in_flight:            u32,
  max_in_flight_per_holder: u32,
  max_attempts:             u16,
  record_deadline_ms:       u64,
}

ACKED | EXPIRED

• Ack transitions the cycle to ACKED.
• Nack ends the attempt and frees the in-flight slot at once, and the record becomes deliverable again at issued_at + visibility_timeout_ms — the moment a silent expiry would have released it — or reaches EXPIRED when the completed attempt exhausts max_attempts. A record waiting out that interval holds no lease and occupies no max_in_flight slot, which is stated because the interval is the one point where a cycle is neither leased nor terminal: a broker that held the slot would let one holder freeze a group for the whole interval with a single round trip, and Backpressure would then clear on a timer rather than “as other holders drain” (§14).
• Extend sets expiry to min(now + extend_ms, issued_at + max_visibility_ms).
• Reject transitions directly to EXPIRED.
• passage of record_deadline_ms, measured from the moment the record’s batch crossed the durable-commit boundary (§10), transitions the cycle to EXPIRED.

​

10. Durability and checkpoints

CheckpointReceiptV2 {
  version:             u8,       // 2
  chain_instance_id:   Bytes32,
  stream_id:           Bytes32,
  provider:            Address,
  first_sequence:      u64,
  last_sequence:       u64,      // >= first_sequence
  records_digest:      Bytes32,
  previous_checkpoint: Bytes32,
  committed_at_ms:     u64,
  snapshot_height:     u64,      // finalized height, physical
  signature:           Signature,
}

checkpoint_id = keccak256(checkpoint_signing_bytes_v2(receipt))

record_digest(r) =
  keccak256("cbqs/record/v2" || canonical(RecordHeaderV2) || keccak256(payload))

records_digest =
  keccak256(
    "cbqs/records-digest/v2" ||
    record_count_u32_be ||
    record_digest(first) || ... || record_digest(last)
  )

snapshot_height >= signing_key_since                        -> signing_key
snapshot_height >= previous_signing_key_since
    and previous_signing_key present                        -> previous_signing_key
otherwise                                                   -> no key resolvable

• a key resolves and the signature verifies — valid;
• a key resolves and the signature does not verify — invalid, and the verifier MUST reject it; and
• no key resolves, because the receipt predates the rotation before last — unverifiable, which the verifier MUST report as such rather than as invalid.

​

11. Transport and flow control

​

11.1 Frames

CbqsClientFrameV2 =
  1 OpenSession     { request_id: Bytes32, grant: StreamGrantV2 } |
  2 CompleteSession { request_id: Bytes32, proof: SessionProofV2 } |
  3 Request         { request_id: Bytes32, session_id: Bytes32, body: CbqsRequestBodyV2 }

CbqsServerFrameV2 =
  1 SessionChallenge { request_id: Bytes32, session_id: Bytes32,
                       challenge: Bytes32, expires_at_ms: u64 } |
  2 SessionOpened    { request_id: Bytes32, session_id: Bytes32,
                       snapshot_height: u64 } |
  3 Response         { request_id: Bytes32, body: CbqsResponseBodyV2 } |
  4 Delivery         { session_id: Bytes32, subscription_id: Bytes32,
                       lease: Option<Bytes32>, header: RecordHeaderV2,
                       sequence: u64, payload: Bytes } |
  5 Error            { request_id: Option<Bytes32>, code: u16, message: Bytes, details: Bytes } |
  6 DeliveryState    { session_id: Bytes32, subscription_id: Bytes32,
                       state: DeliveryStateBodyV2 }

CbqsResponseBodyV2 =
  1 Appended        { sequence: u64 } |
  2 LaneCreated     { lane_id: u64 } |
  3 Lanes           { lanes: Vec<LaneRecordV2>, next_after_lane_id: Option<u64> } |
  4 Settings        { settings: StreamSettingsV2, group_ceilings: GroupCeilingsV2 } |
  5 Checkpoint      { receipt: CheckpointReceiptV2 } |
  6 Group           { config: GroupConfigV2 } |
  7 GroupCreated    { group_id: u64 } |
  8 Ok |
  9 CursorProgress  { subscription_id: Bytes32, lane_id: u64, scanned_through: u64 }

GroupCeilingsV2 {
  max_visibility_ms:    u64,     // cbqs.visibility_ms
  max_attempts:         u16,     // cbqs.max_attempts
  max_in_flight:        u32,     // cbqs.max_in_flight_per_group
}

DeliveryStateBodyV2 =
  1 CreditShort     { needed_bytes: u32 }

domain = UTF8("cowboy/room-lane/v1")
Messages: commitment = keccak256(domain || room_id || u8(1))
Inbox:    commitment = keccak256(domain || room_id || u8(3) || seat_id)
lane_id = u64_be(commitment[0..8])

​

11.2 Subscriptions and credit

SubscriptionSourceV2 =
  1 Cursor { lane_scope, start: Head = 1 | At = 2 (u64) } |
    // At(n) delivers from sequence n inclusive; Head delivers only records
    // committed after the subscription opens.

  2 Group  { lane_id: u64, group_id: u64 }

​

11.3 Replay

​

11.4 Dialing policy

​

12. Retention

• retention_ms has elapsed since the broker committed it, or
• keeping it would put the stream above retained_bytes_limit, in which case the floor advances over the oldest records until it would not.

​

13. Broker-side stream settings

StreamSettingsV2 {
  version:                     u8,      // 2
  retention_ms:                u64,
  retained_bytes_limit:        u64,
  max_message_bytes:           u32,
  max_append_bytes_per_sec:    u64,
  max_delivered_bytes_per_sec: u64,
}

D  >=  (G x (152 + 35 + n) + 43) / (12 + n)  x  A

​

14. Typed errors

​

15. Parameters and bounds

• Admission — read when an instruction or a request is admitted; the accepted object never consults it again.
• Ceiling — bounds a value at the moment it is set (§13 settings, §9.2 group config). The accepted record stores its resolved value, so a later write never redefines an existing stream or group. §13 states this as a rule, not only as a class.
• Runtime — read continuously by the broker; a change takes effect with the snapshot that carries it. Only operational limits live here.
• Codec — a decode bound whose Maximum equals its Default, so a conforming decoder accepts the same byte strings on every deployment. Maximum equals Default does not by itself make a row immovable; the rule below does that.

• cbqs.retention_ms at 0 is the sharpest. §13 gives a stream that never set its own settings the parameter’s value, and §12 then treats every record as past its retention — so one write deletes the entire retained window on every such stream, chain-wide and irreversibly.
• cbqs.visibility_ms, cbqs.max_attempts and cbqs.max_in_flight_per_group at 0 make §9.2’s group config unsatisfiable in both directions at once — the field must be greater than zero AND no greater than the parameter — so no group can be created or updated again.
• cbqs.max_message_bytes, cbqs.max_retained_bytes_per_stream, cbqs.max_append_bytes_per_sec and cbqs.max_delivered_bytes_per_sec at 0 do the same to §13’s settings.
• cbqs.max_grant_ttl_ms at 0 admits no grant, since §7 check 5 requires not_before_ms < expires_at_ms. cbqs.session_handshake_timeout_ms at 0 expires every challenge before it can be answered. cbqs.max_lane_list_page at 0 admits no valid page size, since §11.1 rejects a limit of 0 and a limit above the parameter alike.
• cbqs.snapshot_refresh_ms, cbqs.slow_consumer_timeout_ms, cbqs.commit_batch_max_ms and cbqs.commit_batch_max_records at 0 make a loop spin or fire on every pass.

CBQS_STREAM_CREATION_CHARGE       = 5_000_000_000   // nano-CBY (§6.3)
CBQS_PROVIDER_REGISTRATION_CHARGE = 5_000_000_000   // nano-CBY (§4.1)
CBQS_MIN_ACCOUNT_TOPUP            = 1_000_000_000   // nano-CBY (§4.3)
CBQS_PROVIDER_BPS                 = 9_000           // (§6.1)

​

15.1 State-I/O reservations and metered cost

​

16. Chain events

​

17. Operational surface

​

18. Activation and removed surface

1. genesis MUST seed the Stream Registry singleton and every §15 parameter at its default, MUST reject a parameter set carrying any cbqs.* key §15’s table does not name, MUST NOT seed any other record under 0x17, and MUST leave 0x17 holding no native balance. Stating the rule exhaustively rather than naming version-1 artifacts is what keeps it checkable from this document alone — a validator does not need to know what version 1 stored in order to reject it. Seeding defaults also satisfies §15’s cbqs.stream_rate_per_block floor and its Codec-class equality, so neither needs a genesis check of its own; both bind governance writes, which is where §15 states them;
2. a decoder MUST reject a SYS_CBQS payload whose version byte is not 2;
3. a decoder MUST reject any stored CBQS record whose version byte is not 2; and
4. a broker store MUST carry a store-format marker cbqs/store-format = 2 written at creation, and a version-2 cbqsd MUST refuse to open a store whose marker is absent or not 2 rather than attempt a partial decode. The marker’s key is cbqs/store-format and its value is the single character 2; a store carrying a version marker under any other key has not satisfied this rule, whatever that marker says. The key is pinned because a deployed version-1 store writes its marker under a different key entirely, so a version-2 broker opening one finds the pinned key absent and refuses — the disposition this rule wants, and the one a rule stated only over “a version marker” would have left to the implementation. The marker, not a per-record byte, is what covers the durable broker state this document describes without giving it a canonical struct — leases, delivery cycles, both high-water marks, and the checkpoint-chain tail.

​

19. Conformance

1. it admits and rejects exactly the chain instructions §4–§6 define, with the state effects §6 defines and the events §16 defines. That clause is total, and deliberately not expanded into a checklist: an earlier draft enumerated fourteen cases under it, which added nothing a harness could not derive and drifted from the body twice. Two classes are worth naming because no gas vector can catch them — the initial field values §4.1, §4.2 and §4.3 state for a created provider record, stream record, and account, since two implementations seeding them differently meter identically; and the settle → effects → finalize order of §6.1, which a test distinguishes by closing the last stream of a suspended account whose balance is exactly zero and observing that the record is deleted;
2. it reproduces every pinned field of every vector in cip-39-gas-vectors-v2.json under the genesis parameter set of §18 rule 1 with no prior governance write — a null on a rejection path is not a value to reproduce (§15.1) — and meters every branch of every instruction with identical charged reads, charged writes, and cells, including settle’s full, partial, and suspended branches and the §4.3 account deletion, cycles differing only by payload bytes;
3. its canonical encodings round-trip through cowboy-protocol-codec::cbqs, reject every version byte other than 2 on every object §4 gives one, and produce byte-identical signing preimages for the three §4 registry entries;
4. its broker accepts and rejects sessions and requests as §7 and §11 define — continued service for established sessions across a simulated chain outage (§3); refusal of OpenSession past cbqs.max_snapshot_age_blocks; single-use session_id/challenge; rejection of a session_id not open on the sending connection; termination on grant expiry with no snapshot refresh; and termination under a revoked grant on the first request served after the observing refresh;
5. it refuses a lease action from any holder other than the one the lease was issued to; refuses a subscription request naming another session’s subscription; evaluates lane and group scope by intersection on every operation including lease actions; refuses CreateLane from a grant whose lane scope is not Any with LaneScopeTooNarrow, and CreateGroup from one whose group scope is not Any with GroupScopeTooNarrow; redelivers a lease that expires without a terminal action while an attempt remains and counts that attempt toward max_attempts, terminating instead on the expiry that exhausts them (§9.2); rejects an UpdateGroup that differs in any immutable field; and returns codes consistent with §14’s denial precedence;
6. its broker acknowledges no append before the batch containing it is durable; every acknowledged record still retained appears in a checkpoint a client holding CONSUME or REPLAY can retrieve with GetCheckpoint (§11.1) and whose records_digest recomputes; first_sequence equals the predecessor’s last_sequence + 1 along the whole chain and 1 at checkpoint_genesis (§9.1), and previous_checkpoint names the predecessor’s checkpoint_id at every step; snapshot_height and committed_at_ms do not decrease; a receipt whose provider is not the stream’s is rejected; and §10’s three verdicts are each reachable and correctly assigned — a receipt in the current key’s window verifies as valid, one in the previous key’s window verifies against previous_signing_key and is equally valid, one whose resolved key rejects the signature is invalid, and one below previous_signing_key_since is reported unverifiable rather than rejected;
7. its client rejects every destination in §11.4’s list — for an address literal read straight out of the URI as well as for a resolved name, and for every address a name resolves to and not only the first — refuses to follow a redirect at all, and connects only to a destination it checked;
8. its broker’s externally observable behaviour is the behaviour §6.2 and §§7–17 define. That clause is total, and clauses 4 through 7 name classes under it rather than exhausting it, for the reason clause 1 gives: an enumeration here adds nothing a harness cannot derive from the body, and the one this clause replaces had already fallen behind the body it was enumerating. The range names §6.2 explicitly and runs to §17 because both ends were once outside it: §6.2 is broker behaviour sitting in a chapter of chain instructions, and §17’s readiness rules were reachable by no clause at all. Three classes under it are worth naming because a passing implementation can differ without a client observing it on a healthy path — §6.2 evaluated on every append and every state-creating request rather than only at session open, which a test distinguishes by suspending an account mid-session; §6.2’s converse, that Ack, Reject, and Nack stay available while an account is suspended and that no new lease is issued while it is, which an over-refusing broker would otherwise satisfy vacuously; and §9.2’s reclamation of an ACKED or EXPIRED cycle, which is a MUST precisely because a broker that never reclaims answers a late Ack with DeliveryTerminal where a conforming one answers LeaseStale; and
9. a crash injected on either side of a durable write boundary leaves, after restart, either no record and no acknowledgement, or the record, its sequence, and its checkpoint together (§10); and
10. its activation satisfies §18: a genesis that seeds the singleton and every §15 parameter at its default and nothing else under 0x17, holds no native balance there, and carries no cbqs.* key §15 does not name; a handler that rejects a SYS_CBQS payload whose version byte is not 2; a decoder that rejects a stored record whose version byte is not 2; and a broker that refuses to open a store without cbqs/store-format = 2 under that key. Each is a boundary an implementation can be run against, and none of them is proved by the gas vectors, the structural checks, or the system-address invariant — those pass equally against a version-1 deployment.

• A. the broker’s snapshot-refresh attempt interval (§3);
• B. the truthfulness of the snapshot_height it reports in SessionOpened (§3) — a broker on a year-old snapshot can report the current height, because the frame carries no proof and none is defined;
• C. that it evaluates one request from one snapshot rather than mixing heights (§3);
• D. that session_id, challenge, and lease handles are chosen unpredictably (§7, §9.2) — a counter is indistinguishable from entropy on the wire, and the anti-replay and anti-oracle arguments rest on it;
• E. that lane ids and group ids are never reissued (§8, §9.2), which depends on durable state a client cannot inspect. It is lettered rather than dropped because a grant scoped to Exact(lane_id) or Exact(group_id) rests on it, and a broker that reissues an id hands an old grant authority over a new object without emitting a byte that differs;
• F. the starvation bound in §11.2, whose “scheduling round” has no wire representation; and
• G. that a checkpoint’s snapshot_height is a height the provider actually read (§10). It selects the verification key, so misstating it downward moves a batch into an earlier key’s window — where the receipt still verifies, since the provider holds that key too. What bounds the move is previous_signing_key_since, below which a receipt stops resolving to any key at all. Monotonicity bounds it only from the other side — a provider can never stamp a batch below where its own chain already stands — and does not constrain later batches, which remain free to return to the current height; and
• H. that an oversized frame is rejected before allocation and that every variable-length field is capped at decode rather than at verification (§11.1). The refusal is observable — it has a code and a response — but its position relative to allocation and signature verification produces the same response bytes either way, so a client cannot tell a conforming broker from one that allocates first and refuses second; and
• I. that the broker does not interpret payload bytes (§9) — one that parses, indexes, or routes on them emits identical frames, identical chain state, and identical codes, so §2’s confidentiality framing rests on an obligation no probe can distinguish; and
• J. that an application whose data must survive its provider keeps its own durable copy (§2) — an obligation on a party outside this protocol, which no chain state, wire byte, or broker response can evidence.

​

Security Considerations

​

Rationale

​

The chain is a governance plane, not a data plane

​

The economic unit is the (owner, provider) relationship

​

Flat rent, snapshotted per billing run

​

One delivery class, batch checkpoints, no lane proofs

​

Broker-assigned lane and group ids

​

Rejected alternatives

• Keep version 1 and fix it incrementally. Most of the removed surface is load-bearing for other removed surface: quotes exist because rates are per-stream, reservations because quotes do, lane tombstones because lane ids are client-chosen. Removing them one at a time leaves the document inconsistent at every intermediate step.
• Drop billing entirely and let providers bill off chain. Ownership, authorization, and payment are what the platform exists to arbitrate; a broker with a private customer table is not a Cowboy service.
• Adopt an existing broker unchanged. Kafka, NATS, or RabbitMQ cannot verify a StreamGrant or enforce a chain-controlled generation. That is a true statement about a false choice, and it is worth naming as such: the alternative to adopting a broker unchanged is not defining one from scratch. A third option is a thin chain-aware adapter that verifies grants, generations and tenancy, and maps durability, consumer groups, retry and backpressure onto a mature broker underneath — which is where most of §§9–13 would go. This document does not take it, because the mapping is not free (lease semantics, ordering within a lane, and the checkpoint boundary each have to survive it) and no candidate has been evaluated against those three. But it has not been evaluated against, either, and a reader comparing v2’s size to an off-the-shelf broker deserves to know the option was recognised rather than argued away. cbqsd’s storage engine remains pluggable, which is the smallest version of the same idea.
• Keep per-request signatures. They cost a signature and a verification per message and defend against an attacker who, having reached the required position, can already reorder and drop frames.
• Meter messages and bill per byte. Metering requires trusting a provider-reported counter or putting usage on chain. A flat rate bounded by per-stream ceilings the broker already enforces keeps both off the table.
• Carry arrears instead of writing them off. An abandoned account would accumulate a debt nobody will pay, which no party can act on and which makes revival cost more the longer it is left.