imd-beacon specification, version 1

Status: proposed implementation contract; testnet first. Research checked 26 October 2026 (Asia/Bangkok). This document replaces the draft in PLAN.md, read from the repository's main branch before research. The canonical specification is docs/SPEC.md; artifacts/report.md is an identical delivery copy. No beacon implementation, deployment, security audit, or measured imd-beacon gas result is claimed here.

Decision: use unchained threshold BLS on BLS12-381, signatures in G1, public keys in G2; Ethereum is the membership and ceremony authority; all three target chains verify signatures directly. Recommend N = 256 seats, t = 129 shares, 30-second rounds and 24-hour epochs. A separate, explicitly insecure-for-value pilot may use 64/33. Retain the group key through verified resharing. Do not promise permissionless recovery after loss of a threshold or recovery of secrecy after group-secret compromise.

Unless labelled Evidence, Inference, Unverified, or Open, MUST/SHOULD and parameter choices below are proposed protocol requirements, rather than descriptions of an existing implementation. External claims have adjacent links. Mathematical results are derived here, with an offline reproduction script. A test exercises a property; it does not prove a cryptographic assumption.

1. Requirements

Let f be the number of adversarial shares in the active committee and o additional unavailable honest shares. Let T(r) be the scheduled release time. The model assumes correctly generated shares, an uncompromised group secret, authenticated communication, bounded clock error, eventual message/transaction delivery, canonical finalized Ethereum state, and honest erasure at handover. Its cryptographic foundation is the threshold-BLS construction, not a claim of unconditional randomness; see drand's cryptography description and the Galindo–Liu–Ordean–Wong analysis.

ID	Testable requirement and condition	Required observation
R1 Unpredictability	With f < t, honest nodes release no round partial before T(r) (use a one-second clock-error guard); no honest node signs arbitrary consumer input. Prediction resistance assumes the threshold-BLS hardness and random-oracle assumptions, including the DKG qualifications in §6.	TestNoEarlyPartials, fake-clock boundary tests, and cross-language vectors; the threat model explicitly excludes an adversary that already collected t valid partials. A statistical randomness test is not a security proof.
R2 Unbiasability	For fixed network, group key and round, every valid t-subset produces the same canonical signature and value. No retries, subset choices, relayer address, transaction hash, or blockhash enter the output.	Exhaust all t-subsets for 4/3 and 7/4 fixtures; sample 10,000 subsets at production size. Invalid/duplicate partials cannot affect reconstruction. Withholding can delay availability; it cannot supply a different valid value.
R3 Public verifiability	Anyone with the immutable network descriptor and a signature verifies the exact message and derives exactly the stored 32 bytes, without a trusted API or privileged relayer.	Go, independent BLS library, and Solidity agree on positive and adversarial vectors. All malformed encodings, infinity keys/signatures and wrong domains fail.
R4 Liveness	After network synchrony returns, if N-f-o >= t, t valid partials reach an honest aggregator; a funded or volunteer relayer with chain access can publish. Normal-operation target: 99% of rounds aggregate within 10 seconds after T(r), with end-to-end one-way delay ≤1 second and clock error ≤1 second.	A virtual-clock 24-hour simulation meets that target. With f+o <=127 at 256/129, rounds continue; at 128 withheld shares they may stall. Chain inclusion/finality is separately measured, never covered by the 10-second target. Ceremony availability is a separate requirement (§6).
R5 Open seat membership	Any eligible seat owner can register without an administrator's whitelist. One NFT token id gives at most one epoch slot and one sampling ticket, regardless of registrations, agents or keys.	Ownership, agent binding, PoP and duplicate-seat tests; only publicly specified eligibility rules reject registration. Multiple seats owned by one operator remain multiple tickets.
R6 EVM verification	Ethereum (1), Base (8453) and Robinhood Chain (4663) directly verify the same BLS proof and store the same beacon value.	Offline vectors plus a deployment compatibility probe on each actual target. Receipt gas ≤250,000 for ordinary single-round publication under the specified profile, excluding L1 data/operator fees and optional rewards. Missing precompiles cause deployment to fail.
R7 Epoch integrity	Registry snapshots precede sampling; a finalized handover preserves the group key and activates once, at an epoch boundary. Transfers cannot create two shares for the same seat in one epoch.	Snapshot mutation, fork, reorg, transfer and two-handover adversarial tests.
R8 Consumer safety	A request permanently binds its stakes, eligibility, consumer, target network and future round before honest release.	The demo rejects late entries, redraws, changed targets, post-request odds changes and replayed fulfillment; it never substitutes another round after a delay.

Limits: operator independence is not inferable from NFTs or agent registration. A running worker cannot be cryptographically established merely by registering a key. Basic threshold BLS also does not promise fairness of delivery: an aggregator may learn a value shortly before others. These are design limits; R1 is not a promise to conceal an output from someone who has already received enough honest partials. The difference between standard and strong distributed-VRF pseudorandomness is explicit in Galindo et al..

2. Prior art, with citations

The following comparisons separate documented constructions from the adoption decisions for imd-beacon. Product names alone establish neither decentralization nor audit coverage.

System	Evidence: construction and trust	Failure modes / limits	imd-beacon decision
drand / League of Entropy	A threshold network generates BLS beacons. In chained mode the previous signature is part of the next message; unchained mode signs an independently determined round message. The deployed network list distinguishes default, quicknet and evmnet. Protocol spec, network guide.	Fewer than t colluding members cannot generate a round alone; fewer than t available members cannot finish it. Membership in the League is not a seat-open registry. Its security documentation discusses coordinator TOFU and a reliable-broadcast assumption that the described implementation does not fully realize. Security model.	Copy unique threshold signatures, partial verification, published descriptors and resharing. Replace trusted group formation with finalized registry snapshots and an ordered ceremony board. Do not treat gossip as consensus or assume a coordinator is honest.
drand quicknet	Unchained, 3-second beacon; signatures on BLS12-381 G1 with an RFC-9380-compatible scheme. Launch announcement, client verification code.	There is no dependency on a previous output to verify one round, but t compromised shares still reveal scheduled future outputs. It needs BLS12 precompiles for economical direct EVM verification.	Copy unchained rounds and the standard G1 hash suite. Use a distinct imd message/network domain; this is not wire-compatible drand randomness. Choose a slower initial period to allow broader worker participation.
drand evmnet	Uses unchained BN254, G1 signatures and G2 public keys. The client uses Keccak-256 and the SVDW BN254 suite. Network guide, client source.	Broad legacy EVM compatibility comes with a weaker security margin than BLS12-381; “254” is not 128-bit pairing security. The Kyber BN254 warning withdraws the old 128-bit claim.	Keep evmnet vectors as a comparison harness, not a second accepted signature mode. Choose BLS12 because target support is now evidenced (§4). Avoid mixed curves or silent fallback under one network id.
Pyth Entropy	Two-party protocol with a provider precommitting a hash chain; the user contribution and provider reveal determine a request's output. The documented provider assumptions include reveal availability, no front-running and keeping the hash chain secret. Protocol design.	A provider can see the result and withhold. Transaction ordering, provider commitment changes and reorgs matter; a two-party honest contribution condition does not remove provider availability trust.	Copy explicit request/fulfillment binding and confirmations. Avoid one indispensable reveal provider and outcome-dependent replacement requests.
Chainlink VRF	A request obtains random words with an on-chain verified proof; the coordinator workflow waits request confirmations before fulfillment. Overview, direct-funding flow. This is a request-oriented oracle workflow, not an IMD committee beacon.	A proof establishes correctness, not delivery by an unwilling key holder. Its own guidance warns about reordering, reorgs, cancellation, re-requesting and accepting inputs after a request. Security considerations.	Copy immutable request ids, sufficient finality lead and no redraw. Avoid equating proof validity with censorship resistance. The brief's “paid in LINK” comparison is incomplete: v2.5 supports native payment as well as LINK. v2.5 migration.
RANDAO / PREVRANDAO	Ethereum mixes proposer RANDAO contributions; EIP-4399 describes a proposer withholding a block to influence the mix and transaction censorship shifting the value used by an application. EIP-4399.	Last-revealer/proposer withholding supplies a choice at an opportunity cost. Future lookahead helps applications but does not transform the mechanism into a unique threshold output.	Copy the discipline of choosing a future event. Do not use PREVRANDAO as the epoch seed fallback, bootstrap entropy or timeout output; no proposer-selectable branch should be added to imd randomness.
Supra dVRF	Supra describes GLOW-based threshold BLS, t-of-N generation, and proofs for partial evaluations; its notation uses T+1 where this document uses t. Requests also involve application input and chain information. Architecture, overview, service paper.	Robustness requires enough correct reachable participants; chain inclusion, subscriptions and callback execution remain separate trust/availability surfaces. Production parameter choices and deployed-version audit coverage were not independently established in this research.	Copy verification of partial contributions and explicit threshold accounting. Do not claim Supra's strong pseudorandomness theorem for ordinary BLS partial verification: its GLOW proof layer is a substantive difference. Do not add that layer without a separate reviewed specification.
Internet Computer / DFINITY threshold beacon	The consensus paper describes a chain of unique threshold-BLS signatures, distinct from ordinary multisignatures and threshold authorization. PODC 2022 paper.	Its system model is a consensus protocol with its own membership and scheduling, rather than an external open-seat EVM beacon. Chained dependencies can stop progress after a missing predecessor.	Copy the distinction between a unique threshold signature and a signer-list-dependent aggregate. Avoid importing IC thresholds or membership assumptions without their consensus model.
Robinhood OpenVRF integration	Robinhood-OSS documents an EVM request router backed by existing drand evmnet, with future-round binding and separately stated timestamp/application fairness assumptions. Repository.	It consumes an existing committee; it does not establish open-seat DKG. Its source and example deployment are not an audit of imd-beacon.	Copy a locally reproducible proof-to-consumer check and permanent round binding. Do not mistake a working consumer integration for a solution to dynamic membership.

