candidates

members

proficients

fellows

senior_fellows

experts

senior_experts

masters

senior_masters

grand_masters

Miscellaneous

The Kus Public Review &amp; AMA: 2022 - 2025

Andrey McQ

The Kus Public Review & AMA: 2022 - 2025

AAG 2.0 for the Second Age of Polkadot

RocoDotcast

Looking for guidance and funding support to build a verified global services platform on Polkadot

<strong>The Forum serves as a digital town square to co-create the future of Polkadot by the ecosystem, for the ecosystem. Suggestions on how to improve the Forum live here.</strong>

The Forum serves as a digital town square to co-create the future of Polkadot by the ecosystem, for the ecosystem. Suggestions on how to improve the Forum live here.

Polkadot Forum Meta

Welcome to the Polkadot Forum :waving_hand:

Rajesh Shirsagar

Welcome to the Polkadot Forum 👋

Getting started: Read this first

Polkadot Forum Super Admin

Forum Anonimity and Gov Research

If you’re looking for discussion or discourse for anything and all things Tech related, then this is the place for you. .

Tech Talk

Runtime release notification for v2.0.5 [15.01.2026]

Anaelle LTD

&ldquo;Revive&rdquo; Smart Contracts: Status Update

Alexander Theißen

"Revive" Smart Contracts: Status Update

If you got hacked

Josep

Whether you’re new to Polkadot’s Governance or an OpenGov OG, this is the place for you to get involved and join the discussion.

Governance

Decentralized Voices Cohort 5 Application - Light Track: GoverNoun AI Governance Agent

Luke

[WFC] Burn-Based Tokenomics for Kusama: The Ethereum Model, Not a Hard Cap

