igneum/docs/spec/09-pool-protocol.md

Igneum protocol specification, section 9: the pool protocol

Spec version 0.1, 3 October 2026. Status of this section: Designed. Nothing here is implemented. The only miner-to-worker protocol that exists is the devnet worker protocol (igneum-miner --worker, vendor/igneum-node/igneum/miner/src/main.rs; --serve in proto-cuda/host.cu, proto-opencl/host.c, proto-metal/main.swift), which runs between two processes on one machine and is cited here where this section reuses it. The review of 3 October 2026 found that no pool protocol existed and that "shares on a 64-bit lane hash with vardiff are unspecified" (docs/review/round-3-2026-10-03.md, farm operator, attack 3, R3.15). This section is the answer.

Lineage, credited. The shape is Stratum V2's (Braiins and the Stratum V2 working group, stratumprotocol.org), from memory and approximate: a binary, encrypted protocol with a Mining Protocol for shares, a Job Declaration Protocol under which a miner builds its own block template from its own node and declares it to the pool, which may accept it and must then pay shares found on it, and a Template Distribution Protocol between the miner and its node. Igneum keeps the three ideas (encrypted transport, miner-built templates under the pool's payout, pool pays by shares) and changes what the header carries: on Igneum the header names a vote key (section 2.4) and the vote key decides finality (section 3), so this section also fixes whose key a pooled block names and who signs the checkpoint votes. The ledger entries F10 and G6 (pools hold the votes; Stratum V2 job declaration is optional) are the two criticisms this section is written against.

Two words that collide. In this section "pool" means a mining pool: an operator that distributes work to many hashers and pays them by shares. The "proving pool" of sections 2.5 and 5.3 is the 20% emission share paid to provers and is called "the proving share" here whenever it is meant.

9.1 Roles and what each one holds

Role	Runs	Holds	Never holds
Member	The operator's miner program (the signer), on a machine the operator controls, driving one or more GPU workers over the worker protocol	The operator's vote key (section 3.1 W1, section 8.5 item 4), the operator's payout preference, a verifier: either a full node or the light client of section 10	The pool's keys
Worker	A GPU process fed job lines by the member (the --serve protocol)	Nothing: no key, no template, no network connection	Any key
Pool	A server that builds templates, issues jobs, verifies shares, pays members, relays votes and carries them in its templates	Its own payout address, its own full node, its members' public keys and share ledger	Any member's secret key
Member's verifier	A full node or a section 10 light client	The chain state the member checks templates and checkpoints against

The signer is one process per vote key (9.6). Hashing rigs that carry no key are workers, and a member MAY drive any number of workers on any number of machines from one signer.

9.2 What the pool cannot do, and how a member would notice

This section exists so that each row of the following table is true for a conforming member against any pool, conforming or not.

The pool tries to	Why it fails against a conforming member	How it shows
Leave out or reorder transactions the member wanted in its block	The member receives the full template (9.4, mode A) or builds its own (mode C) and checks it against its verifier before hashing it; a declared template is paid like any other	A pool that refuses declared templates answers with a code (9.5, template_refused) and the member counts refusals; the explorer shows which templates each pool's blocks came from by the template_mode tag in the coinbase extra data
Name its own vote key in the header	The pre-PoW hash commits to vote_key_hash (section 2.2, fork point a5), the member checks the field against its own key before hashing and refuses a job that names another	A pool whose blocks all name one key is a custodial pool (9.6 item 5); any observer counts keys per payout address from headers and bodies alone
Drop a member's checkpoint votes	Votes are signed by the member and reach the chain by three roads (9.7): the pool's template, the member's own template and any node's submitFinalityVote. The member checks that the template it is about to hash carries its outstanding votes	Participation per key is public (getFinalityWeights, section 3.10) and computed from votes in blocks (Q2); 9.7 item 6 gives the chain-only test
Make a member sign a wrong checkpoint	The member signs only a checkpoint hash its own verifier reports; a member without a verifier does not vote (9.7 item 2)	A member that signs two hashes at one index produces equivocation evidence against itself (section 3.6), which is why the rule is "no verifier, no vote"
Withhold a block the member found	The member holds the full block and submits it to its own node as well as to the pool (9.5, solution)	The block is on the chain whatever the pool did
Underpay shares	Share weight is fixed by this section (9.8) and the member keeps its own ledger of accepted shares	Not a protocol matter beyond the ledger; the member changes pool