Source disagreement / scope: drand's overview uses simplified threshold-security language; its security-model page qualifies DKG assumptions and broadcast realization. Supra and Galindo et al. distinguish stronger pseudorandomness from ordinary threshold BLS. This specification claims scheduled-beacon unpredictability under its stated release discipline, not an unrestricted, strongly pseudorandom DVRF with adversarial challenge-partial queries. The brief's “BN254 precompiles on every EVM” is too broad; support is a property of a particular chain and fork, not the EVM label. drand security model, Galindo et al., ArbOS 40 exception.

3. Threat model

The normal-operation bound is f<t and f+o<=N-t; ceremony completion additionally needs at least t valid dealers and t qualified responsive recipients, and finalized bulletin-board delivery within its phase deadlines. Sampling assumes an adversary commits its seat/key positions before learning the designated seed. Instant adaptive corruption after selection invalidates the sampling probabilities.

Adversary/event	Required protocol behaviour
Colluding seat holders	Reject invalid partials and reconstruct the unique signature from any t valid ones. If colluders withhold but t honest available shares remain, continue. If t shares collude, prediction and withholding resistance are lost; uniqueness survives for the fixed key/message. Do not describe this as “still secure.” Stop accepting new value-bearing application requests when compromise is established.
One operator holding many seats	Count every controlled seat in the adversarial share A/M. Key, agent-id, IP and wallet diversity are not evidence of independent control. No unenforceable one-human rule; publish observed concentration and upper-bound scenarios. Seat acquisition is not a slashable offense.
Offline members, partitions and DoS	Exclude unavailable contributions, not the scheduled round. Catch up the same round after recovery. If fewer than t remain, report a stall. Never lower t, change the target seed round, replace an elected member mid-epoch, or hash the available subset into a fallback value.
Malicious relayer / aggregator	Everyone verifies partials; anyone can aggregate or relay. A relayer cannot change M, signature encoding or R. Invalid submissions revert; duplicates do not pay twice. Censorship delays chain availability but cannot select another result. A chain-wide inclusion failure remains an availability failure.
Grinding consumers / builders	Freeze all outcome-sensitive inputs and stakes before the future target; bind each request permanently. Reject alternate-round settlement and late bets. Application-specific expansion includes chain, consumer and request id. Repeated paid independent games remain possible; the beacon cannot make an application that lets users discard losses fair.
Chain reorgs	Use finalized Ethereum state for sampling, DKG and handover. A nonfinal round relay may disappear and be resubmitted with the same signature. Consumer commitments must finalize before the selected release under their chain's finality policy. A finalized-history violation is outside the model: nodes fail closed on conflicting finalized roots and require a new explicitly reviewed network if recovery is necessary.
Key compromise / accumulated old shares	Count compromised shares within each sharing generation, including offline copies and backups. Honest nodes erase superseded shares after finalized activation; do not restore them from snapshots. If t shares from any single historical generation are retained by an adversary, it can reconstruct the persistent secret and sign all future epoch messages. Resharing cannot repair this. Announce compromise, freeze new commitments and bootstrap a new group key/network; unresolved old requests must never migrate to its randomness.
Seat NFT transfer mid-epoch	The old snapshot owner/operator retains the current epoch's duty and reward address. The buyer gains no current share and must register for a later snapshot. A transfer freezes future eligibility of the old registration, once observed at finality; it cannot revoke a cryptographic share. Buyers must be told that seats carry delayed participation, not transfer of secret keys.
ERC-8004 identity transfer, operator or key change	Apply the same snapshot rule. Agent control and seat ownership are checked at registration and snapshot; changes are future-effective. A new key needs a new PoP, authorization and registration nonce.
Malicious DKG dealer / equivocation	Order public packets on the canonical ceremony board, verify encrypted shares and commitments, resolve complaints, and exclude invalid dealers according to §6. A coordinator has no power to choose QUAL, retry seed, set the group key or shorten a deadline.
Clock manipulation / early signing	Nodes use monotonic scheduling anchored to UTC and refuse operation if trusted-clock disagreement exceeds one second. Do not sign future rounds merely because a peer requests them. Contract timestamps cannot prove a node did not sign early; this remains an honest-node assumption.
Malicious treasury / governance	Funding withdrawal can stop paid service, not alter a verified value. v1 verifier/configuration are immutable, with no administrative randomness or group-key setter after genesis. Changes require a new network and explicit consumer opt-in. Emergency action may stop new commitments; it cannot supply replacement outcomes.

Inference from retained-key algebra: including epoch in M separates messages but does not cryptographically revoke an old threshold. Whoever knows x can compute x·H(M) for every epoch. Therefore “old partials fail under new share public keys” must never be confused with revocation of old full signing capability. This follows from the BLS construction; honest erasure is an operational assumption, not an on-chain fact.

4. Cryptographic design

4.1 Curve choice and chain evidence

Use BLS12-381, scalar field order as specified by the selected BLS library, signatures in the prime-order G1 subgroup, group key and verification shares in G2. It offers the stronger margin; EIP-2537 motivates 120+ bits versus an approximately 80-bit characterization of BN254. Those are the EIP authors' estimates, not a new security evaluation or a promise of an exact modern attack cost. EIP-2537. BN254 remains a viable compatibility alternative for a new, separately reviewed network, not v1's fallback.

Target	BN254 evidence	BLS12-381 evidence	Deployment rule
Ethereum, id 1	EIP-196/197 define 0x06–0x08; EIP-1108 reprices them. EIP-196, EIP-197, EIP-1108.	Pectra activated 7 May 2025, including EIP-2537. Ethereum roadmap. Read-only probes also pass (§4.2).	Require all seven BLS precompiles and positive/negative pairing vectors.
Base, id 8453	Successful BN add, mul and true/false pairing probes; do not infer from “L2.”	OP Stack Isthmus specifies EIP-2537; Base's derivation documentation describes Isthmus payloads. All seven precompile probes pass on Base. OP execution spec, Base derivation.	Recheck current chain and corresponding testnet; do not inherit the Ethereum fork label blindly.
Robinhood Chain, id 4663	Official integration uses BN254 evmnet; add, mul and both pairing outcomes pass. OpenVRF. Official mainnet/testnet ids are 4663/46630. Deployment docs.	Current Robinhood node docs state ArbOS 61. ArbOS 51 enabled EIP-2537; ArbOS 40 explicitly did not. All seven probes pass on the official 4663 RPC. Robinhood node docs, ArbOS 51, ArbOS 40.	This establishes current support, not support on every Nitro fork or 46630. Probe the actual deployment network and pin its chain id.

Unverified: testnet precompiles, future upgrade schedules, complete client conformance, and actual imd-beacon contract gas on all three chains. The RPC observations support the design choice; they do not independently establish consensus correctness. No production deployment is authorized merely by this report.

4.2 Reproducible observations

chain-probes.json records requests and responses from read-only JSON-RPC calls to public endpoints. It contains no credentials. Each chain returned (1,2) for BN254 add with infinity and multiplication by one; two cancelling generator pairings returned 1, one generator pairing returned 0. All seven BLS addresses 0x0b–0x11 returned correctly sized outputs: G1/G2 add with infinity and MSM by one match their EIP generators; cancelling/noncancelling pairings return 1/0; zero-input maps produce the same points on all three chains. EIP-2537 generators and encoding.

Recorded initial latest block anchors: Ethereum 0x190e03b, Base 0x329fe2d, Robinhood 0x5d4c77c; full hashes are in the JSON. Calls used latest, so these anchors are context rather than a claim that every call executed at that exact block. One provider per chain was queried. An earlier finalized-state attempt on Robinhood returned “historical state ... is not available”; latest-state calls succeeded. Archived-state support is not required by the precompile itself. The delivered probe script defaults to offline evidence checking; explicit --live refreshes read-only evidence. Deployment acceptance additionally requires malformed inputs, non-subgroup inputs and two independent RPC views at a pinned block.

4.3 Message, suite and encodings

Freeze a genesis descriptor before the bootstrap seed becomes available. Define:

configHash = keccak256(abi.encode(
    uint32(1), uint256(1), registryAddress, seatNFTAddress, agentRegistryAddress,
    uint16(N), uint16(t), uint32(30), uint32(2880), uint64(T0),
    bootstrapSourceChainHash, uint64(bootstrapSourceRound), uint64(registrationCutoff)
))
networkId = keccak256(ASCII("IMD_BEACON_NETWORK_V1") || configHash)
T(r) = T0 + 30 * (r - 1)                 // r starts at 1
E(r) = floor((r - 1) / 2880)             // e starts at 0
M(r) = ASCII("IMD_BEACON_ROUND_V1") || networkId || U64BE(E(r)) || U64BE(r)

All integers in abi.encode occupy normal 32-byte ABI words; addresses are ABI addresses. In the final concatenation networkId is 32 bytes and each U64BE is exactly eight big-endian bytes. Reject r=0, overflow, epoch mismatch and wrong network. No previous signature, consumer input or receiving-chain id is included in M. The same beacon is intentionally usable cross-chain. Application derivation (§8) provides chain/consumer separation.

Use RFC 9380 BLS12381G1_XMD:SHA-256_SSWU_RO_: expand_message_xmd SHA-256, two field elements, simplified SWU with the specified isogeny and cofactor clearing. Use BLS basic-signature DST BLS_SIG_BLS12381G1_XMD:SHA-256_SSWU_RO_NUL_. Hash M directly, with no additional prehash. The RFC defines the hash suite; the separately versioned BLS Internet-Draft defines signature domains and validation and is not an RFC. RFC 9380 §8.8.1, BLS draft -06.

