# RFC-0162 (PR #162): Ecosystem Anti-Trust & Market Structure Omnibus — Review Thread **URL:** \ **Category:** Governance\ **Created:** [January 15, 2026, 3:50am UTC](https://forum.polkadot.network/t/rfc-0162-pr-162-ecosystem-anti-trust-market-structure-omnibus-review-thread/16709 "2026-01-15T03:50:55Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![labormedia](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/labormedia/32/2638_2.png) [@labormedia](https://forum.polkadot.network/u/labormedia)\ **Post date:** [January 15, 2026, 3:50am UTC](https://forum.polkadot.network/t/rfc-0162-pr-162-ecosystem-anti-trust-market-structure-omnibus-review-thread/16709/1 "2026-01-15T03:50:55Z")
gm Polkadot community 👋 I’ve opened a new Fellowship RFC PR for review + discussion: > > > \## Summary > > This PR submits \*\*RFC-0162: The Ecosystem Anti-Trust & Market Stru…cture Omnibus\*\* to the Fellowship RFC repository. > > The RFC treats \*\*institutional capture\*\* as a \*\*security failure mode\*\* (analogous to DoS / centralization drift / chokepoint formation) and introduces operational constraints that preserve: > > \- \*\*Contestability\*\* (markets remain open to new entrants), > \- \*\*Neutrality\*\* (canonical utility rails do not discriminate beyond validity predicates), > \- \*\*Substitutability / Portability\*\* (users and applications are not locked into single registries or single distribution channels), > \- \*\*Rule-based exit\*\* (no privileged lanes; anti-jamming protections). > > This is a “constitutional” standard: it primarily defines \*reviewable invariants\* and metrics, and is designed to be implementable as three independently reviewable follow-up PRs. > > \--- > > \## Scope > > \### Normative changes introduced by RFC-0162 > > 1) \*\*Process (Meta):\*\* Amend \`0000-template.md\` to require a mandatory \*\*Market Structure Impact\*\* section for all future RFCs. > 2) \*\*Infrastructure (Open Utilities):\*\* Amend \*\*RFC-0032\*\* and \*\*RFC-0078\*\* to add: > - validity-only neutrality for canonical utility state, > - proof-carrying export (portability), > - multi-source metadata resilience. > 3) \*\*Economics (Fair Markets):\*\* Amend \*\*RFC-0149\*\*, \*\*RFC-0097\*\*, \*\*RFC-0007\*\* to add: > - coretime re-entry events + concentration friction, > - unbonding anti-jamming constraints (per-controller caps, deterministic carry-over), > - time-bounded privileged sets (invulnerables) with explicit liveness guardrails. > > \### Non-goals > > \- This RFC does \*\*not\*\* prescribe treasury procurement policy beyond protocol-governed mechanisms. > \- It does \*\*not\*\* define editorial/media governance. > \- It does \*\*not\*\* require a single identity system. > \- It does \*\*not\*\* introduce discretionary censorship (validity predicates only). > \- It does \*\*not\*\* claim capture can be eliminated, only that major capture surfaces must be \*\*identified and bounded\*\*. > > \--- > > \## Why now > > As Polkadot’s roadmap increasingly relies on \*\*System Chains\*\*, \*\*Coretime Markets\*\*, and \*\*standards\*\* (e.g., metadata), these become part of the protocol’s de facto security perimeter. If any of these surfaces form a chokepoint (market cornering, registry monopoly, privileged lanes), decentralization degrades even if the chain remains live. > > RFC-0162 is intended as the next step in security maturity: explicit threat model, explicit metrics, explicit mitigations. > > \--- > > \## Review guidance > > Please focus feedback on: > > 1) \*\*Parameter bounds and liveness guardrails\*\* > - \`EXIT\_CAP\_PER\_CONTROLLER\` bounds and epoch definition > - \`INVULN\_MIN\_FLOOR\` and decay schedule safety > > 2) \*\*Concentration metrics and triggers\*\* > - purchaser-level metrics vs. higher-order identity modeling > - practical \`C\_MAX\` thresholds and measurement windows > > 3) \*\*Compatibility with existing RFC intent\*\* > - confirm these constraints can be satisfied without constraining legitimate spam-control / weight limits > - confirm portability requirements are scoped to \*\*claims\*\* (proof-carrying exports), not unilateral balance migration > > \--- > > \## Implementation plan (follow-up PRs) > > The RFC proposes implementation as three independently reviewable PRs: > > \- \*\*PR-A (Meta):\*\* update \`0000-template.md\` > \- \*\*PR-B (Open Utilities):\*\* patch RFC-0032 and RFC-0078 > \- \*\*PR-C (Fair Markets):\*\* patch RFC-0149, RFC-0097, RFC-0007 (including explicit enactment blocks/epochs and deprecation schedules) > > These will be opened as separate PRs to keep diffs small and reviewable once consensus on the Omnibus text is reached. > > \--- > > \## Checklist > > \- \[x\] RFC text added under \`text/\` following repository conventions > \- \[x\] File renamed to match PR number (after PR is opened) > \- \[\] References to amended RFCs verified > \- \[\] Monitoring requirements and parameter governance included **PR #162 — RFC-0162: “The Ecosystem Anti-Trust & Market Structure Omnibus”** * * * ## TL;DR 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). - **Neutrality:** canonical rails don’t discriminate beyond **validity predicates**. - **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: 1. **Process:** amend the RFC template to require a **Market Structure Impact** section in future RFCs. 2. **Open Utilities:** amend **RFC-0032** and **RFC-0078** for validity-only neutrality + proof-carrying export + multi-source metadata resilience. 3. **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: 1. **Parameter bounds + liveness guardrails** (e.g., exit caps, invulnerable floor/decay safety) 2. **Concentration metrics + triggers** (measurement windows, thresholds, identity modeling assumptions) 3. **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. ---
**Author:** ![labormedia](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/labormedia/32/2638_2.png) [@labormedia](https://forum.polkadot.network/u/labormedia)\ **Post date:** [January 19, 2026, 4:19pm UTC](https://forum.polkadot.network/t/rfc-0162-pr-162-ecosystem-anti-trust-market-structure-omnibus-review-thread/16709/2 "2026-01-19T16:19:43Z")
I would like to share a deconstruction of the impact surface of this RFC-0162 for clarifying purposes, as exposed in the [Github thread](https://github.com/polkadot-fellows/RFCs/pull/162#issuecomment-3764315631). ⸻ 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: ![Screenshot 2026-01-19 at 1.02.55 PM](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/a/aa1e150047372f004b7d183fdd64e89b570ea436.png) (Mermaid diagram available at the [Github thread](https://github.com/polkadot-fellows/RFCs/pull/162#issuecomment-3764315631)) ⸻ Column 1: THREATS (The Risk) Mapped to §2 (Motivation) and §3 (Threat Model). | Chart Node | RFC Text Reference | Context in RFC | | --- | --- | --- | | **F1: Contestability** (Entrenchment) | **§2 Motivation** **§3 Threat Model** | 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). | | **F3: Portability** (Data Lock-in) | **§6.5 Definition** **§7.4, §7.6** | “Portability” = **proof-carrying export** (light-client verifiable); reinforced by **multi-source metadata resilience**. | | **F4: Exit Rights** (Jamming / Lock-in) | **§3 Threat Model** **§7.8 Amendment** | Adversary “dominates exit capacity”; mitigated by **rule-based queue ordering** + **per-controller rate limits**. | ⸻ Column 2: RAILS (The Target) Mapped to the specific RFCs being amended in §7 (Specification). | Chart Node | Target System | RFC Text Reference | | --- | --- | --- | | **CT: Coretime Market** | **RFC-0149** | **§7.7** (Anti-hoarding invariants; re-entry events + concentration friction). | | **GOV: Governance Rail** | **RFC-0032** | **§7.3** (Canonical utility state neutrality; validity-only inclusion). | | **EXIT: Staking/Unbond** | **RFC-0097** | **§7.8** (Exit neutrality + anti-jamming constraints). | | **COL: Collator Selection** | **RFC-0007** | **§7.9** (Sunsetting invulnerables; rule-based replacement + liveness safety). | | **ID: Identity System** | **RFC-0032** | **§7.4–§7.5** (Proof-carrying export; multi-attestation compatibility). | | **MD: Metadata Rail** | **RFC-0078** | **§7.6** (Anti-registry capture; multi-source resilience). | ⸻ Column 3: FIX (The Norms) Mapped to the engineering invariants defined in §7 (Specification). | Chart Node | RFC Text Reference | The Constitutional Norm | | --- | --- | --- | | **I1: Contestability** (Forced Re-entry + Sunset Privilege) | **§7.7.1** ; **§7.9** | **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. | | **I4: Rule-Based Exit** (Ordering + Per-Controller Rate Limits) | **§7.8.1** ; **§7.8.2** | 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.