What the pool can still do: choose the transactions in its own templates for members who take them as offered (mode A members who do not check, or mode B members), decline declared templates with a stated code, and concentrate hashrate. Vote weight, however, follows the members' keys (9.6), so pool concentration no longer equals vote concentration as section 3.7 item 3 states; that sentence describes a custodial pool and is narrowed by this section once a conforming pool exists (O-9.1).

9.3 Transport and encoding

Decision: newline-delimited JSON over TLS 1.3, one JSON object per line, UTF-8, binary fields as lowercase hex. Not the node's gRPC.

Why. The pool protocol crosses operators and languages: pools, mining operating systems and rental markets each have their own code base, and the lingua franca of every one of them is a line of JSON on a socket (Stratum V1 made it so). The node's gRPC surface is the node's own interface, it is edited at every fork point (docs/fork-divergence.md, the rpc/grpc rows) and a pool written against it would break at each. Line-oriented text also matches the worker protocol the member already speaks downward, so one miner program has one shape of message in both directions. TLS is required because Stratum V1 in plaintext is hijackable on the wire (the reason Stratum V2 encrypts, approximate), and a hijacked connection could feed a member a checkpoint hash to sign.

Rule	Value	Label
Transport	TLS 1.3, server-authenticated; the pool's certificate chain or a pinned public key the member obtained with the pool's address	Designed
Framing	One JSON object per line, \n terminated, no object over 4 MiB (a template with its transactions)	Designed
Field order	Irrelevant; unknown fields MUST be ignored	Designed
Integers	JSON numbers up to 2^53; anything that can exceed it (nonces, targets, hashes, weights in base units) is a hex string	Designed
Identifiers	id on every request, echoed on the reply; notifications carry no id	Designed
Port	4461 (the mainnet chain id, section 7.4), 4462 testnet, 4463 devnet; a pool MAY use another and say so in its address	Designed
Member authentication	The authorize message carries the member's BLS public key and a proof of possession (the KeyReveal of section 3.10, 144 bytes), plus a signature over the session's TLS exporter value under the same key, so the key proves it is live and the connection is bound to it	Designed

9.4 Templates

Three modes. The pool announces which it supports in welcome; every conforming pool MUST support A and C, and MAY support B.

Mode	What the member receives	What the member checks	For whom
A, full template (default)	The complete block: header fields except nonce, the coinbase (payout, the member's key reveal when outstanding, the finality section with the member's votes), every transaction as hex	Everything in 9.4.1	A member with a verifier and ordinary bandwidth
B, commitment	The header fields, the coinbase, the Merkle path from the coinbase to hash_merkle_root, and the transaction count; not the transactions	Header, coinbase and path; it cannot check transaction choice and the protocol marks its blocks template_mode: "B"	A member on a metered link that has chosen to trust the pool's transaction choice
C, declared	Nothing: the member builds the template from its own node with the pool's payout address and declaration constraints, and declares it; the pool replies with an id and issues jobs on it	The pool checks validity and payout; the member checks nothing further because it built it	A member that wants its own transaction choice, which is the Stratum V2 job declaration idea

9.4.1 What a member checks before hashing a template (modes A and B)

A conforming member MUST verify, against its verifier, every item below, and MUST refuse the job (job_refused with the code) when one fails:

1. vote_key_hash equals the hash of the member's own key.
2. The coinbase miner address is the pool's address announced in welcome (so the pool, not a third party, is paid) and, when the member's key has not yet been revealed on chain, the coinbase extra data carries the member's KeyReveal.
3. The finality section carries every vote the member sent in this session that is not yet carried by a block in the template's past (the pool reports carriage in votes_carried, and the member's verifier can confirm it).
4. daa_score, bits, pruning_point, the parents and seed_source agree with what the member's verifier reports for a block built now: parents are known tips or within the merge-depth bound, bits is the target the verifier computes for those parents (section 2.3), the epoch seed in seeds is the one the verifier holds for that DAA score (section 1.12).
5. Mode A only: hash_merkle_root recomputes from the transactions and the coinbase, no transaction is a state-free fault (design document, execution layer 1.5), and, when the member's verifier is a full node, the node accepts the block as a template (the node's own template validation; the RPC is the forward reference of O-9.4).
6. Mode B only: the Merkle path from the coinbase proves membership under hash_merkle_root.

Cost. Items 1 to 4 are field comparisons. Item 5 is one Merkle root over the block's transactions and one node call, both well under the 1-s template lifetime at any block size the gas budgets of the design document allow (Designed, not measured; the measurement is O-9.5). The lottery hash is not evaluated at job time at all: the member's CPU evaluates one 32-lane unit per found nonce only (9.8), at 0.441 ms per unit on one M5 Max core (Measured, docs/bench-log.md, igneum-pow entry; section 1.11).

9.4.2 Declared templates (mode C)

1. The member sends declare_template with the full block (as mode A would carry it) built from its own node, with the pool's payout address as miner, its own vote_key_hash, and the pool's declaration constraints from welcome honoured: at most max_extra_bytes of member extra data after the pool's tag, and the pool's tag (an opaque string the pool uses to attribute the block) placed first in the coinbase extra data.
2. The pool MUST reply within declare_timeout_ms (Designed 500 ms) with template_ack (an id) or template_refused with one of the codes of 9.5. A pool MUST NOT refuse a declared template on the content of its transactions; it MAY refuse for invalidity against its own node, a wrong payout, a missing tag, oversize, or a rate above max_declarations_per_s.
3. The pool issues jobs on a declared template as on its own; shares on it are paid identically (9.8).
4. A pool MAY cap the share of its hashrate on declared templates only by refusing new declarations with code capacity, never by paying them less.

A member that is refused on code other more than refusal_tolerance times in a session SHOULD disconnect and say why in its log; the pool's refusal rate is reported by the member in stats so that a mining operating system can show it.

9.5 Messages

Direction P = pool, M = member. Every message is one object with "t" naming the type.