Do not implement H(M) = hash(M)·G1: that exposes a known discrete-log relation and is not the required hash-to-curve construction. On-chain compute hash-to-field/XMD, use the EIP-2537 field-to-G1 mapping twice and add the results according to the RFC/EIP mapping interface; the EIP maps field elements, not arbitrary strings. Match RFC and independent library vectors before integration. RFC 9380 algorithms, EIP-2537 mapping specification.

For share s_i at evaluation point i+1, verify e(sigma_i,G2)=e(H(M),P_i). For a distinct set S of at least t valid shares:

lambda_i = product(j in S, j != i) ((j+1) / ((j+1)-(i+1))) mod scalar_order
sigma = sum(i in S) lambda_i * sigma_i
verify e(sigma, G2) * e(-H(M), PK) == 1
R(r) = SHA256(serializeG1Compressed(sigma))

Use standard 48-byte compressed BLS12-381 G1 encoding for the only output hash input. The node wire form is compressed. The EVM submit form is 96 bytes, x || y, each a canonical 48-byte big-endian base-field integer, no flags; the verifier validates and reconstructs the unique standard compressed 48-byte representation internally. Precompile inputs instead require each coordinate padded to 64 bytes. Public keys use standard 96-byte compressed G2 for descriptor/wire; registration and contract storage can use canonical affine coordinates with the explicit EIP coefficient order. Encoding adapters must have fixtures for every direction. BLS serialization/validation, EIP-2537 encoding.

Reject infinity, noncanonical fields, wrong lengths, points outside the curve/subgroup, wrong G2 coefficient order and unexpected extra bytes before hashing. Pairing/MSM precompiles check subgroups; ADD alone does not establish subgroup membership. Pin and validate PK at genesis. Require successful STATICCALL, exact return length and the expected return value; a successful call to a nonexistent account with empty returndata is failure. EIP-2537 subgroup/error rules.

4.4 Gas estimates and limits

These are estimates for one proof, not measurements of an implementation that does not yet exist.

Path	Arithmetic component	Estimated total / acceptance budget
BN254 comparison	Two-pair check 45,000 + 2*34,000 = 113,000; ECADD 150, ECMUL 6,000 if needed. EIP-1108.	drand reports 158,250 verification execution gas and 159,274 including its 64-byte signature calldata accounting. This does not include our storage/transaction overhead. drand benchmark.
BLS12 chosen	Two-pair check 37,700 + 2*32,600 = 102,900; two G1 maps 2*5,500, G1 add 375: 114,275 arithmetic gas, before XMD, memory and calls. EIP-2537 gas schedule.	Published uncompressed verifier comparison: 130,028 execution gas; compressed: 139,812. Our estimate: 135k–160k verify-only, 210k–250k full first-write receipt, including 21k base transaction, calldata, one value slot, one paid/availability flag slot, event and fee credit. Target ≤170k verify-only, ≤250k publication. drand benchmark.
Ethereum / Base / Robinhood	Same nominal EIP arithmetic schedule is the starting assumption.	Use the 250k execution budget on each EVM profile. Base and Robinhood charge additional data and/or chain-specific fees: no USD or total-fee parity claim. Base fees, Robinhood gas.

The published library is expressly unaudited; its numbers are a benchmark reference, not evidence that adopting its code is safe. bls-solidity README. Failed-input calls have bounded supplied gas; acceptance requires an explicit gas report for the pinned compiler, optimizer, EVM fork and deployed clients. Repricing requires revising budgets before deployment, not suppressing a failing check. Rewards and ceremony gas are outside the constant-size per-round proof budget.

5. Committee and threshold

5.1 Quantified sampling risk

Sample N distinct eligible seat token ids, uniformly without replacement. If there are M eligible seats, A adversarial, and X adversarial seats drawn:

Pr[X = k] = C(A,k) C(M-A,N-k) / C(M,N)
Pr[adversary can sign alone] = Pr[X >= t]
Pr[adversary can block alone by withholding] = Pr[X >= N-t+1]

The blocking expression assumes every nonadversarial selected seat is online. With o additional unavailable honest members, replace its cutoff by N-t-o+1. Failed DKG/resharing and adaptive compromise are additional risks, not covered by this calculation. For a large population approximation, X ~ Binomial(N,p) and the tail is sum(k=c..N) C(N,k)p^k(1-p)^(N-k). The numbers below are our calculations, not external security claims. “33%” means exactly 0.33, not 1/3. Here p=A/M is the share of eligible registered seats in the sampling pool, not the share of all minted NFTs: unregistered honest holders do not dilute an attacker. No population size or independent-operator count was supplied, so the exact finite-population probability must be calculated from the actual snapshot before deployment.

N / t	Adversarial seat share p	Pr[X ≥ t], prediction capability	Pr[X ≥ N−t+1], blocking capability
64 / 43, brief's draft	10%	4.74887e−28	1.20207e−7
64 / 43	20%	3.78227e−16	0.00508557
64 / 43	33%	2.35145e−8	0.453869
64 / 43	40%	1.00963e−5	0.852485
64 / 33, pilot only	10%	7.53862e−17	7.04651e−16
64 / 33	20%	1.94850e−8	8.18460e−8
64 / 33	33%	0.00163530	0.00358476
64 / 33	40%	0.0402381	0.0671431
128 / 65, intermediate comparison	10%	3.45444e−31	3.16933e−30
128 / 65	20%	8.94045e−15	3.66740e−14
128 / 65	33%	2.42823e−5	5.13845e−5
128 / 65	40%	0.00868040	0.0138427
256 / 129, recommended	10%	9.91509e−60	9.01043e−59
256 / 129	20%	2.53464e−27	1.02691e−26
256 / 129	33%	6.87202e−9	1.42584e−8
256 / 129	40%	0.000485894	0.000753881

Recommendation and inference: use 256/129 when at least 256 eligible seats exist; do not silently shrink N or t. A majority threshold nearly balances signing and withholding risks for a standalone signature beacon. A 2/3 threshold is not required by the uniqueness equation and spends availability to increase capture resistance. At p=0.33, 256/129 tolerates up to 127 missing/adversarial signers and makes the large-population one-epoch capture tail about 6.87e−9. At p=0.40 its lifetime risk is unacceptable for high-value use: 365 daily committees give a capture union bound of 0.17735, or approximately 16.26% assuming independent samples. At p=0.33 the corresponding union bound is 2.5083e−6. Independence is not needed for the union bound, and generally does not hold exactly across overlapping or changing populations. A past capture permanently compromises a retained group key.

For comparison, 512/257 lowers the p=0.40 capture/block tails to 1.93428e−6 / 2.95411e−6 per epoch, at four times the all-to-all DKG pair count of 256. The default does not claim safe lifetime operation at 40%. Mainnet authorization needs a reviewed concentration/value-at-risk assessment, not just the table. Development first implements 16–64-node tests; 256-node completion is an acceptance gate before production-size testnet claims. If the seat supply is smaller, run a separate pilot network with 64/33 and no valuable consumer funds.

committee_risk.py uses exact rational binomial and hypergeometric arithmetic, supports actual M/A inputs and reproduces these tables offline. Bounds concern adversarial seats, not independent Bernoulli failures of individual operators. Whole-operator outages may be highly correlated.

5.2 Sampling, seed and schedule

Every epoch is 2,880 rounds, exactly 86,400 seconds. start(e)=T0+e*86400. During epoch e prepare e+1:

1. Snapshot the registration state and actual seat/agent ownership at the finalized Ethereum block B_e: the last block with timestamp < start(e). Canonical header/state proof handling is specified in §7. Its eligibility root must be finalized before the designated seed releases. Eligibility is frozen even if the later ceremony fails.
2. The seed round is fixed in advance: r_seed(e+1)=e*2880+121, released one hour after start(e). This is an output from the previous epoch relative to the elected committee, not an administrator's choice of the most recent convenient output. Seed must be verified under the retained group key. If the snapshot did not finalize before release, this transition fails; never choose a later round.
3. Define seed=keccak256(ASCII("IMD_BEACON_SAMPLE_V1") || networkId || U64BE(e+1) || snapshotRoot || R(r_seed)). The root is immutable before R is known. Sort eligible seats by unsigned token id, assigning ranks 0..M−1.
4. Run partial Fisher–Yates for positions k=0..N−1. Generate successive 256-bit words keccak256(seed || U64BE(counter)), counter initially zero, incremented for every draw including rejected draws. For range m=M−k accept w only if w < 2^256-(2^256 mod m); choose j=k+(w mod m) and swap entries k,j. Implement the cutoff with arbitrary precision or equivalent overflow-safe arithmetic, including the m=1 case. This avoids modulo bias. The first N positions are the ordered committee; evaluation point is position+1. Test vectors must freeze swaps, byte encodings, counters and rejection behaviour.
5. Sampling is public and permissionless. An on-chain paginated verifier checks Merkle rank proofs and the sparse swap map; any invalid chunk reverts without changing prior valid chunks. No selected seat may decline and trigger an alternate draw. Absent seats consume the fault budget. If M<N, publish InsufficientSeats and do not start the new epoch.

These are original protocol choices; uniformity follows from rejection sampling and Fisher–Yates, assuming pseudorandom independent hash draws. A standard description of the underlying shuffle is NIST's Fisher–Yates entry. Require exhaustive small-array tests and forced-rejection fixtures rather than relying only on statistical tests.

5.3 Bootstrap and seed withholding

For epoch 0 use drand quicknet as the external bootstrap source only. Pin its descriptor/public key and chain hash 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971; this hash identifies a network, not a random seed. A bootstrap manifest fixes the membership cutoff D, a specific future quicknet round whose release is at least D+1 hour, and T0 at least D+24 hours. Verify that round with quicknet's own message/suite and derive its documented randomness, then apply the §5.2 sampler with destination epoch 0. drand network descriptors, quicknet client message verification.

