pub const DISTRIBUTOR_ANNOUNCE: u8 = 226;Expand description
Wire opcode for a distributor-announce broadcast (DIG-Network/dig_ecosystem#3252).
A public all-peers flood carrying untrusted reward-distributor discovery hints: a
store_id plus the launcher ids of distributors the sender knows of for that store. Same
§5.4 public-broadcast carve-out as STORE_MELTED and HOLDINGS_ANNOUNCE.
Body layout (encoded downstream in dig-gossip, not this crate): store_id(32) ‖ launcher_id_count(u16 BE) ‖ launcher_ids(32 each, ≤ 32).
Deliberately unsigned, for the same reason PROFILE_ROOT_ANNOUNCE is: the authority
for a distributor is the on-chain coin, not the announcing peer, so a receiver re-derives
every property from chain before the launcher id becomes a candidate. Unlike
HOLDINGS_ANNOUNCE, the frame carries no addresses, so there is no address-rewriting or
DHT-poisoning threat for a signature to close — a forged announce costs a receiver one
wasted chain lookup that then fails that compare.
A frame asserts membership only, and never completeness. The launcher ids present are
ids the sender claims to know of for that store_id. The absence of an id from a frame
asserts nothing at all — not that the sender doesn’t know of it, not that it has been
evicted, nothing.
A receiver MUST union a received frame into whatever set it already holds for that
store; it MUST NOT replace its per-store set from a frame, and it MUST NOT diff two
frames against each other to infer a removal. This is what makes eviction
unrepresentable on this wire: because absence carries no meaning, old_set \ new_set is
never a signal, so a receiver that unions can never manufacture a false eviction
(dig_ecosystem §12.5 clause 7). Age out an entry locally on your own retention policy, never
on a peer’s frame.
A sender who knows of more than MAX_LAUNCHER_IDS_PER_ANNOUNCE (32) distributors for one
store sends any subset of at most 32 and MAY rotate which subset it sends across frames.
Because a frame is never a completeness claim, sending a partial subset is honest by
construction — it is not truncation, and it cannot forge an eviction the way silently
dropping ids from a claimed-complete snapshot would.
An empty launcher-id list is a distinct, positive statement in its own right: “my known set for this store is empty” — not “I have nothing to say.” It is how this wire says “I know of none” instead of saying nothing, and a receiver MUST NOT read it as a request to clear what it already holds (see the union rule above).
A received announce is a hint only: it must not admit an entry, rank a candidate, or be a claim’s authority. A peer that never hears one MUST still find and claim via §13.1 — this opcode is a latency shortcut, never a dependency (dig_ecosystem §13.2 clause 2).