[RFC Pre-Submission] Institutional Capture as a Security Failure Mode: Introducing the Anti-Trust & Market Structure Omnibus

Governance
1

To the Polkadot and Kusama community,

Decentralization is not a steady state; it is a continuous engineering objective. As Polkadot matures, we are successfully moving critical functions off the Relay Chain and into specialized institutions: System Chains, Coretime Markets, and Collectives. This is efficient, scalable, and—given the roadmap—necessary.

At the same time, this maturation introduces a class of risks that our threat models typically treat as “governance” rather than “security”: institutional capture.

Capture is a structural failure mode: when an institution becomes a chokepoint, the system’s permissionless claims degrade even if the code continues to run reliably.

  • If the Coretime market can be cornered by incumbents, it ceases to behave like a market and becomes a durable rent surface.
  • If a System Chain becomes the only admissible source of identity or metadata, it becomes a de facto gatekeeper for downstream innovation.
  • If privileged operational roles persist through discretionary appointment without rule-based rotation, they become lobbyable and difficult to replace without instability.

I am proposing the “Ecosystem Anti-Trust & Market Structure Omnibus” (RFC number to be defined) to treat these capture vectors as engineering constraints, in the same spirit that we treat consensus failures and market manipulation as technical failure modes.

The core argument

We already treat consensus failure (slashing, safety margins) and market failure (price manipulation, hoarding dynamics) as technical problems with explicit mitigations.

The same must apply to capture.

Contestability, neutrality, and substitutability are operational security requirements.
If a system cannot be contested, replaced, or exited through deterministic rules, it is insecure—regardless of uptime, performance, or governance goodwill.

What the Omnibus proposes

This RFC is a “constitutional” upgrade to our design standards. It bundles three coordinated amendments, deliberately designed to be reviewable and implementable as separate PRs.

1) Process Standard (Meta): make market-structure risk reviewable

We cannot mitigate what we do not disclose. This amendment updates the Fellowship RFC template to require a mandatory Market Structure Impact section for all new RFCs.

Authors must explicitly address:

  • incumbency advantage and entry paths,
  • creation/modification of privileged sets or registries,
  • portability and exit properties,
  • and at least one measurable concentration or exit-latency metric.

This is intended to be a standardized disclosure regime—analogous to “Security Considerations.”

2) Infrastructure Standard (Open Utilities): secure the new rails

As we rely more on System Chains (e.g., Asset Hub, People Chain) and critical standards (metadata), we must ensure these rails behave like open utilities rather than chokepoints.

The amendments enforce:

  • Neutrality: transaction inclusion based only on validity predicates (signatures, fees, weight bounds, deterministic spam limits), never on identity category or affiliation.
  • Portability: proof-carrying export for canonical utility state claims, so users and applications are not locked into a single registry by availability or discretion.
  • Resilience: multi-source metadata retrieval (or an explicit offline-safe fallback) so distribution cannot become a gatekeeping layer.

3) Economic Standard (Fair Markets): preserve contestability and credible exit

Market design determines who can enter and who can endure. The amendments introduce:

  • Anti-hoarding invariants: Coretime renewals must face periodic contestability via re-entry events and/or concentration friction.
  • Exit neutrality: unbonding queues must be rule-based (FIFO/pro-rata) and protected from “whale jamming” and sybil splitting via per-controller caps with deterministic carry-over.
  • Sunsetting privilege (with liveness guardrails): a concrete, liveness-safe path to transition invulnerable collator sets from discretionary appointment to rule-based selection/rotation, bounded by explicit parameters (e.g., INVULN_MIN_FLOOR).

Why this matters now

We are at a pivot point where institutional surfaces are becoming part of Polkadot’s de facto security perimeter.

The rules we encode now for System Chains, metadata distribution, Coretime renewal dynamics, and exit queues will shape ecosystem contestability for years. If we encode restraint now—systems that force themselves to remain open—we protect the credibility of Polkadot’s neutrality and permissionless claims as the architecture becomes more institutional.

This is not intended as a critique of current contributors or institutions, rather to be the next step in making “decentralization” durable under realistic adversaries: capital concentration, coordination capture, and chokepoint formation.

Next steps and the feedback I’m requesting

The full draft of this RFC is prepared (happy to paste it in full or link it once published). Before opening the formal PR, I am soliciting technical feedback on two areas:

  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

If you disagree with the premise, I still want the counterargument framed in engineering terms: which threat is negligible, which invariant is too costly, and which alternative constraint would achieve the same capture-resistance with lower complexity.

Respectfully,
[Diego Correa Tristain / algoritmia@labormedia.cl]
A participant committed to contestability over coordination-by-control.