Publish/finalize the immutable manifest and eligibility root before the source round releases. No deployer-chosen random bytes, private seed, blockhash, zero address, guessed source round or initial dealer secret is permitted. Actual registry/treasury addresses, source round and start date are deployment inputs with validation; none are invented in this report. Genesis activation requires the DKG certificate in §6, not a deployer's supplied PK.

If the source round is unavailable, wait for that round and postpone service; a failed bootstrap must not expose a choice among DKG keys or seed rounds. T0 may only be changed by abandoning the entire unused network descriptor and publicly recording failure; it cannot affect existing requests. Once active, there is no fallback to drand if imd-beacon stalls. With enough honest available members, unique signatures remove the old committee's seed-selection freedom; without enough members, selective stopping is possible and is reported as a stall, not hidden through reseeding.

6. Key setup and handover

6.1 Chosen protocol and assumptions

Use drand/Kyber's complaint-based Pedersen / joint-Feldman DKG and its verified resharing implementation, with a BLS12-381 G2 group adapter and explicit threshold settings. Do not write a new DKG from an informal paragraph. The source has deal, response, justification and finish phases, explicit old/new thresholds, session nonces and old-share/public-commitment checks. Pinned Kyber DKG source. Its algebra is summarized below to define interoperability and acceptance, not to replace the library.

Evidence / qualification: joint-Feldman/Pedersen DKG may bias the distribution of the setup key. drand's documentation describes that weakness and qualifies the applicability of some signature-security arguments to threshold BLS. It is not a proof that a uniform key results. drand DKG security discussion. This design prevents outcome-driven retries and retains the key, but must receive external cryptography review of the exact DKG, hash suite, release model and resharing before valuable use. If that review requires a stronger DKG, change this specification and its vectors before implementation proceeds to mainnet. This is a concrete review gate, not permission to substitute an uncited algorithm.

Reliable public broadcast is provided by an Ethereum ceremony bulletin board, not by the partial-signature gossip mesh. Each public packet includes network, destination epoch, attempt number, phase, sender index and payload. Its session nonce is keccak256(ASCII("IMD_BEACON_DKG_V1") || networkId || U64BE(destinationEpoch) || U32BE(attempt) || oldCommitteeRoot || newCommitteeRoot); genesis uses an explicitly typed absence of an old committee rather than an address stand-in. Authenticated library packet signatures cover this nonce. Use the registered individual key with the standard POP-scheme signature DST for these authentication signatures; use canonical library packet encoding with the session nonce inside the authenticated payload. The round-signature DST remains the distinct NUL suite in §4. Canonical public packets and encrypted-deal payloads are published as bounded event chunks on DkgBoard; nodes consume finalized complete payloads in board order. Merely posting a hash of unavailable data is insufficient. Ethereum finality/availability substitutes a chain assumption for a trusted coordinator.

Use the library's ECIES encoding/encryption for private deals, with the registered long-term key and independent ephemeral encryption randomness; private scalars must never appear on-chain except protocol-required complaint justifications. The security test suite checks message replay, tampering and confidentiality boundaries. The board authenticates registered senders, limits a sender's phase payload, stores content hashes/phase state, and emits the data; it need not implement DKG field arithmetic in Solidity. Offline reconstruction must reproduce the transcript byte for byte. Kyber ECIES implementation.

6.2 Phases and fixed deadlines

For genesis, use the same phase windows starting at D+2 hours, after bootstrap-seed verification; retry at D+8 hours if needed, with completion before T0. Begin the first attempt at start(e)+2 hours when preparing e+1; the seed and snapshot must already be finalized. All deadlines are fixed Ethereum timestamps; clients must have seen each phase's complete finalized board prefix before progressing. No timeout is justified by the workstation or test wall clock: tests advance a virtual clock.

Phase	Window after session start	Required processing
Deals	[0h,1h)	Each dealer commits a degree t−1 polynomial with G2 coefficient commitments and sends one encrypted evaluation to each recipient. Genesis uses random constant coefficients from the OS CSPRNG; resharing constants are bound to old shares. Missing/incomplete deals at the cutoff cannot later enter QUAL.
Responses	[1h,2h)	Recipients verify decrypted evaluations against the published polynomial; publish signed complete success/complaint bundles (FastSync=true). Missing/decryption-failed/inconsistent shares trigger complaints. All recipients see the same finalized response set.
Justifications	[2h,3h)	Dealers answer complaints with the required evaluations, verified against commitments. Do not reveal t evaluations of one degree t−1 dealer polynomial: ≥t complaints disqualifies that dealer before public reconstruction.
Finalize / readiness	[3h,4h)	Compute deterministic QUAL, group public polynomial and each eligible recipient's share. Publish transcript hash, public coefficient data, qualified index bitmap and verification-share root. Collect at least t new-member authorization votes attesting local verification and successful share possession; also t old-member votes for resharing.
Finality margin	[4h,5h)	Finalization certificate and board prefix must finalize on Ethereum. Late or inconsistent certificates fail this attempt. Active rounds continue under the old sharing until the boundary.

Under the bounded network/chain model all messages submitted early enough within their windows finalize before the next dependent phase. Ethereum may stall longer than a window; this deliberately produces ceremony failure, not disagreement on a locally shifted deadline. Require at least 15 minutes inclusion/finality margin in submission policy, and record phase-finality violations. A future cheaper reliable-broadcast mechanism needs its own specification and review; gossip proximity is not a substitute.

6.3 Complaints, qualification and failure

For a valid deal, recipient i checks share_i·G2 = sum(k=0..t−1) (i+1)^k C_k. Authenticated malformed or conflicting phase packets, wrong session/index, missing required bundles, invalid commitments, invalid/missing justifications, or t-or-more distinct complaints cause the appropriate dealer/holder exclusion under the pinned library rules. A valid justification resolves the complaint: a complaint alone is not proof of fault and creates no slash. Repeated unsigned or invalid-auth complaints are ignored/rate-limited and never count against a dealer. Board duplicates with identical bytes are idempotent; distinct payloads for the same authenticated sender/phase are recorded as equivocation, excluding that sender. Crypto checks and exclusions are recomputed by every honest member from the same complete transcript.

Use the library's exact indexing convention (PriShare.I zero-based, polynomial evaluation I+1). In a fresh DKG, sum qualified dealer polynomials/commitments; each member receives only its summed evaluation, and PK is the constant public commitment. Require a nonzero key, at least t valid dealer contributions, at least t qualified new recipients, and valid local shares. In both DKG and resharing, keep configured t even if QUAL shrinks; unqualified positions are holes, not new tickets or renumbered points. Never reconstruct x to test success.

A readiness certificate is not just a threshold signature under a candidate key: a dealer can choose a key it knows. It contains t distinct eligible new-member authorizations over the exact transcript, PK, public-share root, threshold and activation round; each honest voter must have fully validated the transcript and its own share before authorizing. For handover it additionally needs t distinct old-member authorizations over the same certificate. Votes use registered operator EIP-712 authorizations with EIP-1271 support and are permissionlessly relayable; registry checks slot uniqueness and the frozen operator for that epoch. Contracts rely on at least one honest verifier among these t authorized voters, under f<t, to attest to the off-chain DKG computation. They do not claim to verify the full DKG arithmetic from a Merkle root. EIP-712, EIP-1271.

Permit one retry with a fresh session nonce, the same frozen elected roster and seed, at start(e)+8 hours; exclude already-proven equivocators but do not replace them or lower t. Keep both transcripts public. Accept the first successfully finalized attempt; never choose between successful candidate keys. Genesis must not run a second successful DKG to select a preferable key. Any attempted transcript exposed by a failed attempt is not reused in another attempt. Persistent selection/ceremony DoS is an explicit remaining availability attack; no penalty or retry proves it impossible.

If both attempts fail, do not activate the target epoch or invent an output for it. The old committee may answer its own historical rounds; it does not acquire an indefinite successor term. New consumer commitments pause at the boundary. A delayed resumption may complete the same target roster's resharing using a new documented attempt nonce and fresh ephemeral randomness once the fault is resolved; it cannot switch to a newly sampled roster or use different entropy for outstanding requests. Existing consumers either await the same round or apply the predetermined neutral refund policy (§8). If t old shares are permanently unavailable, retained-key recovery is impossible: declare the network stopped and bootstrap a distinct network for new consumers only.

6.4 Verified resharing and activation

Keep the group PK fixed, while changing its polynomial and holders. In the chosen library, each qualified old dealer j shares a new degree t_new−1 polynomial whose constant commitment must equal the old public evaluation P_old,j. For a qualified old set S with at least t_old dealers, new shares and public polynomial coefficients are interpolated using old evaluation points and their Lagrange coefficients. Thus newPK = sum(j in S) lambda_j P_old,j = oldPK. Verify every constant commitment against the old certified polynomial and every received evaluation against its dealer's new polynomial; reject even an otherwise well-formed fresh key. Always set OldThreshold explicitly: the source identifies omission as a downgrade risk. Kyber resharing checks and reconstruction.

Evidence: verifiable redistribution literature identifies vulnerabilities in naive redistribution and requires checks tying new shares to the old secret. Do not implement only the informal Desmedt–Jajodia sketch cited by older drand documentation. Wong–Wang–Wing, Verifiable Secret Redistribution. Cross-check the selected library's old-commitment binding and new-share consistency in independent tests; the paper is not an assertion that this exact version was audited.

