The Ecosystem Anti-Trust & Market Structure Omnibus #162
Conversation
|
i’ve read everything you’ve written - if i’m honest it is often hard work to get through as it is presented in dense and complex language - perhaps you could dumb things down a little bit, and in turn make your contributions more accessible as you are clearly passionate and (possibly?) have some experience in the antitrust arena… fwiw I understand the meta problems/issues you are pointing at, but a lot of these issues are downstream of the genesis distribution and the basic economic incentives of the network. i struggle to understand what you are requesting with this RFC.
? i don’t even get the title… |
|
I appreciate the time you have taken to read RFC-0162. For the benefit of the broader community, I would like to expand on this Request for Comments with a few clarifying points. 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: flowchart LR
%% RFC-0162 — Diagram-Anchored Review Map (GitHub Mermaid)
%% Failure Mode -> Vulnerable Rail -> Norm (Invariant)
%% --- STYLING ---
classDef rail fill:#0f172a,stroke:#475569,stroke-width:2px,color:#f1f5f9;
classDef fail fill:#450a0a,stroke:#ef4444,stroke-width:2px,color:#fecaca;
classDef inv fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#d1fae5;
linkStyle default stroke:#64748b,stroke-width:1px,fill:none;
%% --- 1) THREATS ---
subgraph THREATS["Failure Modes (Risk)"]
direction TB
F1["F1 Contestability Failure<br/>(Entrenchment)<br/><sub>§2 • §3</sub>"]:::fail
F2["F2 Neutrality Failure<br/>(Discrimination)<br/><sub>§6.1–§6.2</sub>"]:::fail
F4["F4 Exit Rights Failure<br/>(Jamming / Lock-in)<br/><sub>§3</sub>"]:::fail
F3["F3 Portability Failure<br/>(Data Lock-in)<br/><sub>§2 • §6.5</sub>"]:::fail
end
%% --- 2) RAILS ---
subgraph RAILS["Vulnerable Targets"]
direction TB
subgraph MKT["Market Domain"]
direction TB
CT["CT Coretime Market<br/>(amends RFC-0149)<br/><sub>§7.7</sub>"]:::rail
GOV["GOV Governance Rail<br/>(amends RFC-0032)<br/><sub>§7.3</sub>"]:::rail
end
subgraph OPS["Operations Domain"]
direction TB
EXIT["EXIT Staking / Unbonding<br/>(amends RFC-0097)<br/><sub>§7.8</sub>"]:::rail
COL["COL Collator Selection / Invulnerables<br/>(amends RFC-0007)<br/><sub>§7.9</sub>"]:::rail
end
subgraph UTL["Utility Domain"]
direction TB
ID["ID Identity / System Utilities<br/>(amends RFC-0032)<br/><sub>§7.4–§7.5</sub>"]:::rail
MD["MD Metadata Rail<br/>(amends RFC-0078)<br/><sub>§7.6</sub>"]:::rail
end
end
%% --- 3) FIX ---
subgraph FIX["§7 Norms (Fix)"]
direction TB
I1["I1 Contestability<br/>(Forced Re-entry / Anti-cornering)<br/><sub>§7.7.1 • §7.9</sub>"]:::inv
I2["I2 Neutrality<br/>(Validity-only / Common-carrier)<br/><sub>§7.3 • §6.1–§6.2</sub>"]:::inv
I4["I4 Rule-based Exit<br/>(Ordering + Per-controller caps)<br/><sub>§7.8.1–§7.8.2</sub>"]:::inv
I3["I3 Portability<br/>(Proof export + Multi-source)<br/><sub>§7.4 • §7.6 • §6.5</sub>"]:::inv
end
%% --- WIRING ---
F1 ==> CT
F1 ==> GOV
CT ==> I1
GOV ==> I1
F2 ==> GOV
F2 ==> COL
GOV ==> I2
COL ==> I2
F4 ==> EXIT
F4 ==> CT
EXIT ==> I4
CT ==> I4
F3 ==> ID
F3 ==> MD
ID ==> I3
MD ==> I3
⸻ Column 1: THREATS (The Risk) Mapped to §2 (Motivation) and §3 (Threat Model).
⸻ Column 2: RAILS (The Target) Mapped to the specific RFCs being amended in §7 (Specification).
⸻ Column 3: FIX (The Norms) Mapped to the engineering invariants defined in §7 (Specification).
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. |
3 participants
Summary
This PR submits RFC-0162: The Ecosystem Anti-Trust & Market Structure 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:
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
0000-template.mdto require a mandatory Market Structure Impact section for all future RFCs.Non-goals
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:
Parameter bounds and liveness guardrails
EXIT_CAP_PER_CONTROLLERbounds and epoch definitionINVULN_MIN_FLOORand decay schedule safetyConcentration metrics and triggers
C_MAXthresholds and measurement windowsCompatibility with existing RFC intent
Implementation plan (follow-up PRs)
The RFC proposes implementation as three independently reviewable PRs:
0000-template.mdThese will be opened as separate PRs to keep diffs small and reviewable once consensus on the Omnibus text is reached.
Checklist
text/following repository conventions