This follow-up (re: IBP curator pay / auditability and the broader validator-set discussion) is exactly the kind of “institutional surface” that tends to get waved away as social drama — until it hardens into a durable chokepoint.
In “message number 25” of this thread, the claim being argued is basically: (a) certain validator operators can exploit timing + UI observability gaps (e.g., commission flips / identity splitting), and (b) at the same time, large budget rails (bounties / curator roles / reporting) can become hard to audit in practice, creating trust erosion and a concentration vector. oai_citation:0‡Polkadot Forum
This is why I keep pushing collaboration around RFC-0162:
- RFC-0162’s framing is: treat institutional capture / chokepoint formation as a security failure mode, and force every future change to include a Market Structure Impact analysis (i.e., make these attack surfaces explicit, reviewable, and bounded). oai_citation:1‡Polkadot Forum
- It also explicitly does not prescribe treasury procurement policy, so the goal isn’t “use RFC-0162 to litigate one bounty.” The goal is to stop building systems where auditability and contestability are optional. oai_citation:2‡Polkadot Forum
Concrete suggestion for anyone willing to engage productively:
Let’s propose an RFC-0162 follow-up amendment that adds observability/auditability invariants for protocol-adjacent “utility rails” (dashboards, reports, registries) that the ecosystem treats as canonical in practice—so the default is verifiable history, not “trust me” narratives.
If you’re sympathetic to that direction: please jump into the RFC-0162 review thread and propose one concrete invariant / metric / monitoring requirement we can actually implement.