Activate only at the first round of the destination epoch after a finalized certificate. The new committee signs no future output before its scheduled release; the old committee stops producing new round partials at the boundary. For off-chain handover diagnostics, reconstruct a dedicated test signature under a separate IMD_BEACON_HANDOVER_TEST_V1 message and compare it under old/new shares; never use a future beacon round as the test. Keep old share material only until activation finality, then erase it and its backups. Archive public transcripts and certificates permanently; retain no raw private shares in logs, telemetry, crash dumps or repository fixtures. Erasure effectiveness and endpoint side channels remain review/operational limits.

7. Membership registry

7.1 Canonical registration and binding

Deploy the authoritative CommitteeRegistry on Ethereum. The brief supplies identity.md seat NFT 0x0000ec93127baa929e58e97dd0095a2bfb38ec1d; Unverified: this research did not establish that contract's implementation, supply, transfer hooks or storage layout. Integration acceptance must establish deployed code, ERC-721 ownership semantics and a working historical ownership adapter. The ERC-8004 identity-registry address and IMD ERC-20 address were not supplied: use explicitly required deployment configuration, validated and frozen before registration/funding, never a guessed address. ERC-8004 is currently documented as a Draft, with an ERC-721-based identity registry and registry-scoped agent ids; it is not proof of human uniqueness. ERC-8004, ERC-721.

register records (seatTokenId, seatOwner, agentRegistry, agentId, operator, longTermG2Key, peerIdHash, rewardAddress, registrationNonce, effectiveEpoch). Requirements:

• Current ownerOf(seatTokenId) authorizes registration. For v1, require the same address to own the selected ERC-8004 agent NFT; delegation to the beacon operator is authorized by that owner. Do not infer authorization from agentURI, reputation or an arbitrary agent wallet metadata field. A later delegation policy needs a separately specified authorization flow.
• Owner EIP-712 authorization binds every recorded field, chain id 1, the registry address, expiry and monotonic seat nonce. Support EIP-1271 contract owners. Front-running can relay the same authorized registration but cannot replace the operator or reward address. EIP-712, EIP-1271.
• The individual long-term beacon key is not a self-selected group share. Verify standard BLS PoP on its canonical public-key bytes, with BLS_POP_BLS12381G1_XMD:SHA-256_SSWU_RO_POP_, subgroup and non-infinity validation. Additionally require a BLS signature by that long-term key over ASCII("IMD_BEACON_REGISTRATION_V1") || ownerAuthorizationDigest, using the standard POP-scheme signature DST BLS_SIG_BLS12381G1_XMD:SHA-256_SSWU_RO_POP_. This fresh binding signature covers the seat, agent, operator, reward destination, registry domain, expiry and nonce through the typed digest. A copied public PoP plus an attacker's owner authorization must not be sufficient to reserve someone else's key. The owner authorization and key binding establish mutual authorization; a bare PoP alone does not bind ownership. Use the draft's PopProve/PopVerify procedure, not a bespoke algebraic knowledge proof. BLS PoP scheme.
• One active record per seat, one agent identity per active seat record, and no reused long-term public key or peer identity among simultaneous seat records. An operator with many seats can generate many distinct keys; these uniqueness checks prevent accidental aliasing, not Sybil concentration. An agent id is scoped by its registry address and chain.
• Require a worker-service declaration and endpoint/peer information sufficient for peers to connect. This is an operator assertion. The protocol verifies share participation, not that proprietary worker software runs on a particular host. Node runs beside the IMD worker and does not change its control plane.

Operators rotate keys/addresses only for future snapshots, with a new owner authorization, fresh nonce and PoP. An operator can voluntarily deregister its future service; the NFT/agent owner can revoke future delegation. Neither operation destroys existing shares or changes a frozen epoch's reward destination. Re-registration after a transfer requires the buyer's authorization; never send the seller's secret share to the buyer.

7.2 Transfer-safe snapshots without a trusted indexer

Calling ownerOf at different current blocks during a paginated scan does not create one historical ownership snapshot. v1 therefore requires a historical-state snapshot verifier, rather than treating an RPC indexer or a committee-chosen root as authoritative.

Maintain the registry's versioned ordered registration tree and count on-chain. For B_e, anyone supplies its canonical Ethereum header and immediate successor header: their hashes must match cached blockhash results, and their timestamps must straddle the cutoff exactly. Cache these headers/state roots while accessible; honest nodes use them only after finality. A missed cache window fails that transition. Prove the registry's historical registration root/count and the seat/agent owners against B_e's state root with Ethereum account/storage Merkle-Patricia proofs. Standard proof structure is documented in Ethereum's trie reference and EIP-1186.

Use a separately reviewed OwnershipSnapshotAdapter for the actual deployed NFT/agent implementations, including proxy implementation identity and codehash at B_e where relevant; do not assume every ERC-721 stores owners in the same slot. A contract upgrade or unsupported storage layout pauses new snapshots until a new network/configuration is reviewed. Pin the adapter and authorized implementation policy at genesis. No administrator may replace an ownership result with an unsigned assertion.

Process all historical registration records exactly once in ordered rank order, using inclusion proofs against the frozen registration root. For each, accept into the eligibility tree only if the record is effective and not deregistered at B_e, seat owner and agent owner both equal its authorized owner at B_e, and key/agent uniqueness holds. Historical ownership mismatch excludes that registration; transfers after B_e affect a later snapshot. Prove an excluded record's ownership mismatch or inactive flag as well: a proposer cannot omit a rival. Rank/count checks prevent omissions, duplicates and truncation. Final eligible leaves are sorted by token id and commit all registration fields and frozen reward destinations; finalize only after the entire historical count has been processed.