Type	Direction	Fields	Meaning
hello	M to P	versions (list), chain_id, client, modes supported	Opens the session
welcome	P to M	version, chain_id, pool_address, modes, vote_mode (member or pool), declaration {tag, max_extra_bytes, max_declarations_per_s, declare_timeout_ms}, share_scheme (pplns or pps with its parameters), min_shift, max_shift	The pool's terms; the member shows vote_mode and share_scheme to its operator
authorize	M to P	pubkey (48 bytes hex), pop (96 bytes hex), binding (signature over the TLS exporter), label	Names the member by its vote key
authorized	P to M	member_id, revealed (true when the key has been revealed on chain, per the pool's node)
seeds	P to M	epoch_seed, day_seed, seed_source, vdf_proof (516 bytes hex, section 4.4, when the member asks), next_epoch_seed, next_day_seed, next_at_daa	Current and next seed pair so the member can prepare its workers ahead (the worker protocol's prepare)
set_target	P to M	shift s (9.8)	Vardiff
template	P to M	template_id, mode (A or B), header (every field but nonce, hex), coinbase, transactions (A) or merkle_path plus tx_count (B), votes_carried (indices of the member's votes in this template)	A new template; supersedes the previous one for new jobs
declare_template	M to P	header, coinbase, transactions	Mode C
template_ack	P to M	template_id
template_refused	P to M	code in {invalid, payout, tag, oversize, rate, capacity, other}, detail
job	P to M	job_id, template_id, prehash (64 hex), target64 (16 hex), share_target64 (16 hex), nonce_start (hex, a multiple of 32), nonce_count (hex, a multiple of 32), clean (bool)	Work. clean true means abandon earlier jobs. The member forwards it to its workers as a worker-protocol job line with share_target64 in the target field
job_refused	M to P	job_id, code in {vote_key, payout, reveal, votes, header, merkle, invalid, seeds}, detail	The member will not hash this job and says why
share	M to P	job_id, nonce (16 hex), hash (16 hex)	A lane hash at or below share_target64
share_result	P to M	job_id, nonce, accepted (bool), code in {ok, stale, duplicate, above_target, wrong_hash, unknown_job}, weight (the share's weight, 9.8)
solution	M to P	job_id, nonce, hash, block_hash	A lane hash at or below target64. The member has already submitted the block to its own node, or does so at once if it has none
checkpoint	P to M	index, hash, blue_score, daa_score, state	The pool's view, for information. A member MUST NOT sign from this message alone (9.7)
vote	M to P	index, hash, vote (280 bytes hex, section 3.10 C2)	The member's signed vote, for relay and carriage
vote_ack	P to M	index, relayed (bool)
votes_carried	P to M	list of {index, block_hash}	Blocks the pool's node has seen that carry the member's votes
stats	both	member: hashrate, workers, refusals, shares; pool: members, hashrate, blocks_24h, declared_share	For dashboards and the phone app (docs/design/phone-app.md), read-only
ping, pong	both	id	Liveness
bye	both	reason	Close

Sizes. A job line is under 300 bytes; a share under 120; a vote about 600 (hex of 280). A mode A template is the block, which at 1 BPS and the design document's budgets is a few KB to a few hundred KB (Designed, unmeasured; O-9.5); a mode B template is about 1 KB plus the coinbase.

9.6 Identity: one vote key per operator

Rule of 3 October 2026 (ledger F17; section 3.1 W6): keys are free, weight is the only Sybil-resistant quantity, and a rule that counts keys is a rule a splitter wins. This section applies it to pools.

1. A member's vote key is the operator's key, the one its client created under section 8.5 item 4. A pool MUST NOT create, derive or hold vote keys for its members, and a conforming client defaults to one key per operator. The devnet launcher's MINERS=8 identities per vendor is a devnet convenience and is withdrawn by this rule for any public network (ledger F17, "the client's one-key default" item, closed here as a rule and Open as code, O-9.2).
2. The header of every block a member finds names the member's key, in every mode. The pool's blocks therefore carry as many keys as it has members, and each member's 30-day weight (W2) is the blocks that member found, under any pool or alone, because weight follows the key and not the payout address. Moving between pools moves nothing.
3. Many rigs, one key: the key lives in one signer process (9.1) and the rigs are workers. An operator who runs two signers under one key risks equivocation (3.6): BLS signatures are deterministic, so two signers that see the same checkpoint hash produce the same vote, but two signers whose verifiers disagree during a partition sign two hashes at one index and strip the key's weight for 30 days. Two signers under one key is therefore a MUST NOT, and the client enforces it by refusing to start a second signer on the same key file.
4. Succession (W5) is the operator's: a pool never signs a succession message, because it never holds the key.
5. A custodial pool (vote_mode: "pool"): a pool MAY name its own key in every header it issues, and a member MAY accept that. The member's client MUST show the mode before the first share and MUST default to refusing it. A custodial pool's blocks all name one key, so its share of vote weight is visible to anyone who counts keys per payout address, and the explorer labels it. Section 3.7 item 3 describes this pool and no other.
6. Dust (W3) is per key: a member who finds fewer than 100 blocks in 30 days has no vote whichever pool it joins, which at one block a second is about 0.004% of hashrate (section 3.7 item 6). Pooling changes a member's variance of income, not its weight.

9.7 Votes: signed by the member, relayed by the pool

1. The member's signer reads checkpoints from its own verifier (a full node's getFinalityCheckpoints, or the light client of section 10), signs every checkpoint of the presence window it has not signed (section 3.3 Q2, as the devnet miner does, Voter::tick in main.rs), and sends each vote to the pool as a vote message. Nothing in the vote depends on the pool: the message signed is (chain_id, index, hash(C_i)) (C2), and the pool only sees the signature.
2. A member whose only source of checkpoints is the pool's checkpoint message MUST NOT vote. A silent key leaves the active denominator after the presence window and loses nothing but its say (Q2); a key that signs what it was told loses 30 days of weight if it was told wrong (3.6). The client enforces this: voting is on only when a verifier is configured, and the light client of section 10 counts as one.
3. The pool MUST relay every member vote to the network as its own node received it (the p2p vote message of section 3.10, C2) within relay_ms (Designed 1,000 ms, under the certificate grace of Q4, Open O-3.4) and MUST carry it in its next template's finality section unless a block in that template's past already carries it, under the per-block vote bound of O-3.3.
4. Aggregation in templates. Votes for one (index, checkpoint hash) pair MAY be aggregated inside a block into one signature with a bitmap (Q2). A pool with many members SHOULD aggregate its members' votes per index before carriage: at 10,000 voters and 2,880 checkpoints a day, unaggregated carriage needs 333 votes per block at 280 bytes each (93 KB per block), while an aggregate per index per block is one signature and a bitmap (Designed; the bitmap's size and canonical list are O-3.12). Aggregation needs no secret key, so the pool can do it, and the member's participation is credited either way (Q2 counts a vote carried "as a vote or inside a certificate", and an in-block aggregate is a vote carrier; the spec 03 wording should say "or inside an aggregate", O-9.3).
5. Three roads. A member's vote reaches the chain through the pool's template (item 3), through the member's own declared templates (mode C, its own finality section), and through submitFinalityVote on any node it can reach, including seed nodes; the signer SHOULD use at least two of the three. A vote carried twice costs block space and nothing else (section 3.10: "votes not already in its past").
6. Detecting a pool that drops votes, from the chain alone. For member key k with pool payout address A, over a presence window: let V_k be the indices at which k voted (k's own log, or the votes seen on any road), B_A the blocks whose miner is A, and C_A(k) the indices among V_k carried by some block in B_A within 60 blocks of k's vote. A conforming pool's |C_A(k)| / |V_k| is near 1 minus the fraction already carried by other blocks (item 3 lets it skip votes already in the past); a pool that drops votes shows a ratio near 0 while the same votes appear in other producers' blocks or in k's own. The ratio is computable by anyone from headers and bodies (k's key hash is in the header of k's blocks and k's key is revealed in the body; A is in every coinbase), so a pool's carriage ratio is a public statistic the explorer and the phone app show per pool. The threshold below which the client warns is Open (O-9.6).

9.8 Shares

The hash is 64 bits and is defined over an aligned group of 32 nonces (section 1.9), so a share is defined the same way.

1. A share for job j is a nonce n in the job's range with hash(n) <= share_target64(j), where hash(n) is lane n AND 31 of the group n AND ~31 under the job's prehash, init words I = seed_words_from_bytes("igneum-block/" || prehash || nonce_hi_le32) (section 1.6, header binding, O-1.9) and the job's seed pair.
2. share_target64 = min(2^64 - 1, target64 << s) for the shift s the pool last sent in set_target, min_shift <= s <= max_shift. The pool MUST choose s so that target64 << s does not saturate; a saturated target makes every hash a share and the pool's verification cost (item 5) unbounded. target64 is the block target of the template's bits under the mapping of section 1.10 (target64 = target256 >> 192, candidate, Open O-2.4).
3. Weight. A share at shift s counts 2^-s of a block: its expected cost is 2^64 / share_target64 hashes against 2^64 / target64 for a block, and the ratio is 2^-s exactly, so share weights are exact binary fractions and a pool's ledger needs no floating point. A solution (a share at or below target64) counts as a share at its job's shift plus whatever the scheme pays for the block.
4. Vardiff. The pool SHOULD set s per member so that the member sends about one share per share_interval_s (Designed 10 s): at the worker protocol's 64-bit hash and a card at 229 Mhash/s (the RTX 5090 bench figure quoted in docs/review/round-3-2026-10-03.md, R3.15), ten seconds is 2.3 x 10^9 hashes, which fixes s once target64 is known. The pool adjusts s by one per set_target and never more than once per 30 s (Designed), so the share rate is a smooth estimate of a member's hashrate for the dashboards.
5. Verification. The pool MUST verify every share by evaluating the 32-lane group on a CPU exactly as a node verifies a block (section 1.11): 0.441 ms per group steady on one M5 Max performance core, 0.87 ms worst cold (Measured, docs/bench-log.md, igneum-pow entry). One such core verifies about 2,270 shares a second, so at one share per 10 s per member one core covers about 22,000 members (derived from the measurement; a server core is the measurement of O-9.5). A pool MAY sample shares at high shifts; it MUST NOT credit a share it did not verify at a shift below sample_shift (Designed 8, so every share worth more than 1/256 of a block is checked).
6. The member re-checks every found nonce on its own CPU before sending it as a share, as the devnet miner already does for blocks (mine_worker, "cpu re-check ok"); a worker whose found lines fail the re-check is reported as WORKER MISMATCH and the share is not sent.
7. Rejections. stale: the job's template is superseded and the share is older than stale_grace_ms (Designed 2,000 ms, two block times, so a share found a moment after a new template still pays); duplicate: the nonce was already credited for the job; above_target: the pool's own evaluation exceeds share_target64; wrong_hash: the member's hash field disagrees with the pool's evaluation (a worker fault, reported to the operator).
8. Payment schemes are the pool's business. The protocol fixes share weight and the share_scheme disclosure; it does not fix PPLNS window lengths or PPS fees. A pool that pays the proving share: a member's blocks pay 80% of emission to the pool's address and 20% to the provers of the block (section 2.5), so a pool receives only the 80%; whether a pool also proves (its node holds the members' keys' sortition eligibility, section 7.2, because eligibility is by key and the key is the member's) is answered by 7.2 item 2: the assignee is the member's key, so a pool cannot prove in its members' name without their shard proofs carrying their keys (R3.13, provers naming in the proof statement). Pools that offer proving to members do so under the external job market's terms, outside this section.

9.9 Seeds and the epoch boundary

The program changes every epoch and the dataset every day (section 1.12), and an ahead-of-time worker needs the next pair before the boundary (the prepare command of the worker protocol, measured across boundaries in docs/bench-log.md, hot-swap entry).

1. The pool MUST send seeds on connection and whenever the current or next pair changes, with next_at_daa the DAA score of the boundary.
2. The member MUST check epoch_seed and next_epoch_seed against its verifier (the VDF output for the epoch, section 4.3; on the devnet, the hash of the last selected-chain block below 3,600 e - 600) and refuse jobs on a seed its verifier does not confirm (job_refused, code seeds). A pool that could choose the seed could choose the program, which is the grinding section 4 exists to prevent.
3. A member whose verifier is the light client of section 10 verifies the VDF proof (516 bytes, 4.5 ms, Measured, section 4.4) that the pool forwards in seeds, against the seed_source its checkpoint chain confirms.

9.10 Parameters in this section

Parameter	Value	Label
Transport	TLS 1.3, newline-delimited JSON	Designed
Ports	4461 / 4462 / 4463	Designed
Required modes	A (full template) and C (declared); B optional	Designed
declare_timeout_ms	500	Designed, Open O-9.5
relay_ms	1,000	Designed, tied to Q4's grace (O-3.4)
share_interval_s	10	Designed, Open O-9.5
Share target	target64 << s, never saturated	Designed
Share weight	2^-s of a block	Designed
sample_shift	8	Designed
stale_grace_ms	2,000	Designed
Vardiff step	one shift per 30 s at most	Designed
Pool-side verification per share	0.441 ms per 32-lane group, one M5 Max core	Measured (section 1.11); server core Open O-9.5
Vote key per member	the operator's own; one signer per key; pool holds none	Designed (ledger F17)
Custodial mode	allowed, disclosed, refused by default, visible on chain	Designed
Member without a verifier	hashes, does not vote	Designed
Vote carriage by the pool	every member vote in the next template, aggregated per index when many	Designed
Member template checks	9.4.1 items 1 to 6	Designed

9.11 Open items

Id	Item	What closes it	Gate
O-9.1	Section 3.7 item 3 ("pools hold their hashers' votes") describes a custodial pool once this section is implemented; the litepaper's pool sentence (ledger F10, G6, overclaims 44 and 45) should say that a conforming pool's members keep their keys and that custodial pools are visible on chain	A reference pool and a reference member run on the phase 4 devnet; the getFinalityWeights listing shows one key per member under the pool's payout address; then the sentence is rewritten and 3.7 narrowed	4
O-9.2	The devnet launcher runs MINERS=8 identities per vendor (ledger F17); the one-key default is a rule here and not code	The launcher and the official client start one signer per operator and any number of workers; the signer refuses a second instance on the same key file	4
O-9.3	Q2 counts a vote carried "as a vote or inside a certificate"; an in-block aggregate of votes (9.7 item 4) is a third carrier and the wording should name it; the bitmap and canonical list are O-3.12	Spec 03 wording at the next MINOR step; the per-block vote bound re-run of O-3.3 with pool-aggregated carriage in the model	3
O-9.4	Mode A item 5 needs a node RPC that validates a block as a template without submitting it; none is named	Add the RPC to the fork (candidate: validateBlockTemplate), with the cost per call measured at the design document's gas budgets	2
O-9.5	Every timing here is Designed: template size and bandwidth per member at 1 BPS, the member's check cost (9.4.1), declare_timeout_ms, share_interval_s, the pool's verification throughput on a server core	A reference pool with 100 members on the phase 4 devnet: record template bytes per second per member, check time per template on a 2019-class laptop core, declared-template acceptance latency, shares verified per second per core on a server CPU; set the four parameters from the distributions	4
O-9.6	The carriage ratio of 9.7 item 6 has no threshold, and its 60-block window is a guess	On the same devnet, one pool conforming and one dropping every vote: record both ratios per key over a day; set the warning threshold at the point that separates them with no false warnings on the conforming pool	4
O-9.7	The TLS exporter binding in authorize is named and not specified (which exporter label, which bytes are signed)	Write the exact bytes at the first implementation; test that a replayed authorize on a second connection is refused	4
O-9.8	A member with only the light client of section 10 as its verifier checks headers against a checkpoint chain, not against a full node's tip, so item 4 of 9.4.1 (parents are known tips) is weaker for it: it can confirm the parents descend from the last certified checkpoint and no more	Decide at gate 4 whether a light-client member may vote (9.7 item 2 says yes) after the eclipse test of O-3.7 is re-run with light-client members in the model	3, with 4
O-9.9	HiveOS and the rental markets need this protocol to list the algorithm (ledger entry on rental, "cannot list an algorithm whose kernel changes hourly without a stratum for it")	The reference member runs under HiveOS against the reference pool through 24 epoch changes with in-worker compilation (R3.15's acceptance test: outage under 2 s per change)	4