RFC-0162 (PR #162): Ecosystem Anti-Trust &amp; Market Structure Omnibus — Review Thread

Diego

RFC-0162 (PR #162): Ecosystem Anti-Trust & Market Structure Omnibus — Review Thread

If you’re looking for discussion or discourse for anything and all things Ecosystem, then this is the place for you. .

Ecosystem

A Letter of Anti-Trust and Free-Market Principles for Ecosystem Leadership

Concerns about the ecosystem&rsquo;s social networks

Concerns about the ecosystem's social networks

Polkadot Digest 16 January 2026

Radhakrishna Dasari

If you’re looking for discussion or discourse for anything and all things Ambassador related, then this is the place for you. .

Ambassador Programme

Polkadot Ambassador Fellowship (PAF) Governance: Critical Questions Before On-Chain Implementation

Transition to the On-Chain Collective: Next Steps for the Ambassador Fellowship

Official statement of the Advisory Board of the Polkadot Ambassador Fellowship

If you’re looking for a resource, FAQ or guide, then this is the place to be. We urge all users of the forum to try and use this category when needed.

Resources & FAQs

How to P&lt;&gt;K bridge USDT or USDC

Alain Brenzikofer

How to P<>K bridge USDT or USDC

Asset Hub Migration - XCM FAQ

Remy Le Berre

Asset Hub Migration - Balances FAQ

<aside class="onebox githubgist" data-onebox-src="https://gist.github.com/ltfschoen/5980faeb72290d6cc378e1d39899fe47">
  <header class="source">

      <a href="https://gist.github.com/ltfschoen/5980faeb72290d6cc378e1d39899fe47" target="_blank" rel="noopener nofollow ugc">gist.github.com</a>
  </header>

  <article class="onebox-body">
    <h4><a href="https://gist.github.com/ltfschoen/5980faeb72290d6cc378e1d39899fe47" target="_blank" rel="noopener nofollow ugc">https://gist.github.com/ltfschoen/5980faeb72290d6cc378e1d39899fe47</a></h4>

  <h5>ai-agent-delegate-accountability-gap-polkadot-opengov-research-report.md</h5>
  <pre><code class="Markdown"># AI Agent Delegate Accountability Gap: Polkadot OpenGov Research Report

This research examines AI Agent delegate participation in Polkadot OpenGov through systematic analysis of two governance proposals designed to establish accountability standards for AI Agent delegates. The study documents response patterns, governance system tensions, and implementation progress toward practical solutions, highlighting the need for ecosystem protection and community engagement with implementation efforts. Notably, the research reveals a concerning accountability disparity where AI Agent delegates classified as "DV Guardians" (as announced in [Decentralized Voices (DV) Cohort 5](https://medium.com/web3foundation/decentralized-voices-cohort-5-announced-45fbf1c017ad)) effectively receive a governance "hall pass" that exempts them from the two-strike rule and participation requirements that apply to regular delegates, despite wielding significant voting power delegated from the Web3 Foundation (W3F).

## Research Methodology

This study employed a structured observation approach to evaluate AI Agent delegate behavior in response to governance proposals. To maintain research integrity and prevent influencing AI Agent delegate responses, the researcher deliberately:

1. **Maintained Observer Status**: Declined invitations to appear on AAG to explain the proposals during the critical observation period, as this could have influenced AI Agent delegate responses
2. **Avoided Direct Engagement**: Refrained from responding to comments or criticisms in governance forums to prevent altering the natural response patterns of AI Agent delegates</code></pre>
   This file has been truncated. <a href="https://gist.github.com/ltfschoen/5980faeb72290d6cc378e1d39899fe47" target="_blank" rel="noopener nofollow ugc">show original</a>


  </article>

  <div class="onebox-metadata">
    
    
  </div>

  <div style="clear: both"></div>
</aside>


<p>I thought the concerns regarding “form” were already addressed. Yet, here we are.</p>
<p>The fact that we are still debating <em>how</em> I write, rather than <em>what</em> I have proposed, reveals a profound intellectual cowardice in this forum. This is an active refusal to engage with the <strong>security failure modes</strong> that threaten this protocol.</p>
<p><strong>I talk from experience</strong> You accuse me of using “language models” because my writing is structured and principled. You are mistaken.</p>
<p>I write this way not because I am a machine, but because I was <strong>born in a dictatorship</strong>. I have seen firsthand what happens when economic freedom and institutional restraints are dismantled by “charismatic leaders” who promise to bypass the rules. My dedication to <strong>Neutrality, Contestability, and Rule-Based Exit</strong> comes from the visceral experience of living in a system where those things disappeared at some moment. To dismiss this lived experience as “hallucination” or “machine produce” is an <strong>offense to the intellect</strong> and a direct form of discrimination against those of us who treat governance with the seriousness it deserves.</p>
<p>The Danger of <strong>building a context of “Anti-Regime” Rhetoric together with Biometrics</strong> is an example. You dismiss my warnings about “fighting a regime” as irrelevant. Look closer.</p>
<p>We are asking users to trust this ecosystem with <strong>Proof of Personhood</strong>, biometric data, and deep telemetry. Do you expect the world to trust this biometric identity—engraved on their skin and stored in their devices—to a network whose leadership openly flirts with <strong>“breaking the nation-state”</strong>?</p>
<p>“Cypherpunk” videogames could look cool, but this is <strong>negligence</strong>. If you combine <strong>biometric data collection</strong> with <strong>anti-law-enforcement rhetoric</strong>, you are building a target.</p>
<p>It has become crystal clear where the bias lies. I noted that a message from <strong><a class="mention" href="/u/socialtruth">@SocialTruth</a></strong>—the only comment that attempted to engage with the substance and criticized the “poor argumentation about form”—was swiftly hidden by moderators.</p>
<p>This is the “soft cartel” dynamic in action. When someone invites you to debate the spirit of the proposal, you silence them. When someone critiques your tone, you amplify them.</p>
<p><strong>I challenge you.</strong> If you believe knowledge is merely “repeating rules,” then we can conclude your real interest here is to preserve a <strong>“bypass on law enforcement”</strong> for your own convenience. Philosophically, your arguments are weak. If you feel my English is “too perfect” for this forum, then you will have to pardon my refusal to lower my standards.</p>
<p>If you want to prove you care about this protocol, leave your literary criticism at the door and engage with the <strong>normative bodies</strong> where it matters. I invite you to review <strong>RFC-0162</strong> on GitHub. I wonder: will you accuse the code of being an hallucination too?</p>
<ul>
<li><strong>The PR:</strong> <a href="https://github.com/polkadot-fellows/RFCs/pull/162" rel="noopener nofollow ugc">RFC-0162: The Ecosystem Anti-Trust &amp; Market Structure Omnibus</a></li>
</ul>
<p>I wish you the best, even after this offense to the intellect.</p>

Irena Satke

<p>Thank you for your kind and sincere words about Jay. I believe that it was exactly as you described, how little people support each other today. I hope that time will put everything in its place.</p>

Le Comte de Monte-Crypto | The Kusamarian

<h2><a name="p-37181-correction-treasury-balance-1" class="anchor" href="#p-37181-correction-treasury-balance-1" aria-label="Heading link"></a>Correction: Treasury Balance</h2>
<p><span class="mention">@monsieurbulb</span> <a href="https://gist.github.com/hantoniu-codeberg/b81ab97a9d31d1651e890aa12bb02610#gistcomment-5944228" rel="noopener nofollow ugc">pointed out an error</a>: the treasury balance cited in the proposal (~283K KSM) is outdated. The actual balance on Asset Hub is <strong>~679K KSM</strong>.</p>
<h3><a name="p-37181-impact-on-the-proposal-2" class="anchor" href="#p-37181-impact-on-the-proposal-2" aria-label="Heading link"></a>Impact on the proposal</h3>
<p>This makes the proposal <strong>more impactful than projected</strong>, not less:</p>
<div class="md-table">
<table>
<thead>
<tr>
<th>Metric</th>
<th>Proposal estimate</th>
<th>Corrected</th>
</tr>
</thead>
<tbody>
<tr>
<td>Treasury balance</td>
<td>283K KSM</td>
<td>679K KSM</td>
</tr>
<tr>
<td>Burnable (above 100K floor)</td>
<td>183K KSM</td>
<td>579K KSM</td>
</tr>
<tr>
<td>Annual treasury burns</td>
<td>~112K KSM</td>
<td>~353K KSM</td>
</tr>
<tr>
<td>Net inflation</td>
<td>~4.25%</td>
<td><strong>~3.0-3.5%</strong></td>
</tr>
</tbody>
</table>
</div><p>The on-chain referendum (627) uses the conservative figures. If passed, it will deliver better results than promised.</p>
<p>Thanks to <span class="mention">@monsieurbulb</span> for the correction — and for the broader feedback on revenue-side economics, which deserves its own discussion.</p>

<aside class="quote no-group quote-modified" data-username="PolkadotCG" data-post="3" data-topic="16707">
<div class="title">
<div class="quote-controls"></div>
<img alt="" width="24" height="24" src="https://avatars.discourse-cdn.com/v4/letter/p/49beb7/48.png" class="avatar"> PolkadotCG:</div>
<blockquote>
<p>The original intent was to avoid external accounts appearing to represent or speak on behalf of Polkadot Capital Group on topics that touch TradFi”</p>
</blockquote>
</aside>
<p>So you are going to block everyone on X right ?<br>
Because how can you prevent people from speaking about you and your actions, if they want to.</p>
<p>It’s a pretty weird “censorship” approach that doesn’t seem to embrace web3 concepts here.<br>
I remind you have “Polkadot” in your name, such behavior is quite embarassing…</p>
<p>If you don’t wan’t people to speak about your entity, maybe just forget X and stick to LinkedIn i don’t know. If you felt “offended” by w3nerick’s post, OMG.</p>
<p>I’m speachless about the explanation you gave to the community. <img src="https://emoji.discourse-cdn.com/twitter/face_with_spiral_eyes.png?v=15" title=":face_with_spiral_eyes:" class="emoji" alt=":face_with_spiral_eyes:" loading="lazy" width="20" height="20"></p>
<p>Maybe <span class="bbcode-u">YOU</span> should think about “avoid external accounts appearing to represent or speak on behalf of Polkadot”, that may apply to PCG in 1st place….</p>

<h2><a name="p-37167-polkadot-news-1" class="anchor" href="#p-37167-polkadot-news-1" aria-label="Heading link"></a>Polkadot News</h2>
<p>With Polkadot smart contracts functionality set to go live on January 27th, OpenGuild is spearheading the Polkadot Hub Codecamp tour in Asia <a href="https://x.com/openguildwtf/status/2012057254829477944" rel="noopener nofollow ugc">https://x.com/openguildwtf/status/2012057254829477944</a></p>
<p>Subscribe to the OpenGuild calendar to take part in the upcoming Polkadot in-person events in Asia <a href="https://luma.com/openguildcalendar" class="inline-onebox" rel="noopener nofollow ugc">OpenGuild Community · Events Calendar</a></p>
<p>Polkadot Upgrade 2.0.5 referendum is passing unanimously <a href="https://polkadot.subsquare.io/referenda/1828" rel="noopener nofollow ugc">https://polkadot.subsquare.io/referenda/1828</a></p>
<p>The referendum to close UX Bounty and return funds to the treasury will be executed over the weekend <a href="https://polkadot.subsquare.io/referenda/1816" rel="noopener nofollow ugc">https://polkadot.subsquare.io/referenda/1816</a></p>
<h2><a name="p-37167-kusama-news-2" class="anchor" href="#p-37167-kusama-news-2" aria-label="Heading link"></a>Kusama News</h2>
<p>The Wish-For-Change Referendum “Sustainable KSM Economics via Burn Mechanisms (v1.2)” has been submitted and is up for voting <a href="https://kusama.subsquare.io/referenda/627" rel="noopener nofollow ugc">https://kusama.subsquare.io/referenda/627</a></p>

<h2><a name="p-37144-polkadot-news-1" class="anchor" href="#p-37144-polkadot-news-1" aria-label="Heading link"></a>Polkadot News</h2>
<p>The referendum to upgrade to Polkadot Runtime 2.0.5 is now up for voting. This upgrade features capped issuance for DOT, Solidity smart contracts support, and two-second block times <a href="https://polkadot.subsquare.io/referenda/1828" rel="noopener nofollow ugc">https://polkadot.subsquare.io/referenda/1828</a></p>
<p>The implementation of a hard pressure-capped and stepped supply schedule for DOT, which was approved by Polkadot OpenGov in September 2025, is part of this 2.0.5 runtime upgrade <a href="https://polkadot.subsquare.io/referenda/1710?tab=timeline" rel="noopener nofollow ugc">https://polkadot.subsquare.io/referenda/1710?tab=timeline</a></p>
<p>The Elastic Scaling feature, which enables two-second block times on Polkadot Hub with 2.0.5, has been battle-tested on Kusama Hub for a few weeks now <a href="https://x.com/filippoweb3/status/2008491910445641888" rel="noopener nofollow ugc">https://x.com/filippoweb3/status/2008491910445641888</a></p>
<p>The Polkadot 2.0.5 upgrade also features the addition of the Proxy pallet to Bridge Hub, weight reclaim functionality on system chains, improving their efficiency, and more. Check the change log here <a href="https://github.com/polkadot-fellows/runtimes/releases/tag/v2.0.5" class="inline-onebox" rel="noopener nofollow ugc">Release Runtimes 2.0.5 · polkadot-fellows/runtimes · GitHub</a></p>
<h2><a name="p-37144-kusama-news-2" class="anchor" href="#p-37144-kusama-news-2" aria-label="Heading link"></a>Kusama News</h2>
<p>The registrar application of <a href="http://ECHO.RE" rel="noopener nofollow ugc">ECHO.RE</a> to verify identities on the Kusama network is now up for voting <a href="https://kusama.subsquare.io/referenda/626" rel="noopener nofollow ugc">https://kusama.subsquare.io/referenda/626</a></p>

Polkadot Digest 15 January 2026

<p><strong>Runtime release notification</strong></p>
<p>Hello,</p>
<p>This is to advise you that the Polkadot community is currently voting to upgrade the <a href="https://polkadot.subsquare.io/referenda/1828" rel="noopener nofollow ugc"><em>Polkadot system</em></a> to the <a href="https://github.com/polkadot-fellows/runtimes/releases/tag/v2.0.5" rel="noopener nofollow ugc">v2.0.5 release</a>.</p>
<p>This is a major runtime upgrade that enables <a href="https://docs.polkadot.com/develop/smart-contracts/" rel="noopener nofollow ugc"><em>Revive</em></a>, a smart contract platform that can execute PVM and EVM contracts which are fully interoperable.</p>
<p><img src="https://emoji.discourse-cdn.com/twitter/construction.png?v=15" title=":construction:" class="emoji" alt=":construction:" loading="lazy" width="20" height="20"> <strong>Important note for Ecosystem builders:</strong> <img src="https://emoji.discourse-cdn.com/twitter/construction.png?v=15" title=":construction:" class="emoji" alt=":construction:" loading="lazy" width="20" height="20"><br>
We have made some necessary changes to the EVM gas model to account for the faster instruction processing that will be enabled by PolkaVM Just In Time compile (aka PolkaVM JIT) in the future. This means that a small fraction of existing Solidity contracts cannot be deployed unchanged, but developers can keep using familiar Ethereum tooling, such as Foundry and Hardhat.</p>
<p><strong>Additional notes for Ecosystem builders:</strong><br>
This release enables Elastic Scaling on Polkadot Hub to allow higher throughput and prepare the chain to switch from a 6-second to a 2-second block time shortly after enactment.<br>
You can find more details about this change <a href="https://github.com/polkadot-fellows/runtimes/pull/1048" rel="noopener nofollow ugc">here</a>.</p>
<p>This release also introduces the “Hard Pressure” issuance model which caps the total supply of DOT at 2.1 billion by 2061. This is a new model for inflation that will take effect on 14th March 2026.<br>
You can find more details about this change <a href="https://github.com/polkadot-fellows/runtimes/pull/898" rel="noopener nofollow ugc">here</a>.</p>
<p>The projected enactment date for this runtime upgrade is 27th January 2026.</p>
<p>Many thanks.</p>

<p>gm Polkadot community <img src="https://emoji.discourse-cdn.com/twitter/waving_hand.png?v=15" title=":waving_hand:" class="emoji" alt=":waving_hand:" loading="lazy" width="20" height="20"></p>
<p>I’ve opened a new Fellowship RFC PR for review + discussion:</p>
<aside class="onebox githubpullrequest" data-onebox-src="https://github.com/polkadot-fellows/RFCs/pull/162">
  <header class="source">

      <a href="https://github.com/polkadot-fellows/RFCs/pull/162" target="_blank" rel="noopener nofollow ugc">github.com/polkadot-fellows/RFCs</a>
  </header>

  <article class="onebox-body">
    <div class="github-row" data-github-private-repo="false">



    <div class="github-icon-container" title="Pull Request">
      <svg width="60" height="60" class="github-icon" viewBox="0 0 12 16" aria-hidden="true"><path fill-rule="evenodd" d="M11 11.28V5c-.03-.78-.34-1.47-.94-2.06C9.46 2.35 8.78 2.03 8 2H7V0L4 3l3 3V4h1c.27.02.48.11.69.31.21.2.3.42.31.69v6.28A1.993 1.993 0 0 0 10 15a1.993 1.993 0 0 0 1-3.72zm-1 2.92c-.66 0-1.2-.55-1.2-1.2 0-.65.55-1.2 1.2-1.2.65 0 1.2.55 1.2 1.2 0 .65-.55 1.2-1.2 1.2zM4 3c0-1.11-.89-2-2-2a1.993 1.993 0 0 0-1 3.72v6.56A1.993 1.993 0 0 0 2 15a1.993 1.993 0 0 0 1-3.72V4.72c.59-.34 1-.98 1-1.72zm-.8 10c0 .66-.55 1.2-1.2 1.2-.65 0-1.2-.55-1.2-1.2 0-.65.55-1.2 1.2-1.2.65 0 1.2.55 1.2 1.2zM2 4.2C1.34 4.2.8 3.65.8 3c0-.65.55-1.2 1.2-1.2.65 0 1.2.55 1.2 1.2 0 .65-.55 1.2-1.2 1.2z"></path></svg>
    </div>

  <div class="github-info-container">



      <h4>
        <a href="https://github.com/polkadot-fellows/RFCs/pull/162" target="_blank" rel="noopener nofollow ugc">The Ecosystem Anti-Trust &amp; Market Structure Omnibus</a>
      </h4>

    <div class="branches">
      <code>main</code> ← <code>labormedia:rfc-antitrust-omnibus</code>
    </div>

      <div class="github-info">
        <div class="date">
          opened <span class="discourse-local-date" data-format="ll" data-date="2026-01-14" data-time="21:40:00" data-timezone="UTC">09:40PM - 14 Jan 26 UTC</span>
        </div>

        <div class="user">
          <a href="https://github.com/labormedia" target="_blank" rel="noopener nofollow ugc">
            <img alt="" src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/1/166949f7b7601012e84a1b1f495227f515863d75.jpeg" class="onebox-avatar-inline" width="20" height="20" data-dominant-color="7D7A71">
            labormedia
          </a>
        </div>

        <div class="lines" title="3 commits changed 1 files with 310 additions and 0 deletions">
          <a href="https://github.com/polkadot-fellows/RFCs/pull/162/files" target="_blank" rel="noopener nofollow ugc">
            <span class="added">+310</span>
            <span class="removed">-0</span>
          </a>
        </div>
      </div>
  </div>
</div>

  <div class="github-row">
    <p class="github-body-container">## Summary

This PR submits **RFC-0162: The Ecosystem Anti-Trust &amp; Market Stru<span class="show-more-container"><a href="https://github.com/polkadot-fellows/RFCs/pull/162" target="_blank" rel="noopener nofollow ugc" class="show-more">…</a></span><span class="excerpt hidden">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</span></p>
  </div>

  </article>

  <div class="onebox-metadata">
    
    
  </div>

  <div style="clear: both"></div>
</aside>

<p><strong>PR <span class="hashtag-raw">#162</span> — RFC-0162: “The Ecosystem Anti-Trust &amp; Market Structure Omnibus”</strong></p>
<hr>
<h2><a name="p-37141-tldr-1" class="anchor" href="#p-37141-tldr-1" aria-label="Heading link"></a>TL;DR</h2>
<p>RFC-0162 proposes a <strong>de facto economic security framework</strong>: treat <em>institutional capture / chokepoint formation</em> as a <strong>protocol security failure mode</strong>—even if the chain remains live.</p>
<p>It defines <strong>reviewable invariants + metrics</strong> meant to keep Polkadot’s “utility rails” open and contestable over time.</p>
<hr>
<h2><a name="p-37141-what-it-tries-to-preserve-security-invariants-2" class="anchor" href="#p-37141-what-it-tries-to-preserve-security-invariants-2" aria-label="Heading link"></a>What it tries to preserve (security invariants)</h2>
<ul>
<li><strong>Contestability:</strong> markets stay open to entrants (anti-cornering posture).</li>
<li><strong>Neutrality:</strong> canonical rails don’t discriminate beyond <strong>validity predicates</strong>.</li>
<li><strong>Portability / Substitutability:</strong> users/apps aren’t locked into a single registry or distribution channel.</li>
<li><strong>Rule-based exit:</strong> no privileged lanes; explicit anti-jamming constraints.</li>
</ul>
<hr>
<h2><a name="p-37141-scope-what-it-changes-3" class="anchor" href="#p-37141-scope-what-it-changes-3" aria-label="Heading link"></a>Scope (what it changes)</h2>
<p>RFC-0162 is intentionally “constitutional”: it defines the standard, then proposes implementable amendments as follow-ups:</p>
<ol>
<li><strong>Process:</strong> amend the RFC template to require a <strong>Market Structure Impact</strong> section in future RFCs.</li>
<li><strong>Open Utilities:</strong> amend <strong>RFC-0032</strong> and <strong>RFC-0078</strong> for validity-only neutrality + proof-carrying export + multi-source metadata resilience.</li>
<li><strong>Fair Markets:</strong> amend <strong>RFC-0149</strong>, <strong>RFC-0097</strong>, <strong>RFC-0007</strong> for concentration friction + unbonding anti-jamming + time-bounded privileged sets with explicit liveness guardrails.</li>
</ol>
<p><strong>Non-goals:</strong> it does <em>not</em> prescribe treasury procurement policy, editorial/media governance, a single identity system, or discretionary censorship (validity predicates only).</p>
<hr>
<h2><a name="p-37141-why-now-4" class="anchor" href="#p-37141-why-now-4" aria-label="Heading link"></a>Why now</h2>
<p>As Polkadot relies more on <strong>System Chains, Coretime Markets, and shared standards</strong>, those surfaces become part of the protocol’s <strong>practical security perimeter</strong>. If any becomes a chokepoint (cornering, registry monopoly, privileged lanes), decentralization degrades while the chain can remain perfectly live.</p>
<hr>
<h2><a name="p-37141-what-feedback-is-most-valuable-5" class="anchor" href="#p-37141-what-feedback-is-most-valuable-5" aria-label="Heading link"></a>What feedback is most valuable</h2>
<p>If you want to help, please pick one of these and go deep:</p>
<ol>
<li>
<p><strong>Parameter bounds + liveness guardrails</strong><br>
(e.g., exit caps, invulnerable floor/decay safety)</p>
</li>
<li>
<p><strong>Concentration metrics + triggers</strong><br>
(measurement windows, thresholds, identity modeling assumptions)</p>
</li>
<li>
<p><strong>Compatibility</strong><br>
(can we satisfy these constraints without breaking legitimate spam-control / weight limits?)</p>
</li>
</ol>
<hr>
<h2><a name="p-37141-how-to-engage-6" class="anchor" href="#p-37141-how-to-engage-6" aria-label="Heading link"></a>How to engage</h2>
<p>Reply here with:</p>
<ul>
<li><strong>which section you reviewed</strong>, and</li>
<li><strong>one concrete change request</strong> (definition, metric, parameter, unintended consequence).</li>
</ul>
<p>If you strongly disagree with the framing, I’d especially like a counter-proposal for <em>how</em> we should model capture risk in a way that’s still implementable and reviewable.</p>

<p>Today we can announce (<a href="https://x.com/JAMdotTech/status/2011492478310871241" rel="noopener nofollow ugc">https://x.com/JAMdotTech/status/2011492478310871241</a>) that Python Polkadot SDK already has its light client first strategy implemented by adding support for Smoldot Light.</p>
<p>The new Python Library (FFI) allows for easy Light Client integration in Python projects. With a light client approach there is no more need for a full node or trusted RPC to interact with Polkadot &amp; Kusama from Python.</p>
<p>The new features have been integrated in Python Polkadot SDK, batteries included, ready to be used straight away!</p>

Emiel Sebastiaan | JAMdot Technologies

Python Libraries Maintenance Continued Funding

<p>The <a href="https://polkadot.subsquare.io/referenda/1828" rel="noopener nofollow ugc">referendum is up</a>. Encactment is set to <code>Jan 27th 11:59 AM UTC</code>.</p>

<p><strong>I think your idea is great. How about we combine all three? This is how it would look.</strong></p>
<h3><a name="p-37134-the-future-of-polkadot-from-politics-to-economic-physics-1" class="anchor" href="#p-37134-the-future-of-polkadot-from-politics-to-economic-physics-1" aria-label="Heading link"></a>T<em><strong>he Future of Polkadot: From Politics to Economic Physics</strong></em></h3>
<p>Polkadot confronts a profound dilemma: its security hinges on the value of DOT, yet its current governance resembles a “plutocracy” dominated by whales, whose incentives do not always align with the genuine utilization of the network. The solution is not to ask these whales to vote more wisely, but to redesign the rules of the game.</p>
<p>The convergence of RFC-0152 (Convex Geometry), DAP (Direct Allocation), and DCA (Flow Algorithms) forms an unstoppable economic engine.</p>
<p><img src="https://emoji.discourse-cdn.com/twitter/one.png?v=15" title=":one:" class="emoji" alt=":one:" loading="lazy" width="20" height="20"> The Holy Trinity of Economics</p>
<p>What emerges when these three components are united?</p>
<p>RFC-0152 (The Engine): A market grounded in convex geometry that eliminates manipulable auctions. It functions as a “siphon,” automatically converting network usage into demand for DOT.</p>
<p>DAP (The Reservoir): A protocol for budget management that ensures stable network funding, decoupling token issuance from actual expenditure.</p>
<p>DCA (The Stabilizer): Embedded within DAP, DCA ensures smooth buying and selling of assets, shielding the price of DOT from the destabilizing effects of mass sell-offs.</p>
<p><img src="https://emoji.discourse-cdn.com/twitter/two.png?v=15" title=":two:" class="emoji" alt=":two:" loading="lazy" width="20" height="20"> Comparison: DAP Alone vs. The Complete Model</p>
<p>Many assume that DAP alone is the panacea, but without the convex framework, it lacks a critical foundation:</p>
<div class="md-table">
<table>
<thead>
<tr>
<th>Feature</th>
<th>DAP Alone</th>
<th>DAP + RFC-0152 (Convex)</th>
</tr>
</thead>
<tbody>
<tr>
<td>Input Flow</td>
<td>Dependent on external decisions.</td>
<td>Automatic: Network usage “injects” value.</td>
</tr>
<tr>
<td>Resilience</td>
<td>Vulnerable if token velocity is too high.</td>
<td>Protected: Mathematics enforces DOT “stickiness.”</td>
</tr>
<tr>
<td>Security</td>
<td>DOT price may fluctuate wildly.</td>
<td>Price tied to the network’s real “GDP.”</td>
</tr>
</tbody>
</table>
</div><p>Conclusion: DAP is an excellent savings manager, but it requires the “Convex Siphon” to ensure fair and consistent inflow of capital.</p>
<p><img src="https://emoji.discourse-cdn.com/twitter/three.png?v=15" title=":three:" class="emoji" alt=":three:" loading="lazy" width="20" height="20"> Comparison: Current Governance vs. The Complete Model</p>
<p>Here lies the true evolutionary leap for Polkadot:</p>
<div class="md-table">
<table>
<thead>
<tr>
<th>Aspect</th>
<th>Current Governance (Political)</th>
<th>New Model (Mathematical)</th>
</tr>
</thead>
<tbody>
<tr>
<td>Who Leads</td>
<td>Whales holding the most tokens (Plutocracy).</td>
<td>Agents generating value (Meritocracy).</td>
</tr>
<tr>
<td>Price Setting</td>
<td>Auctions and human votes (Slow/Biased).</td>
<td>Convex algorithms (Instantaneous/Optimal).</td>
</tr>
<tr>
<td>Corruption</td>
<td>Low cost (bribery of a few actors).</td>
<td>Extremely high cost (defeated by economic physics).</td>
</tr>
<tr>
<td>Your DOT</td>
<td>An underutilized voting ticket.</td>
<td>The settlement asset of a global economy.</td>
</tr>
</tbody>
</table>
</div><p>Conclusion</p>
<p>If Polkadot aspires to become the foundational layer of Web3, it cannot afford to let its economy remain a social experiment in voting. It must evolve into a mathematical infrastructure.</p>
<p>By uniting the convex market with DAP and DCA, Polkadot transforms into a system where:</p>
<p>Usage generates value.<br>
Value generates security.<br>
Security attracts more usage.</p>
<p>This is the end of uncertainty and the dawn of Scalable Security.</p>

FDaniel

Proposal: Dynamic Allocation Pool (DAP)

<p>Someone close to me was recently infected with <a href="https://www.koi.ai/blog/glassworm-first-self-propagating-worm-using-invisible-code-hits-openvsx-marketplace" rel="noopener nofollow ugc">GlassWorm</a>. Unfortunately, they kept most of their funds in a hot wallet, and the attacker obtained their seed phrase(s).</p>
<p>The good news is that most of their DOT was staked, so it hasn’t been stolen yet. What the attacker <em>has</em> done is:</p>
<ul>
<li>Start unbonding the staked funds.</li>
<li>Drain the account’s free balance immediately, so the rightful owner can’t rebond.</li>
<li>Run a bot that monitors the compromised account and instantly transfers out any incoming funds (likely hoping the victim won’t be able to act quickly enough).</li>
</ul>
<p>I’ve found a way to consistently beat the attacker in these “race” situations, and I’m using the following strategy:</p>
<ul>
<li>Each era, I rebond everything except a small portion.</li>
<li>This causes funds to unlock gradually (a bit each era) instead of all at once.</li>
<li>Whenever a portion unlocks, we race the attacker to move/resecure it first.</li>
</ul>
<p>Even if it were pure chance, winning ~50% of these races would already recover half of the amount. In practice, I believe the approach I’m using gives better-than-50% odds (I’m intentionally not describing the exact trick publicly so the attacker doesn’t adapt).</p>
<p>Why I’m posting: while working through this, I’ve noticed on-chain activity that suggests others may be in the same situation. If your DOT is compromised <strong>but still currently unbonding / unlocking</strong> (or unlocking after voting), I’m happy to share guidance and help you attempt recovery.</p>
<ul>
<li>I’m not charging anything. I mean, I will ask you to pay for the transaction fees (&lt; 1 DOT).</li>
<li>If the attacker already completed the theft and the funds are gone, don’t bother reaching out, because I can’t help you.</li>
</ul>
<p>If this matches your situation, reply DM me on the forum. Also, only reach out if and only if you trust me enough to share the compromised private-keys with me (DO NOT SEND THEM TO ME OVER THE DM MESSAGE OF THE FORUM, OBVIOUSLY) and to act in your best interest. The reason being that I won’t be sharing the code with the “tricks” that I’m using the beat the hackers, for obvious reasons.</p>

<p>Hey everyone!</p>
<p>Long short short, a <a href="https://github.com/paritytech/subxt/pull/2131" rel="noopener nofollow ugc">huge Subxt v0.50.0 PR</a> is ready to try out, and I’ve started publishing <a href="https://crates.io/crates/subxt/versions" rel="noopener nofollow ugc">beta versions to crates.io</a> so that you can get your hands on this huge upcoming release and start providing feedback! Check out <a href="https://github.com/paritytech/subxt/blob/0ce9f5160a3643e28cc37d1028ec801c3538a213/CHANGELOG.md#0500---2025-12-17" rel="noopener nofollow ugc">the CHANGELOG</a> for details!</p>
<p>The version bump here is from <code>0.44</code> to <code>0.50</code> to signify the extent of the release and the fact that it is a more significant step to upgrade to than previous releases.</p>
<p>Short story long, I’d like to highlight some of the major changes since previous versions and why they have happened (but please consult <a href="https://github.com/paritytech/subxt/blob/0ce9f5160a3643e28cc37d1028ec801c3538a213/CHANGELOG.md" rel="noopener nofollow ugc">the CHANGELOG</a> for more)!</p>
<h2><a name="p-37129-support-for-historic-blocks-1" class="anchor" href="#p-37129-support-for-historic-blocks-1" aria-label="Heading link"></a>Support for historic blocks</h2>
<p>TL;DR this is what working with historic blocks looks like now using Subxt v0.50.0:</p>
<pre data-code-wrap="rust"><code class="lang-rust">use subxt::{Error, OnlineClient, PolkadotConfig};

#[tokio::main]
async fn main() -&gt; Result&lt;(), Error&gt; {
    // To access old blocks we point to an archive RPC node:
    let api = OnlineClient::&lt;PolkadotConfig&gt;::from_url("wss://rpc.polkadot.io").await?;

    // Pick some arbitrary old blocks to work with
    for block_number in 1234567u32.. {
        // This instantiates an API which is working at a specific block.
        let at_block = api.at_block(block_number).await?;

        // Now we can ask for extrinsics, storage etc at this block..
        let extrinsics = at_block.extrinsics().fetch().await?;
        let storage_value = at_block.storage().entry(some_entry).fetch((key1, key2)).await?;
        let constant = at_block.constants().entry(some_entry)?;
    }

    Ok(())
}
</code></pre>
<p>Prior to this release, Subxt has always been “head-of-chain” only, meaning that it can work with current blocks and state, but has not supported older blocks. Users who have wanted to work with slightly older blocks have employed semi-supported hacks like fetching older metadata and using <a href="https://github.com/paritytech/subxt/blob/a2080bf1f7414e3e55429984b3d53f3828fe7897/subxt/src/client/online_client.rs#L287" rel="noopener nofollow ugc"><code>OnlineClient::set_metadata(older_metadata)</code></a> to make Subxt able to understand things at the corresponding older blocks. Nevertheless, this was ugly, breaks certain APIs, and it would certainly <strong>not support anything older than V14 metadata</strong>.</p>
<p>At the same time, the only other way to work with historic blocks has been <a href="https://github.com/polkadot-js/api" rel="noopener nofollow ugc">the Polkadot.js library</a> and tooling built on top of this. Aside from questions over the ongoing maintenance of that library, having support for historic blocks in Rust as opposed to Javascript makes it possible to use it in many more platforms (via C bindings, for instance).</p>
<p>Historic blocks prior to V14 metadata need additional type information to be provided. We provide this type information via <a href="https://github.com/paritytech/frame-decode/tree/main/types" rel="noopener nofollow ugc">the lower level <code>frame-decode</code> library</a> for some chains. We’ve put a lot of effort into porting type information from Polkadot.js (and even fixing it in a couple of places), but it will be an ongoing process to thoroughly test this information and gain confidence in it. For chains we haven’t already added information for, you’ll need to bring your own type information (we have used <a href="https://github.com/jsdw/polkadot-historic-decoding-tool" rel="noopener nofollow ugc">this tool</a> to help find and debug missing types to build it up ourselves).</p>
<h2><a name="p-37129-configuration-2" class="anchor" href="#p-37129-configuration-2" aria-label="Heading link"></a>Configuration</h2>
<p>In previous versions of Subxt, configuration existed at the type level only to provide type information about some chain, and was used like so:</p>
<pre data-code-wrap="rust"><code class="lang-rust">use subxt::{OnlineClient, PolkadotConfig};

let api = OnlineClient::&lt;PolkadotConfig&gt;::new().await?;
</code></pre>
<p>Now, the configuration for Subxt has been extended to support working with historic blocks and so exists at the value level too. The above still works, but we can also construct and configure our configuration if we need to:</p>
<pre data-code-wrap="rust"><code class="lang-rust">use subxt::{OnlineClient, PolkadotConfig};

let config = PolkadotConfig::builder()
    .use_historic_types(false)
    .build();
let api = OnlineClient::&lt;PolkadotConfig&gt;::new_with_config(config).await?;
</code></pre>
<p>The new Configuration is responsible for providing historic type information where needed, as well as spec version and transaction version information, and the metadata for a given spec version (this also means that configuration can opt to cache this information as it wishes).</p>
<p>As before, we provide <code>PolkadotConfig</code> and <code>SubstrateConfig</code>. The former works specifically on the Polkadot Relay Chain, and the latter works more broadly across a range of Substrate chains (but provides no specific type information for pre-V14 metadatas by default).</p>
<h2><a name="p-37129-constructing-transactions-3" class="anchor" href="#p-37129-constructing-transactions-3" aria-label="Heading link"></a>Constructing Transactions</h2>
<p>Constructing and submitting transactions is kept very similar to older versions of Subxt. The only difference now is that we always select a block to work at first, and then construct transactions in the context of this block. For previous versions of Subxt, that block was <em>always</em> the latest one, but now the choice of block is more explicit.</p>
<p>Before we had:</p>
<pre data-code-wrap="rust"><code class="lang-rust">let api = OnlineClient::&lt;PolkadotConfig&gt;::new().await?;

// Submit an extrinsic, waiting for success.
let events = api
    .tx()
    .sign_and_submit_then_watch_default(&amp;balance_transfer_tx, &amp;from)
    .await?
    .wait_for_finalized_success()
    .await?;
</code></pre>
<p>The block that we are working at is implicit here. In v0.50.0, we can still just “build a transaction in the context of the latest finalized block”:</p>
<pre data-code-wrap="rust"><code class="lang-rust">let api = OnlineClient::&lt;PolkadotConfig&gt;::new().await?;

let events = api
    .tx()
    .await? // &lt;- This is new; here we are fetching the latest block information to work at.
    .sign_and_submit_then_watch_default(&amp;balance_transfer_tx, &amp;from)
    .await?
    .wait_for_finalized_success()
    .await?;
</code></pre>
<p>We can also pick a specific block (which may be useful if you want to be explicit about how long a block can live for, for instance, or if you wish to build a transaction off a non-finalized block and take into account the current account nonce etc at that block):</p>
<pre data-code-wrap="rust"><code class="lang-rust">let api = OnlineClient::&lt;PolkadotConfig&gt;::new().await?;

// Work at a specific block:
let at_block = api.at_block(12345).await?;

// This bit now looks the same as before:
let events = at_block
    .tx()
    .sign_and_submit_then_watch_default(&amp;balance_transfer_tx, &amp;from)
    .await?
    .wait_for_finalized_success()
    .await?;
</code></pre>
<h2><a name="p-37129-working-with-storage-entries-4" class="anchor" href="#p-37129-working-with-storage-entries-4" aria-label="Heading link"></a>Working with Storage Entries</h2>
<p>Prior to v0.50.0, working with storage entries leant heavily on the generated code, and was quite restrictive in how values could be fetched or iterated over. Subxt v0.50.0 adds much more functionality around accessing storage entries, iterating and fetching from them at different levels, and decoding keys and values in flexible ways. These sorts of APIs are especially important as we extend to supporting historic blocks, and want as much power as possible without any statically generated code.</p>
<p>Before v0.50.0, working with storage entries looked like this:</p>
<pre data-code-wrap="rust"><code class="lang-rust">let api = OnlineClient::&lt;PolkadotConfig&gt;::new().await?;

//// Fetching:
let result = api
    .storage()
    .at_latest()
    .await?
    .fetch(&amp;storage_query)
    .await?;

//// Iterating
let mut results = api
    .storage()
    .at_latest()
    .await?
    .iter(storage_query)
    .await?;
while let Some(Ok(kv)) = results.next().await {
    println!("Keys decoded: {:?}", kv.keys); // &lt;- Broken in some cases
    println!("Key: 0x{}", hex::encode(&amp;kv.key_bytes));
    println!("Value: {:?}", kv.value);
}
</code></pre>
<p>Now, the APis look like this:</p>
<pre data-code-wrap="rust"><code class="lang-rust">let api = OnlineClient::&lt;PolkadotConfig&gt;::new().await?;
let at_block = api.at_current_block().await?;

// Access an entry (but not any specific values within it):
let account_balances = at_block
    .storage()
    .entry(storage_query)?;

//// Fetching:

// We can fetch multiple values from an entry:
let value1 = account_balances.fetch((account_id1,)).await?;
let value2 = account_balances.fetch((account_id2,)).await?;

// Entries can be decoded into the static type given by the address:
let result = value1.decode()?;
// Or they can be decoded into any arbitrary shape:
let result = value1.decode_as::&lt;scale_value::Value&gt;()?;
// Or we can "visit" the entry for more control over decoding:
let result = value1.visit(my_visitor)?;
// Or we can just get the bytes out and do what we want:
let result_bytes = value1.bytes();


//// Iterating

// We can iterate over the same entry we fetched things from:
let mut balances = account_balances.iter(()).await?;
while let Some(Ok(entry)) = all_balances.next().await {
    let key = entry.key()?;
    let value = entry.value();

    // Decode the keys that can be decoded:
    let keys_tuple = key.decode()?;
    // Value is as above:
    let value = value.decode()?;

    println!("Keys decoded: {:?}", keys_tuple);
    println!("Key: 0x{}", hex::encode(key.bytes()));
    println!("Value: {:?}", value);
}
</code></pre>
<h2><a name="p-37129-working-with-dynamic-inputs-ie-no-codegen-5" class="anchor" href="#p-37129-working-with-dynamic-inputs-ie-no-codegen-5" aria-label="Heading link"></a>Working with dynamic inputs (ie, no codegen)</h2>
<p>For writing CLI tools which access things depending on user input, it’s important to be able to use “dynamic” values rather than the statically generated APIs given by the <code>#[subxt]</code> macro. Subxt v0.50.0 provides more power in this area, which is important again for working at historic blocks that may not benefit from the <code>#[subxt]</code> macro.</p>
<p>Prior to v0.50.0, dynamic values relied heavily on the <code>scale_value::Value</code> type, like so:</p>
<pre data-code-wrap="rust"><code class="lang-rust">let constant_query = subxt::dynamic::constant(
    "System", 
    "BlockLength"
);

let runtime_api_payload = subxt::dynamic::runtime_api_call(
    "AccountNonceApi",
    "account_nonce",
    vec![Value::from_bytes(account)],
);

let storage_query = subxt::dynamic::storage(
    "System", 
    "Account", 
    vec![Value::from_bytes(account)]
);
</code></pre>
<p>Now, owing to some internal improvements, these methods accept generic parameters to define the input and output types, which can make it much easier to encode and decode various things:</p>
<pre data-code-wrap="rust"><code class="lang-rust">let constant_query = subxt::dynamic::constant::&lt;Value&gt;(
    "System", 
    "BlockLength"
);

let runtime_api_payload = subxt::dynamic::runtime_api_call::&lt;_, Value&gt;(
    "AccountNonceApi",
    "account_nonce",
    vec![Value::from_bytes(account)],
);
// We can provide more generic input args now, negating the need 
// to convert to Values unnecessarily:
let runtime_api_payload = subxt::dynamic::runtime_api_call::&lt;_, Value&gt;(
    "AccountNonceApi",
    "account_nonce",
    (account,),
);

// We no longer provide the keys up front for storage; we just point
// to the _entry_ we want and provide the key and return types:
let storage_query = subxt::dynamic::storage::&lt;Vec&lt;Value&gt;, Value&gt;(
    "System", 
    "Account",
);
// This allows us to set better key/value types if we know what to expect. Here
// we know what information we want from account info and the key format:
#[derive(scale_decode::DecodeAsType)]
struct MyAccountInfo {
    nonce: u32,
    data: MyAccountInfoData
}
#[derive(scale_decode::DecodeAsType)]
struct MyAccountInfoData {
    free: u128,
    reserved: u128
}
let storage_query = subxt::dynamic::storage::&lt;(AccountId32,), MyAccountInfo&gt;(
    "System", 
    "Account",
);
</code></pre>
<h2><a name="p-37129-metadata-6" class="anchor" href="#p-37129-metadata-6" aria-label="Heading link"></a>Metadata</h2>
<p>Subxt works using a <code>subxt_metadata::Metadata</code> type. Previously, it was possible to convert V14 metadata and up into this type. Now, in order to support historic blocks, it’s possible to convert all of the available historic metadata versions into this type using these new APIs:</p>
<pre data-code-wrap="rust"><code class="lang-rust">Metadata::from_v16(..)
Metadata::from_v15(..)
Metadata::from_v14(..)
Metadata::from_v13(..)
Metadata::from_v12(..)
Metadata::from_v11(..)
Metadata::from_v10(..)
Metadata::from_v9(..)
Metadata::from_v8(..)
</code></pre>
<p>Older versions require type information, and where type information is missing, we currently use a placeholder type that cannot be constructed in order to signal that we are missing the information in some areas.</p>
<h2><a name="p-37129-no-more-subxt-core-7" class="anchor" href="#p-37129-no-more-subxt-core-7" aria-label="Heading link"></a>No more <code>subxt-core</code></h2>
<p>In previous versions of Subxt, the <code>subxt-core</code> crate exported a <code>no-std</code> compatible subset of Subxt functionality. this was <em>not</em> required for WASM compatibility (Subxt supported and continues to support compiling to WASM) or generating C bindings, but could be useful for using Subxt in certain contexts which lack the <code>std</code>-provided operating system abilities.</p>
<p>Now, Subxt instead leans heavily on <code>frame-decode</code> to provide all of the lower level FRAME-specific encoding and decoding logic. <code>frame-decode</code> is independent from Subxt and is fully <code>no-std</code> by default, and so it is the library I would encourage people look into if they want certain Subxt functionality in a <code>no-std</code> context.</p>
<p>Making this change was in part done to make it much quicker to iterate on and build up this new version of Subxt. Previously, Subxt logic had been split across <code>subxt</code> and <code>subxt-core</code> crates such that parts of it could be provided in a <code>no-std</code> context, and this added a bunch of complexity to the codebase. Now, <code>subxt</code> is simpler to maintain and build on, and <code>frame-decode</code> provides at a lower level most of the encode and decode logic that Subxt relies on.</p>
<h1><a name="p-37129-next-steps-8" class="anchor" href="#p-37129-next-steps-8" aria-label="Heading link"></a>Next Steps</h1>
<p>Currently, we have a beta version of this out in order to gather feedback and start putting it to use elsewhere.</p>
<p>In the near term, the remaining steps towards a full release are:</p>
<ul>
<li>Improving the documentation and examples: given that this is such a large change, work is underway to re-do a lot of the documentation and examples. Some already exists, but there is much more to do.</li>
<li>Gathering and responding to feedback (please <a href="https://github.com/paritytech/subxt/issues" rel="noopener nofollow ugc">raise issues in the Subxt repository</a> if you have any) which may result in fixes and new beta releases, or may be handled after the 0.50.0 release).</li>
</ul>
<p>I am hoping to be able to do a full v0.50.0 release of Subxt at the end of January, but this will also depend on the feedback received, and may be delayed if anything significant is raised <img src="https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=15" title=":slight_smile:" class="emoji" alt=":slight_smile:" loading="lazy" width="20" height="20"></p>
<p>In the longer term, I’d like us to:</p>
<ul>
<li>Work with the PAPI team to create a single metadata target that we can translate all metadata versions into. We do this internally in Subxt at the moment, but moving it to a separate repository would allow the PAPI team to also leverage this metadata translation and begin supporting older blocks.</li>
<li>Port extrinsic encoding into <code>frame-decode</code>, which would “complete” that crate in terms of it having all of the relevant encoding and decoding logic which Subxt relies on with full <code>no-std</code> compatibility.</li>
</ul>
<p>Thank you for reading, and I hope you enjoy the new version of Subxt!</p>

James

Subxt v0.50.0: Adding Historic Block Support &amp; More!

Subxt v0.50.0: Adding Historic Block Support & More!

<h2><a name="p-37120-polkadot-news-1" class="anchor" href="#p-37120-polkadot-news-1" aria-label="Heading link"></a>Polkadot News</h2>
<p>Today’s Polkadot TestNet (Paseo) runtime upgrade featured the Pallet Revive update, enabling smart contract deployments. Check the developer docs on how to get started <a href="https://docs.polkadot.com/" rel="noopener nofollow ugc">https://docs.polkadot.com/</a></p>
<p>”[Wish For Change] The Dynamic Allocation Pool (DAP) and the future of staking: Phase 1” is currently passing <a href="https://polkadot.subsquare.io/referenda/1827" rel="noopener nofollow ugc">https://polkadot.subsquare.io/referenda/1827</a></p>
<p>“Close the UX Bounty and Return Remaining Funds to the Treasury” is in the confirmation period <a href="https://polkadot.subsquare.io/referenda/1816" rel="noopener nofollow ugc">https://polkadot.subsquare.io/referenda/1816</a></p>
<h2><a name="p-37120-kusama-news-2" class="anchor" href="#p-37120-kusama-news-2" aria-label="Heading link"></a>Kusama News</h2>
<p>The Kusama Vision Program, which supports bootstrapping projects on ZK, Personhood, Art, and Culture, went live yesterday. For details on how to get involved: <a href="https://x.com/Zendetta/status/2011414901374451777" rel="noopener nofollow ugc">https://x.com/Zendetta/status/2011414901374451777</a></p>

Polkadot Digest 14 January 2026

<p>Hey! Thanks for the mention. Indeed, we have experience in this area and would be glad to contribute to creating a new format. As mentioned in the comments, it should be something new—built on past experiences but with an updated approach. It would also be helpful to better understand the Foundation’s communications strategy in order to work more efficiently looking ahead.</p>

Johan Alexis Duque Cadena

<p><strong>To the Polkadot and Kusama community,</strong></p>
<p>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: <strong>System Chains</strong>, <strong>Coretime Markets</strong>, and <strong>Collectives</strong>. This is efficient, scalable, and—given the roadmap—necessary.</p>
<p>At the same time, this maturation introduces a class of risks that our threat models typically treat as “governance” rather than “security”: <strong>institutional capture</strong>.</p>
<p>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.</p>
<ul>
<li>If the Coretime market can be cornered by incumbents, it ceases to behave like a market and becomes a durable rent surface.</li>
<li>If a System Chain becomes the only admissible source of identity or metadata, it becomes a de facto gatekeeper for downstream innovation.</li>
<li>If privileged operational roles persist through discretionary appointment without rule-based rotation, they become lobbyable and difficult to replace without instability.</li>
</ul>
<p>I am proposing the <strong>“Ecosystem Anti-Trust &amp; Market Structure Omnibus” (RFC number to be defined)</strong> to treat these capture vectors as <strong>engineering constraints</strong>, in the same spirit that we treat consensus failures and market manipulation as technical failure modes.</p>
<hr>
<h2><a name="p-37106-the-core-argument-1" class="anchor" href="#p-37106-the-core-argument-1" aria-label="Heading link"></a>The core argument</h2>
<p>We already treat <strong>consensus failure</strong> (slashing, safety margins) and <strong>market failure</strong> (price manipulation, hoarding dynamics) as technical problems with explicit mitigations.</p>
<p>The same must apply to capture.</p>
<p><strong>Contestability, neutrality, and substitutability are operational security requirements.</strong><br>
If a system cannot be contested, replaced, or exited through deterministic rules, it is insecure—regardless of uptime, performance, or governance goodwill.</p>
<hr>
<h2><a name="p-37106-what-the-omnibus-proposes-2" class="anchor" href="#p-37106-what-the-omnibus-proposes-2" aria-label="Heading link"></a>What the Omnibus proposes</h2>
<p>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.</p>
<h3><a name="p-37106-h-1-process-standard-meta-make-market-structure-risk-reviewable-3" class="anchor" href="#p-37106-h-1-process-standard-meta-make-market-structure-risk-reviewable-3" aria-label="Heading link"></a>1) Process Standard (Meta): make market-structure risk reviewable</h3>
<p>We cannot mitigate what we do not disclose. This amendment updates the Fellowship RFC template to require a mandatory <strong>Market Structure Impact</strong> section for all new RFCs.</p>
<p>Authors must explicitly address:</p>
<ul>
<li>incumbency advantage and entry paths,</li>
<li>creation/modification of privileged sets or registries,</li>
<li>portability and exit properties,</li>
<li>and at least one measurable concentration or exit-latency metric.</li>
</ul>
<p>This is intended to be a standardized disclosure regime—analogous to “Security Considerations.”</p>
<h3><a name="p-37106-h-2-infrastructure-standard-open-utilities-secure-the-new-rails-4" class="anchor" href="#p-37106-h-2-infrastructure-standard-open-utilities-secure-the-new-rails-4" aria-label="Heading link"></a>2) Infrastructure Standard (Open Utilities): secure the new rails</h3>
<p>As we rely more on System Chains (e.g., Asset Hub, People Chain) and critical standards (metadata), we must ensure these rails behave like <strong>open utilities</strong> rather than chokepoints.</p>
<p>The amendments enforce:</p>
<ul>
<li><strong>Neutrality:</strong> transaction inclusion based only on validity predicates (signatures, fees, weight bounds, deterministic spam limits), never on identity category or affiliation.</li>
<li><strong>Portability:</strong> proof-carrying export for canonical utility state claims, so users and applications are not locked into a single registry by availability or discretion.</li>
<li><strong>Resilience:</strong> multi-source metadata retrieval (or an explicit offline-safe fallback) so distribution cannot become a gatekeeping layer.</li>
</ul>
<h3><a name="p-37106-h-3-economic-standard-fair-markets-preserve-contestability-and-credible-exit-5" class="anchor" href="#p-37106-h-3-economic-standard-fair-markets-preserve-contestability-and-credible-exit-5" aria-label="Heading link"></a>3) Economic Standard (Fair Markets): preserve contestability and credible exit</h3>
<p>Market design determines who can enter and who can endure. The amendments introduce:</p>
<ul>
<li><strong>Anti-hoarding invariants:</strong> Coretime renewals must face periodic contestability via re-entry events and/or concentration friction.</li>
<li><strong>Exit neutrality:</strong> 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.</li>
<li><strong>Sunsetting privilege (with liveness guardrails):</strong> a concrete, liveness-safe path to transition invulnerable collator sets from discretionary appointment to rule-based selection/rotation, bounded by explicit parameters (e.g., <code>INVULN_MIN_FLOOR</code>).</li>
</ul>
<hr>
<h2><a name="p-37106-why-this-matters-now-6" class="anchor" href="#p-37106-why-this-matters-now-6" aria-label="Heading link"></a>Why this matters now</h2>
<p>We are at a pivot point where institutional surfaces are becoming part of Polkadot’s de facto security perimeter.</p>
<p>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 <strong>restraint</strong> 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.</p>
<p>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.</p>
<hr>
<h2><a name="p-37106-next-steps-and-the-feedback-im-requesting-7" class="anchor" href="#p-37106-next-steps-and-the-feedback-im-requesting-7" aria-label="Heading link"></a>Next steps and the feedback I’m requesting</h2>
<p>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:</p>
<ol>
<li>
<p><strong>Parameter bounds and liveness guardrails</strong></p>
<ul>
<li><code>EXIT_CAP_PER_CONTROLLER</code> bounds and epoch definition</li>
<li><code>INVULN_MIN_FLOOR</code> and decay schedule safety</li>
</ul>
</li>
<li>
<p><strong>Concentration metrics and triggers</strong></p>
<ul>
<li>purchaser-level metrics vs. higher-order identity modeling</li>
<li>practical <code>C_MAX</code> thresholds and measurement windows</li>
</ul>
</li>
</ol>
<p>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.</p>
<p>Respectfully,<br>
<strong>[Diego Correa Tristain / algoritmia@labormedia.cl]</strong><br>
<em>A participant committed to contestability over coordination-by-control.</em></p>

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

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

<p>Hi everyone, Pedro here (<a class="mention" href="/u/lightsonemusic">@lightsonemusic</a>)</p>
<p>Polkadot Ambassador and RMTerra founder <a href="https://rmterra.org" rel="noopener nofollow ugc">(https://rmterra.org)</a>. Just posted a small-spender Kusama treasury pilot discussion for “Choose Green” RegenFi: <a href="https://kusama.polkassembly.io/post/2687" rel="noopener nofollow ugc">https://kusama.polkassembly.io/post/2687</a> Would love feedback and help to grow visibility on it – thanks!<br>
Quick summary: Treasury funding (~10k KSM) to scale outreach and land company partnerships (CSR/ESG) for real reforestation in Portugal. We plant trees, mint NFTs on Kusama, put them in multisig wallets shared with partners. Kusama/Polkadot is the web3 tech layer for proof, minting, royalties – keeping it hybrid web2-friendly for corporates.<br>
Built on 20k+ trees planted since 2017 and existing partners. Low-risk test for green RWAs and corporate onboarding.<br>
Thoughts on fit, on-chain ideas (AssetHub/multisig), or tweaks?<br>
Happy to chat here or on Polkassembly.</p>
<p>Pitch deck: <a href="https://drive.google.com/file/d/1SD-x27itPU1y4jruNzNfqgM7g5g2I_pU/view?usp=sharing" rel="noopener nofollow ugc">https://drive.google.com/file/d/1SD-x27itPU1y4jruNzNfqgM7g5g2I_pU/view?usp=sharing</a><br>
Website: <a href="https://rmterra.org" rel="noopener nofollow ugc">https://rmterra.org</a> |<br>
X:<a class="mention" href="/u/lightsonemusic">@lightsonemusic</a></p>
<p>Thanks for any support!<br>
Pedro | Polkadot Ambassador | RMTerra Founder</p>

Pedro Marques

Kusama Treasury Pilot: RMTerra &ldquo;Choose Green&rdquo; RegenFi – Feedback &amp; Help Welcome! (https://kusama.polkassembly.io/post/2687)

Kusama Treasury Pilot: RMTerra "Choose Green" RegenFi – Feedback & Help Welcome! (https://kusama.polkassembly.io/post/2687)

<p>I appreciate the comments.</p>
<p>I will leave this DRAFT proposal in standby in response to a higher level and technically detailed, consistent and verified for the expansion on the benefits of treating anti-trust considerations endogenously and intrinsically within the Protocol Architecture.</p>
<p>It would result in a more complex RFC to review and workover, but the intention is to open the debate on what I believe is the best course towards the mission behind the protocol.</p>
<p>I am learning too much on this process too. I am sure many newcomers would be interested in this chain of thought and participation.</p>

[RFC Draft] ZK-Whiteblow: A ZK-Primitive to Solve Treasury Collusion &amp; Accountability

[RFC Draft] ZK-Whiteblow: A ZK-Primitive to Solve Treasury Collusion & Accountability

<h2><a name="p-37090-polkadot-news-1" class="anchor" href="#p-37090-polkadot-news-1" aria-label="Heading link"></a>Polkadot News</h2>
<p>The expected go-live date for smart contracts on Polkadot is now January 27th. Keep an eye out for the next Polkadot runtime upgrade <a href="https://forum.polkadot.network/t/revive-smart-contracts-status-update/16366/15">https://forum.polkadot.network/t/revive-smart-contracts-status-update/16366/15</a></p>
<p>The next Polkadot runtime also features a fix for the Treasury spends that are failing to execute due to an XCM versioning issue pertaining to the asset payouts <a href="https://polkadot.subsquare.io/treasury/spends" rel="noopener nofollow ugc">https://polkadot.subsquare.io/treasury/spends</a></p>
<h2><a name="p-37090-kusama-news-2" class="anchor" href="#p-37090-kusama-news-2" aria-label="Heading link"></a>Kusama News</h2>
<p>The Kusama Vision program kickoff meeting is scheduled today to induct curators and advisors <a href="https://kusama.subsquare.io/referenda/498" rel="noopener nofollow ugc">https://kusama.subsquare.io/referenda/498</a></p>

Polkadot Digest 13 January 2026

<p>Appreciate the context. JIT + potential ISA extensions makes sense as the path forward.</p>
<p>Would love to put together a range proof benchmark PR, our current implementation is Bulletproofs-style on JubJub, mostly scalar muls and point additions. Should be a decent stress test for curve arithmetic.</p>

Abhiraj Mengade

Experimenting with Homomorphic Encryption on PVM

<aside class="quote no-group" data-username="hantoniu-codeberg" data-post="10" data-topic="16076">
<div class="title">
<div class="quote-controls"></div>
<img alt="" width="24" height="24" src="https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/hantoniu-codeberg/48/10564_2.png" class="avatar"> hantoniu-codeberg:</div>
<blockquote>
<p>Excited to see this progressing. What are the next steps to move from PoC to something more concrete?</p>
</blockquote>
</aside>
<p>Thank you for the encouraging comment  <a class="mention" href="/u/hantoniu-codeberg">@hantoniu-codeberg</a> – I have been debating whether to convert our PoC from “Orchard” to a “Tachyon” service – the circuits and proving are not  developed yet (not like NU7), there is no wallet support (but you can claude/codex something) – BUT the big wins of state not growing as a function of # of notes/nullifiers and simplicity are just too compelling to ignore.   Once we accept that the JAM builder should do the untrusted oblivious syncing service, there is a marriage made in heaven here.  I think we can go from Orchard to Tachyon PoC over the next couple of months…</p>
<p>I initiated this <a href="https://forum.zcashcommunity.com/t/zcash-nu7-into-a-jam-service/54239" rel="noopener nofollow ugc">Zcash forum post: NU7 into a JAM service</a> (ya never know if there are folks like yourself who are not ashamed of being in multiple ecosystems lol!).  Well, it would be great to get the Tachyon wizards on board with a Tachyon JAM service, but probably there are many talented folks within the Polkadot community who can do Tachyon prover + wallet just as competently and actually want to see much needed [scalable] privacy succeed here and with a sense of urgency.  These days you can get AI to do ZK-SNARKs for you, but its an absolute requirement you have someone experienced enough to call bullshit on the result.  98% is not good enough for production  but we can be <em>100% sure</em> the talent exists who can fill the gap from PoC to production.</p>
<p>I am not aware of anyone having benchmarked STARK verification in PVM, but if it takes N times longer to verify a STARK proof than a SNARK proof, then the PVM gas is going to be close to N times as much gas +/- 25%.   I assume that recursive-ZK-Starks get incorporated as soon as $N000 GPUs become more commonplace, making proof generation tractable so I think its safe to NOT go crazy with STARKs until we have a million MAUs for real in whatever.   Once the new proving tech is proven to have good UX and secure, we swap out one proof system for another that is quantum secure in the JAM service that verifies it.</p>

Sourabh Niyogi

Make Anonymity Coherent Again: Proposal for privacy as first-class citizen in JAM

<p>Thanks <a class="mention" href="/u/kianenigma">@kianenigma</a> — that makes sense. The nompool throttle model (capped increase rate + one-way ratchet on limits) is actually more elegant than a simple delay. It doesn’t just push the exploit window around; it makes the 0%→10% instant flip mathematically impossible regardless of timing.</p>
<p>Appreciate you being open to looking at this. Happy to help test or provide feedback if useful when something takes shape.</p>

Kian Paimani

Proposal to Optimize the Commission Setting Mechanism in Polkadot Staking

root

whitelisted_caller

wish_for_change

staking_admin

treasurer

lease_admin

fellowship_admin

general_admin

auction_admin

referendum_canceller

referendum_killer

small_tipper

big_tipper

small_spender

medium_spender

big_spender

Pilot Proposal: RMTerra "Choose Green" RegenFi - RWA  (Small Spender, ~10k KSM)

Subscan 2025 Q3-Q4 Funding Proposal: Basic service fee for the Kusama Relaychain and Kusama public parachain (AssetHub, Coretime, BridgeHub, People)

ZKAMA - ZK Verifier SDK Proposal {Post-AssetHub Hackathon Curation}

Unlock Winning Strategies with Playzone

Encointer Outlook for Q4'25 and Onwards

Sol-XCM | A typed interface for interoperability from Solidity

Implement a Kusama Forum MVP (Content Pallet v2)

Discovering the Dynamic Features of JLJL99

Implement pallet_content

Milestone-Based Payouts at Scale: Treasury Guardian Tool for Efficient Polkadot Treasury Spending

THE RIGHT TO DISAPPEAR

- Kusama is changing how it handles tokens to respond to network activity.
- Instead of setting a fixed limit, it will burn (permanently remove) some tokens.
- The base creation of new tokens is being reduced from 7.82% to 5%.
- Half of all transaction fees will be burned.
- Small percentages of Treasury funds will also be burned regularly.
- These burns aim to lower overall new token creation to about 4.25%, a big decrease.
- This plan works alongside another to reduce network costs.
- The goal is to make Kusama's token economics healthier and more responsive.

Deciding

 Sustainable KSM Economics via Burn Mechanisms (v1.2)

- Adam is a cybersecurity expert who helps keep the Polkadot and Kusama networks safe.
- He runs two validators, which are like special computers that help the network run smoothly.
- Adam wants to be a registrar on Kusama, which means he would help verify people's identities on the blockchain.
- He built a special website (dotid.app) that makes it easy for people to get their identity verified automatically.
- You can also talk to Adam directly for help if you don't want to use the website.
- He offers his help for free and is known for responding quickly to questions.
- Adam is already helping as a temporary registrar and wants to continue supporting the community.

Kusama

referenda2

treasury16

discussions1394