Use a domain-separated binary Merkle tree for registration, eligibility, public shares and reward manifests: leaf keccak256(0x00 || abi.encode(typeTag, fields...)), parent keccak256(0x01 || left || right), zero padding to the next power of two, with depth and actual count separately committed. typeTag=keccak256(ASCII(the tree's versioned name)); define these names in shared fixtures before the registry implementation. Never sort sibling hashes; preserve rank order. Sampling uses the eligible count, not padded leaves. Every root record binds its count. This is a proposed encoding choice, not a new cryptographic primitive.

Snapshot processing and sampling are permissionless and paginated, with bounded gas per chunk; funded keepers must complete before the fixed seed deadline. Any eligible owner can supply missing proofs. This provides safety against an omitted seat, not a free guarantee of snapshot liveness at arbitrary M. Benchmark the largest real registry and provision keepers; if it cannot finish in the hour, lengthen the precommitted preparation schedule in a new descriptor before launch. Initial pilot fixtures can use standard ERC-721 mocks, but production acceptance requires the real adapters. No stand-in address may escape into a deployment manifest.

7.3 Destination-chain epoch authorization

All destination verifiers pin the same genesis descriptor and PK. Ethereum reads its registry directly. Base and Robinhood additionally use immutable EpochMirror adapters receiving canonical Ethereum registry activation messages through each chain's native L1→L2 messaging path. Mirror records contain network id, epoch, committee/public-share roots, t, QUAL bitmap, activation round, transcript hash and unchanged PK hash. Authenticate both the native messenger/inbox path and the original Ethereum registry sender; a relayer-supplied sender argument is insufficient. Require sequential epoch numbers, exact activation boundary, no overwrite, idempotent duplicate delivery and the pinned key hash.

OP messaging exposes original cross-domain sender authentication; Arbitrum L1→L2 calls use retryable tickets and address aliasing. Robinhood documents its messaging routes. These are distinct adapters, not one interchangeable msg.sender check. OP cross-domain messenger specification, Arbitrum L1→L2 messaging, Robinhood cross-chain messaging.

Mirror delivery adds native-bridge/finality trust and availability assumptions, not a new randomness provider. Anyone may fund/retry delivery. Rounds whose epochs have not been authorized locally cannot publish or accept consumer commitments; delayed mirror delivery permits backfill of those same rounds later. The standalone pairing library can verify proofs without a mirror; the public beacon storage/consumer service must enforce the epoch gate. No committee multisig or admin root update substitutes for the native path in production. Testnet mocks must be marked as such.

8. Rounds and relaying

8.1 Signing and dissemination

Every qualified node computes M for its current epoch/round and creates one deterministic partial using its current share only when its clock reaches T(r)+1 second. The extra second guards the permitted one-second positive clock error, so real release is never before T(r) under the model. Use libp2p GossipSub for partial-signature distribution, plus authenticated direct request/response for catch-up and multi-aggregator redundancy. GossipSub includes peer scoring and flood-publishing controls; it is not a Byzantine agreement or reliable-broadcast proof. GossipSub v1.1 spec.

Topic: /imd-beacon/1/<networkId>/<epoch>/partials; envelope includes network, epoch, round, share index and compressed partial. Authenticate the peer against the frozen operator/peer binding, then verify the partial against the certified P_i before caching/forwarding. The envelope also identifies the sharing generation (shareEpoch, normally equal to epoch; see backfill below). Message id is the hash of network/shareEpoch/roundEpoch/round/index/partial bytes. Bound round lookahead to zero for partial acceptance, discard future partials into an alert channel, and require exact supported encodings. Limit message size to 1 KiB, per-peer verification work and distinct rounds per second; duplicate valid partials are idempotent. Gossip signed envelopes are not extra entropy.

Any node or external aggregator may reconstruct after t distinct valid shares. There is no leader election on the critical path. Publish (networkId,r,sigma,R) through a read-only HTTP endpoint and gossip; clients verify before use. Retain at least seven days of public partials locally for diagnostics/reward evidence and all group proofs or a public archive for historical verification. Retention of public data has no effect on private-share erasure. Use separate resource limits for public API traffic and committee traffic.

Do not overwrite a current share with an old backup to answer history. Serve archived proofs first. To repair an elapsed round whose epoch was canonically authorized, the current qualified committee may sign its original M using the current sharing generation, provided real time is past T(r) and the historical epoch/descriptor is unchanged. Extend the envelope with shareEpoch (the current sharing generation), distinct from roundEpoch=E(r); validate each partial under that generation's public share root. Never mix sharing generations during interpolation. This computes the same unique old-round signature without restoring retired shares. A proof does not certify which generation generated it. Disallow arbitrary messages, unauthorized epochs and future-release backfills. Require TestBackfillWithCurrentSharesSameValue and TestNeverMixSharingGenerations.

8.2 Chain API and permissionless relay

Required interfaces (exact ABI is to be frozen in the verifier job; scalar/encoding semantics above are already fixed):

verify(uint64 round, bytes calldata affineG1Signature) external view returns (bytes32);
submit(uint64 round, bytes calldata affineG1Signature) external;
get(uint64 round) external view returns (bool available, bytes32 value);

verify derives epoch and M from immutable configuration, checks the pairing, and returns the canonical R; the pure verification library has no availability side effects. submit additionally requires an authorized epoch and block.timestamp >= T(r), validates, stores (available=true,R) and emits RoundVerified(networkId,epoch,round,R,signature). Store an explicit availability flag; an all-zero random value is possible and must not mean unavailable. A zero address/key is never a configuration default. Accept out-of-order publication; do not require r−1. Duplicate matching submissions do not overwrite or pay; a mismatching submission for an available round reverts. Gas/fee accounting is checks-effects-interactions with pull withdrawals; a failing token transfer cannot prevent valid public proof storage.

A permissionless relay obtains any valid proof and submits it to any enabled destination chain. It cannot change the beacon value by front-running, modifying calldata encoding or choosing the fee recipient. First valid inclusion earns at most that chain/round's pre-funded IMD relayer fee; no fee is paid for invalid, future, duplicated or unsolicited unfunded rounds. The relay pays native-chain gas and decides whether the posted IMD fee is worthwhile. No automatic token/native exchange oracle is part of v1. Verified publication remains possible with no reward budget, so a treasury outage is not a verification failure. Economic service liveness still requires volunteers or adequate funding.

8.3 Consumer discipline and finality

Default target lead is 3,600 seconds (120 rounds), not “current round+1.” At request execution, choose the smallest r whose T(r) is at least the chain timestamp plus that lead. Freeze all bets, payouts, odds, participant list hash and request nonce in the same transaction. Reject target epochs that are not locally authorized; near a pending handover, pause new requests rather than choosing a currently known earlier output. Do not derive the target from the “latest relayed round,” which a relayer can censor.

Timing assumption: the request must become final before T(r), and the chain timestamp must be sufficiently fresh relative to honest beacon clocks. A one-hour lead is a conservative engineering default, not a theorem that a chain will finalize in an hour. Monitors pause new commitments when finality or timestamp lag breaches the configured margin. Builders/sequencers can delay inclusion; they cannot safely be allowed to execute a stale-timestamp request after the real-world reveal. Native L2 finality is distinct from a sequencer receipt: Base finality, Robinhood finality. These chain assumptions must appear in the demo UI/runbook. A contract timestamp check alone cannot establish real-world freshness.

After the target value is verified, anyone settles the permanently bound request. Define application expansion as:

W(counter) = keccak256(abi.encode(
    keccak256(ASCII("IMD_BEACON_CONSUMER_V1")), networkId, uint256(chainId),
    consumerAddress, bytes32(requestId), uint64(r), bytes32(R), uint64(counter)
))

For n equally likely outcomes use the §5 rejection cutoff for 256-bit W and increment counter on rejection; no W % n without rejection. This domain expansion neither creates extra entropy nor repairs a compromised beacon. A raffle must freeze the full entrant set and settle even if the caller dislikes its outcome. Anyone can execute settlement, with pull payouts to avoid a malicious winner reverting the whole raffle.

Default timeout policy is wait indefinitely for the same round; the demo may instead precommit a 48-hour, all-participants full-refund deadline. If refunds are enabled, anyone can trigger all refunds after the deadline and no result can settle afterwards; never refund only losers, accept replacement bets, rerun the same game, or substitute a new round. Such a refund policy deliberately gives a withholding adversary a “game cancelled” option and therefore cannot claim outcome-independent completion under loss of liveness. Document this residual selective-abort effect. Consumer discipline follows the same no-cancellation/no-new-input rationale as Chainlink's security guidance, with an explicit refund tradeoff rather than a hidden redraw.

9. Incentives

Keep randomness correctness independent of incentive accounting. IMD is a configured ERC-20 payment asset, not a second random contribution; require the real token address, decimals and transfer semantics in deployment records. Fee-on-transfer/rebasing tokens are unsupported unless reviewed accounting is added. Test fixtures may use an explicitly labelled mock; no mock, invented treasury or address may enter production configuration. The token interface is ERC-20.

Relayers: sponsors escrow a per-chain per-round fee F_relay in IMD, fixed before the round releases. Credit it once to the first valid submitting address; copied proofs may win the fee, so this is a permissionless race, not a promise that the original broadcaster is paid. Never use a caller-supplied gas bill or an unbounded reimbursement formula. Unfunded rounds remain verifiable/relayable. Sponsor terms are public and immutable for already-funded rounds; only unreserved funds may be withdrawn.

Signers whose partials are used: a group signature does not reveal its contributing subset. Do not trust a relayer's bitmap, pay all purported signers, or add the bitmap to the random hash. For sponsored rounds only, offer an optional, separately processed ContributionPool:

1. The sponsor reserves budget B_signer, divisible into t equal rewards, on Ethereum only; bind network/round/epoch. At most one reward set per round can win. Proposals must fully validate within seven days after T(r), so an incomplete proposal cannot reserve a sponsor budget forever; after that validation deadline, unallocated signer funds return to the sponsor. Default sponsorship is hourly (rounds with r mod 120 = 0), rather than every 30-second beacon. Ordinary beacon publication never waits for reward accounting.
2. Anyone proposes a manifest of exactly t sorted, distinct qualified indices and the corresponding partials, committing a rank-preserving Merkle root and index list. The full public manifest must be available in calldata/events. Its id binds network/round/epoch/indices/root; multiple proposals may coexist, funded by their proposers' native gas.
3. Permissionless paginated validation checks each declared partial with an individual pairing equation under that epoch's certified verification share, plus root/index proofs. Store validated bits and reject duplicates. Do not introduce an unreviewed batch-verification shortcut. A proposal becomes eligible only after all t partials are valid and its indices are exactly the declared set.
4. The first fully validated set is the canonical reward aggregation set. Any t valid partials from the certified degree t−1 polynomial reconstruct the already accepted unique sigma, so this set is a valid reconstruction witness; actual off-chain provenance cannot be established. Publish this distinction: “used” means the protocol's publicly validated reconstruction set, not a claim about which packets an earlier aggregator used in memory.
5. Only after completion, credit equal fixed amounts to frozen snapshot reward addresses of those t seats. Anyone may execute claims; funds cannot be redirected to the caller. No duplicate per-round reward, no bridge double-pay, no payment for an invalid/unfinished set. Claims expire 30 days after the winning manifest completes and unclaimed reserved funds return to the original sponsor. Rounding remainder remains with that sponsor. A late-completing second set cannot replace the winner.

This mechanism pays documented contributors without pretending the compact proof proves attribution. It deliberately allows a proposer to favour a valid subset and gives no guarantee of equal reward inclusion; honest partial gossip and competing proposers reduce dependence on one aggregator, not eliminate it. If fair availability pay is desired, specify it as a separate policy later. Pairing verification makes these rewards expensive: approximately 129*130k ≈16.8 million verification gas per sponsored round, plus proofs/storage/claims, spread across bounded transactions. Hourly sponsorship is opt-in, and may be economically unattractive on Ethereum. That cost is disclosed rather than hidden in the 250k round budget.

No slashable bond in v1. Seat gating already prices additional sampling tickets; a bond does not establish independent control. Nondelivery cannot distinguish withholding, network isolation and relayer censorship. Punishing complaints or absence would create a griefing surface. Invalid proofs are rejected at the sender's gas expense; objectively recorded equivocation excludes a dealer from its current ceremony, without a financial court. Rewards incentivize useful service and relayer fees fund publication, but neither proves that an adversary will not sacrifice rewards to censor a valuable game. Escalating financial security requires a separately justified bond/slashing specification and value-at-risk analysis.

10. Implementation plan

10.1 Language, libraries, licences and audit boundary

Choose Go for the node, to reuse drand/Kyber DKG, resharing and threshold APIs. Solidity/Foundry for contracts; Python standard library for report calculations/evidence utilities. Do not develop a custom signature scheme or DKG to avoid adapting an existing interface. All implementation dependencies must be pinned by immutable revision, vendored as ordinary files with licence notices, and build offline; no submodule or network-only module download may be required.

Component considered	Licence / established scope	Decision and remaining review
drand node/protocol code	Dual Apache-2.0 / MIT according to its README. Source.	Reuse framing, threshold-signature patterns and test fixtures where compatible; do not import its permissioned coordinator assumptions. Published tlock review covers named tlock components, not this new registry/DKG integration. tlock assessment scope.
drand/kyber	Root licence MPL-2.0-or-later; retain per-file/subdirectory notices. Licence. DKG reference revision 163173fa8030f35b422fea5a4e52425f77c210f5 was inspected for this report.	Default DKG/resharing implementation. No audit of this exact revision, BLS12 adapter and new board integration was established. Its README explicitly leaves application audit responsibility with the user. README.
drand/kyber-bls12381	MIT; wraps kilic/bls12-381. Repository and licence.	Existing G2 suite adapter for initial interoperability/testnet work. Audit and secret-operation timing guarantees of the selected complete stack are unverified here. Pin compatible revisions; do not assume the wrapper inherits another library's audit.
blst	Apache-2.0, BLS12-381; its README links an NCC Group audit from January 2021. Repository.	Independent oracle for vectors and candidate backend for secret BLS operations. It does not supply the whole DKG/resharing/registry protocol. Any new Kyber adapter and secret scalar handling need separate review; an old audit does not certify future versions. Go bindings may require a C toolchain; vendor the selected sources.
gnark-crypto	Apache-2.0; upstream links Kudelski coverage for BN254/BLS12-381 and warns it is not fully audited and gives no constant-time/side-channel guarantee. README/audit pointers.	Independent arithmetic/vector tool, especially for the BN254 comparison. Do not select secret-share operations merely because verification benchmarks are fast.
randa-mu/bls-solidity	MIT; README explicitly calls it experimental and unaudited. Repository. Inspected reference revision 11af179a8287d978659aae07adb66aa60f64b8a6.	Useful BLS2 verifier/hash-to-curve starting point and gas comparison. Vendor only after line-by-line review, add strict canonical encoding checks, and audit the resulting contract. No blanket “audited library” claim.

Production gate: a reviewer must identify which operations handle secrets, their side-channel assumptions, dependency versions and actual audit coverage. The Go library choices above establish an implementable testnet route, not a completed constant-time security argument. Go GC/backups complicate erasure; document the limitation and audit share storage/retirement. A Rust rewrite using blst could improve some memory-control properties, but does not automatically solve DKG correctness or erasure. Choose it only through a separate reviewed scope change, not mid-job substitution.

10.2 Intended repository layout

contracts/
  BeaconVerifier.sol                  # immutable network + group-key verification/storage
  CommitteeRegistry.sol               # canonical Ethereum registration/epochs
  SnapshotVerifier.sol                # Ethereum header/account/storage proof verification
  OwnershipSnapshotAdapter.sol        # exact deployed seat + agent ownership layouts
  DkgBoard.sol                        # ordered, available ceremony packets
  EpochMirror.sol                     # common immutable epoch gate interface
  mirrors/BaseEpochMirror.sol
  mirrors/RobinhoodEpochMirror.sol
  ContributionPool.sol
  interfaces/IBeacon.sol
  consumers/DemoRaffle.sol
node/
  cmd/imd-beacon/
  crypto/  registry/  snapshot/  sampling/
  dkg/  reshare/  rounds/  gossip/  relay/  store/
test/
  contracts/                         # Foundry tests named below
  vectors/                           # canonical JSON inputs/outputs, generated provenance
  integration/                       # virtual-clock devnet and bridge simulations
scripts/                             # offline checks + explicit read-only/live tools
vendor/                              # pinned Go dependency source, no submodules
lib/                                 # vendored Solidity dependencies with notices
third_party/                         # licences, source origins and revision/audit inventory
docs/
  SPEC.md  PLAN.md  chain-probes.json
  deployment/  operations/  audit/
foundry.toml  go.mod  go.sum  Makefile

Paths above are future implementation outputs, not a claim they already exist in this specification deliverable. No generated private keys or sensitive runtime configuration belongs in the tree. All demos and synthetic fixtures must be labelled nonproduction. Public network addresses go into deployment manifests only when actually established.

10.3 Ordered jobs and acceptance criteria

Each job updates its relevant fixtures/documentation and supplies an offline command in Makefile. Tests must assert outcomes/properties, not merely match the implementation's internal sequence. The pinned Foundry/compiler build profile must be recorded with gas snapshots; use EVM Prague or later with EIP-2537 enabled, without accidentally requiring unrelated opcodes absent on a target. Native chain fees are reported separately.

Job 1 — this specification. Files: docs/SPEC.md, the replacement section in docs/PLAN.md, artifacts/report.md, short root README, reproducible risk/probe utilities and public RPC evidence. Acceptance: exactly the eleven required top-level sections; every external claim attributed, calculations reproducible, recommendations distinguished from evidence, limitations and missing deployment parameters explicit, delivery copy byte-identical, local links resolve. No cryptographic implementation tests are claimed by a documentation job.

Job 2 — verifier contract and interface. Files: contracts/BeaconVerifier.sol, contracts/interfaces/IBeacon.sol, reviewed BLS/hash/encoding libraries under lib/, test/contracts/BeaconVerifier.t.sol, test/vectors/bls12.json, docs/verification-gas.md, foundry.toml.

• Tests test_Rfc9380Vectors, test_IndependentBlsVectors, test_CanonicalCompressionHash, test_RejectInfinity, test_RejectNonSubgroup, test_RejectNonCanonicalField, test_RejectMalformedLength, test_RejectWrongNetworkEpochRound, test_RejectMissingPrecompile, test_OutOfOrderRound, test_NoDuplicateFee, and test_ZeroRandomnessAvailability (mock only for the last value-path case).
• testFuzz_EncodingCannotChangeOutput runs at least 10,000 adversarial encodings; testFuzz_ModifiedSignatureFails covers mutated points/messages and proper failure handling. Compare with blst plus RFC vectors, not solely a copied Solidity implementation. Include one deterministic threshold fixture and at least 100 independent valid signatures.
• testGas_VerifySingleRound <=170,000 execution gas; testGas_SubmitFirstWrite <=250,000 receipt gas including intrinsic/calldata, without reward processing. Document storage writes and compiler profile. Deployment smoke scripts exercise positive, negative, malformed and subgroup vectors on all seven precompiles; empty successful returndata must fail closed. Group key/config immutable after verified genesis installation; early-round submission reverts.

Job 3 — committee registry, snapshots and epoch mirrors. Files: contracts/CommitteeRegistry.sol, SnapshotVerifier.sol, real OwnershipSnapshotAdapter.sol, mirror contracts, node/registry, node/snapshot, test/contracts/CommitteeRegistry.t.sol, test/contracts/EpochMirror.t.sol, docs/deployment/integrations.md. DKG readiness may initially use explicit test fixtures; no production admin-set root.

• Tests test_OnlySeatAndAgentOwnerCanRegister, test_ValidPoPRequired, test_ReplayedPoPDoesNotAuthorizeNewOwner, test_CopiedPoPCannotReserveVictimKey, test_ContractOwner1271, test_OneSeatOneTicket, test_AgentIdIsRegistryScoped, test_KeyRotationFutureOnly, test_DeregisterFutureOnly, test_TransferBeforeSnapshotExcluded, test_TransferAfterSnapshotKeepsEpochDuty, test_AgentTransferInvalidatesFutureRegistration.
• Historical proof tests test_CutoffHeaderAndSuccessor, test_SnapshotUsesOneStateRoot, test_RejectOmittedRank, test_RejectFalseExclusion, test_RejectWrongStorageLayout, test_RejectProxyUpgrade, test_ReorgBeforeFinalityDoesNotActivate and fuzzed MPT proofs. Produce known-answer proofs for the real deployed seat/agent contracts; establishing the configurable agent-registry address is deployment work, not permission to invent one.
• Mirror tests test_RejectForgedL1Sender, test_RejectDirectL2Call, test_AddressAliasAuthentication, test_EpochMonotonic, test_IdempotentBridgeReplay, test_RejectChangedGroupKey, test_UnknownEpochBlocksSubmit. Authenticate the actual documented native paths on each target testnet before deployment acceptance.
• Budgets: registration including PoP and key-binding signature ≤750k receipt gas; a one-record snapshot verification step ≤1.5m; one sampling/vote/activation chunk ≤1.5m; local mirror activation ≤500k excluding bridge envelope. No O(M) unbounded transaction. Stress the complete real-size snapshot within the one-hour deadline using accelerated chain time and block capacity, with cost/resource report.

Job 4 — DKG. Files: node/dkg, contracts/DkgBoard.sol, node/store, test/integration/dkg, public transcripts under test/vectors/dkg, dependency inventory and vendored sources.

• Tests TestDKG16, TestDKG32, TestDKG64 with all-honest, maximal allowed adversarial withholding, invalid deals, decrypt failures and missing nodes. TestNoFullSecretExport checks APIs/logging/storage, while acknowledging it cannot prove absence from process memory. TestDKG256 is required before production-size testnet claims.
• TestComplaintResolved, TestUnresolvedComplaintExcludesDealer, TestThresholdComplaintsNeverRevealPolynomial, TestEquivocationSameTranscriptForAll, TestSessionReplay, TestIncompleteBoardPayload, TestWrongThreshold, TestNoSeedRetry, TestNoSuccessfulKeyGrinding, TestFailClosedOnFinalityTimeout, TestIndependentTranscriptReplay.
• All honest qualified nodes obtain identical PK/public polynomial/QUAL, and their shares verify; all t-subset test signatures agree. With fewer than t qualified dealers/holders, no genesis activation. Certificates must include t eligible independent slot authorizations, not candidate-PK self-certification. “Independent” here means distinct slots, not independent operators.
• Default simulation uses virtual deadlines and deterministic test-only RNG fixtures; production randomness uses the OS CSPRNG. Offline runs must complete the 16–64 matrix without external services. Report 256-node CPU/memory/message/board-data volume. DkgBoard chunk ≤16 KiB and ≤1m receipt gas; complete phase payloads must fit the modeled chain capacity and schedule. If not, amend timing/transport specification with review rather than dropping availability checks.

Job 5 — rounds, gossip and relay. Files: node/rounds, node/gossip, node/relay, node/cmd/imd-beacon, test/integration/rounds, a local devnet command and public API schema/runbook.

• Tests TestNoEarlyPartials, TestClockDisagreementStopsSigning, TestUniqueSignatureAcrossSubsets, TestRejectDuplicateShareIndex, TestInvalidPartialFloodBounded, TestNoLeaderRequired, TestRelayerCannotChangeValue, TestRelayReorgResubmitsSameProof, TestBridgeDelayBackfillsSameRound, TestNoPredecessorDependency.
• Exhaust all subsets on small fixtures; 10,000 subset samples at N=256. Simulate 24 hours/2,880 rounds with ≤1-second one-way delay, ≤1-second clock error and 127 unavailable/adversarial members; ≥99% aggregate within 10 seconds of T(r). At 128 withholding shares, expose a stall and never invent a value. The simulator advances time without waiting 24 hours.
• Two aggregators and two relayers produce byte-identical proofs/values. Kill/restart either one and show continued service; data races/replayed packets cannot duplicate fees or affect outputs. go test -race passes. Target chain receipt budget stays ≤250k; no production dependence on a single HTTP endpoint, bootstrap peer or relayer.

Job 6 — resharing and sampling. Files: node/reshare, node/sampling, on-chain sampling verification and certificate logic, test/vectors/sampling.json, test/integration/handover.

• Tests TestReshareDisjointCommittees, TestReshareOverlap, TestGroupKeyUnchanged, TestRejectChangedConstantCommitment, TestOldThresholdMandatory, TestNewShareMatchesPublicPolynomial, TestOldPartialRejectedUnderNewShareKey, TestOldThresholdStillSignsGroupMessages (documents the security limit), TestEraseAfterActivation, TestHandoverNeverActivatesTwice.
• TestSamplerExactSmallPopulation, TestSamplerForcedRejection, TestSamplerDistinctSeats, TestSamplerSameAcrossGoSolidity, TestSnapshotBeforeSeed, TestNoReplacementAfterRefusal, TestInsufficientSeatsNoDowngrade, TestFailedHandoverPausesBoundary, TestLostThresholdRequiresNewNetwork. Statistical tests supplement exhaustive small-population outcomes, not replace them.
• Three successive epochs, including a disjoint transition, preserve PK and valid R; old/new shares agree on the handover test message. Failed attempts retain roster/seed/t and cannot replace successful setup. Every elected position has a deterministic status. Test 16→64 and 64→16 under explicit thresholds in fixtures, plus 256→256 production profile. Mainnet descriptor itself fixes 256/129. Gas for any one sampler/certificate chunk ≤1.5m.

Job 7 — minimal IMD incentives. Files: contracts/ContributionPool.sol, relayer fee escrow, test/contracts/ContributionPool.t.sol, fee/reward accounting documentation.

• Tests test_OnlyValidCompleteManifestPays, test_BitmapAloneNeverPays, test_ClaimantCannotRedirectReward, test_WrongEpochShareRejected, test_ManifestDuplicateIndex, test_NoCrossChainDoubleReward, test_FirstCompleteSetWins, test_ReplayedClaim, test_ExpiredClaimReturnsToSponsor, test_RelayerFrontRunPaysOnce, test_EmptyPoolDoesNotBlockBeacon, test_ReentrantTokenCannotDoubleSpend, test_SponsorCannotWithdrawReservedFunds.
• Property: IMD conservation equals deposits minus withdrawals and outstanding obligations; arbitrary contribution/relay ordering never creates an unfunded obligation. testFuzz_FundsConserved and invariant_NoDoublePayment run at least 10,000 cases. Unknown/nonstandard token transfer semantics fail deployment validation; no introduced bond/slash logic.
• Each contribution validation/claim transaction ≤500k receipt gas; manifests/indices paginated so no operation scales into a block-sized transaction. Report total gas for a 129-contributor sponsored round separately. A broken/unfinished reward proposal must not block other proposals or ordinary round storage.

Job 8 — independent audit and repairs. Files: docs/audit/cryptography-review.md, docs/audit/contracts-node-review.md, dated scope/revision identifiers, findings, fixes and regression tests. An automated agent panel is useful review input but does not replace the brief's external human cryptography review.

• Acceptance: external reviewers cover the DKG theorem/model qualifications, static/adaptive concentration assumptions, share erasure, retained-key compromise, PoP/domain/encoding, historical ownership proofs, bridge origins, secret-dependent operations, reward attribution and consumer selective abort. Each finding maps to an accepted fix/test or an explicitly approved residual risk. No open critical/high issue at value-bearing deployment. Re-run relevant tests and gas budgets on repaired revisions; no claim that a library's historical audit certifies the integration.

Job 9 — testnet and demo. Files: scripts/deploy*, contracts/consumers/DemoRaffle.sol, test/contracts/DemoRaffle.t.sol, chain-specific deployment manifests under docs/deployment/, docs/operations/runbook.md, public testnet evidence.

• First probe Ethereum testnet, Base Sepolia and Robinhood testnet 46630, distinct from target mainnet 4663. Establish public RPC/bridge paths and actual code addresses from official sources at deployment time; never copy a guessed id/address. Fail if EIP-2537 missing. Publish source, bytecode hashes, compiler profile, genesis descriptor, actual registry/NFT/agent/IMD addresses, group-key transcript and verified receipt gas.
• Tests test_FutureRoundCommitment, test_NoEntriesAfterCommit, test_NoTargetChange, test_NoRedraw, test_AnybodySettles, test_UniformOutcomeRejection, test_RefuseUnknownEpoch, test_LateFinalityPausesNewRequests, test_AllOrNothingRefundIfEnabled, test_MaliciousWinnerCannotBlockPayout.
• A read-only reproduction tool takes a raffle request and a proof, verifies the BLS signature and canonical R, reproduces the application expansion, and compares the payout against contract state on each chain. No API response is trusted as the proof.
• Automated acceptance simulates three epochs and injected faults using virtual time. A subsequent operator-run soak may last 72 hours, but is not a required real-time wait inside a single implementation job; implement jobs must not sleep/poll their allotted runtime away. Publish observations when the soak actually happens. Mainnet activation remains gated on audit and concentration review.

11. Open questions, each with a recommended default

Open item / what remains unknown	Recommended default and effect on implementation
Actual seat population and operator concentration	Target 256/129, daily epochs; assume no better than 33% adversarial seats for initial risk analysis and evaluate 40% explicitly. This is a risk scenario, not an established fact about the holders. Require actual M/A sensitivity and operator evidence before valuable use; use 64/33 only in a separate no-value pilot if supply is insufficient.
Sufficient security horizon / value at risk	Budget risk across the entire retained-key lifetime, not just one epoch. At sustained 40%, increase N (512/257 comparison) or do not launch valuable service. A sampled captured committee is a permanent-key event.
Exact DKG proof model	Use the cited Kyber implementation for testnet and make an external cryptographer decide whether its setup/release assumptions meet the intended beacon claim. Do not quietly call joint-Feldman a uniform-key DKG or ordinary BLS a strongly pseudorandom GLOW DVRF. A required stronger protocol is a specification revision, not an undocumented implementation choice.
Secret-operation timing, memory and erasure	Audit the entire Go/Kyber/curve stack; use blst-backed secret operations only through a reviewed adapter. Treat secure erasure of GC-managed buffers, snapshots and backups as an unresolved production assurance issue. No valuable use until reviewer-approved handling exists.
Actual ERC-8004 registry and seat/agent storage layouts	Deployment-supplied Ethereum registry address; require seat and agent to share an owner, pin exact ownership adapters/code identities. ERC-8004 is Draft, so version/ABI drift triggers review. No guessed deployment address or generic “all ERC-721 storage is alike” assumption.
IMD token address, decimals, reward budget and funding owners	Required deployment configuration validated before funding; fees/signer budgets are sponsor-set and fixed per funded round. Pilot rewards disabled until a real IMD integration is established. No arbitrary token amount or treasury recipient is invented here.
Real Ethereum snapshot/board cost and maximum M	Keep ordered on-chain available ceremony data and historical ownership proofs initially. Measure 256 participants and full live seat population. If hourly snapshot or ceremony windows are infeasible, choose longer precommitted preparation windows before genesis; do not weaken roots or allow a coordinator to omit seats.
Committee private endpoint topology	Public peer identities with authenticated committee transport, independent bootstrap peers and multiple aggregators. Resource-limit public ingress; do not count endpoints/IPs as independent operators. Review DoS at production size.
Future precompile/fork changes	BLS12-381 is v1. Reprobe seven addresses and malformed/subgroup vectors on actual deployments, with two independent RPC views. No automatic BN254 fallback; unsupported destinations stay disabled.
Native bridge details and delay	Implement separate authenticated OP and Nitro/Robinhood routes, with pinned deployment manifests and fail-closed epoch gates. Mirror delivery delay reduces liveness; no admin fast path.
Finality and freshness margin per consumer chain	One-hour future lead initially, finalized-before-release assumption, monitoring and fail-closed new requests on chain stalls. Reassess from measured chain finality; an old sequencer timestamp is not proof that a result is still unknown.
Refund policy after a beacon stall	Default indefinite wait for the same round. Demo may opt into an immutable full-refund deadline with disclosed selective-abort risk. Never silently redraw or migrate an unresolved wager to a replacement network.
Fair signer reward inclusion	Pay the first completely validated reconstruction set, sponsored hourly; acknowledge subset favoritism and native-gas costs. Do not add an availability-pay committee or arbitrary bitmap rewards under the present specification.
Bond/slashing	None in v1. A future proposal must identify objectively provable misconduct, a safe adjudication path and value-at-risk rationale; downtime alone is insufficient evidence.
Group-secret compromise or permanent loss of t old shares	Stop new commitments, preserve public evidence, create a new independently reviewed group key/network for future consumers. Stable-key resharing cannot restore secrecy or reconstruct a secret without a threshold.
Governance / upgrades	Immutable verifier, descriptor and adapter policy; new network id and consumer opt-in for protocol changes. Funding controls do not control randomness. Initial deployer has no post-genesis key/root override.

Review status: this is a sourced design and a set of future acceptance gates. Mathematical tables and public RPC evidence are locally reproducible; independent security validation, chain deployment, measured contract gas and economic viability remain uncompleted. No missing private deployment choice has been replaced with a made-up value.