RFC-0162 proposes a de facto economic security framework: treat institutional capture / chokepoint formation as a protocol security failure mode—even if the chain remains live.
It defines reviewable invariants + metrics meant to keep Polkadot’s “utility rails” open and contestable over time.
What it tries to preserve (security invariants)
Contestability: markets stay open to entrants (anti-cornering posture).
Portability / Substitutability: users/apps aren’t locked into a single registry or distribution channel.
Rule-based exit: no privileged lanes; explicit anti-jamming constraints.
Scope (what it changes)
RFC-0162 is intentionally “constitutional”: it defines the standard, then proposes implementable amendments as follow-ups:
Process: amend the RFC template to require a Market Structure Impact section in future RFCs.
Open Utilities: amend RFC-0032 and RFC-0078 for validity-only neutrality + proof-carrying export + multi-source metadata resilience.
Fair Markets: amend RFC-0149, RFC-0097, RFC-0007 for concentration friction + unbonding anti-jamming + time-bounded privileged sets with explicit liveness guardrails.
Non-goals: it does not prescribe treasury procurement policy, editorial/media governance, a single identity system, or discretionary censorship (validity predicates only).
Why now
As Polkadot relies more on System Chains, Coretime Markets, and shared standards, those surfaces become part of the protocol’s practical security perimeter. If any becomes a chokepoint (cornering, registry monopoly, privileged lanes), decentralization degrades while the chain can remain perfectly live.
What feedback is most valuable
If you want to help, please pick one of these and go deep:
Compatibility
(can we satisfy these constraints without breaking legitimate spam-control / weight limits?)
How to engage
Reply here with:
which section you reviewed, and
one concrete change request (definition, metric, parameter, unintended consequence).
If you strongly disagree with the framing, I’d especially like a counter-proposal for how we should model capture risk in a way that’s still implementable and reviewable.
I would like to share a deconstruction of the impact surface of this RFC-0162 for clarifying purposes, as exposed in the Github thread.
⸻
The market, specially under decentralized economies, is holistically interdependent. This RFC-0162 treats the ecosystemic threat on institutional capture, given by the market structure (the rules of the game), within three consecutive PRs coordinated together as an Omnibus, an indivisible package of reforms on the whole structure.
With “RFC-0162: The Ecosystem Anti-Trust & Market Structure Omnibus” we are proposing a single, comprehensive act to engineer fair competition and prevent institutional capture across the entire Polkadot protocol design.
This is the minimal mapping from RFC-0162’s threat model to concrete amendment points + engineering invariants; if anyone sees a better anchor for any node, I’m happy to revise the references accordingly:
Capture via incumbency entrenchment and monopolizing scarce resources (coretime).
F2: Neutrality (Discrimination)
§6.2 Definition §7.3 Amendment A
“Discrimination” = inclusion/exclusion by non-validity attributes; neutrality is normed as common-carrier, with validity predicates only as exceptions (§6.1).
Periodic contestability: renewed coretime can be forced back into competition; discretionary privilege must be time-bounded and replaced by rule-based mechanisms.
I2: Neutrality (Validity Only)
§7.3; §6.1–§6.2
Common Carrier for canonical utility state: no discrimination beyond validity predicates.
I3: Portability (Proof Export + Multi-Source)
§7.4; §7.6; §6.5
Verifiable export + multi-source retrieval validated against on-chain commitments.
Unbonding must be purely rule-based, with per-controller caps and order-preserving carry-over (no privileged fast lanes).
Last but not least, this roadmap starts by patching 0000-template.md, immediately enforcing market security considerations as a review standard for all subsequent RFCs.
