candidates

members

proficients

fellows

senior_fellows

experts

senior_experts

masters

senior_masters

grand_masters

Miscellaneous

Wallet Recommendations

Jonathan

Proposal for the Implementation of a Sybil-Resistant Proof-of-Syntactic-Equilibrium Pallet (v0.0.1-alpha)

Diego

The OpenGov.Watch Monitor V2

Eric-W3F

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.

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:

hantoniu (no dm)

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

AI Formal Verification tool for JAM

0xGeorgii

Discontinuation of ink: Rust smart contract language

Can Sassafras make Polkadot faster and safer?

Nasihudeen Adegboyega Jimoh

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

Polkadot-API Project Update

SO/DA zone

Polkadot x Işık Üniversitesi Turkey is the first pilot event İstanbul

PixelProof, and the Cost of a Careless Aye

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

Ecosystem

H160 Precompile Gateway: Standardized EVM Access for Polkadot DApps

Tokeniza Expands multichain strategy for RWA with Graphite Network and Moonbeam Foundation integrations

Tokeniza

Polkadot Digest 09 February 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

Luke

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="quote no-group" data-username="christ" data-post="10" data-topic="16951">
<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/christ/48/2868_2.png" class="avatar"> christ:</div>
<blockquote>
No one seems to be addressing the elephant in the room. <a href="https://martinalderson.com/posts/has-the-cost-of-software-just-dropped-90-percent/" rel="noopener nofollow ugc">The cost of software has supposedly dropped by 90%</a>
</blockquote>
</aside>
I guess the elephant in the room is a magical one. The blog post you mentioned claiming a 90 percent drop in software cost comes from a personal blog where the author shares anecdotal experience, not data or industry studies, and it is hopefully just clickbait.
Even if AI coding tools can dramatically speed up some tasks, that mostly reduces accidental complexity, like repetitive coding, boilerplate, and tooling overhead, while the essential complexity of real E-type systems, such as understanding evolving requirements, designing correct architectures, integrating components safely, and ongoing maintenance, remains the main effort.
Framing speedups in implementation due to accidental complexity reduction as a 90 percent total cost drop is arbitrary fantasy. It conflates improvements in incidental work with the core hard problem of building and evolving real software.

Chris T

I prefer to remain anonymous. The proposal should be evaluated based on its technical merit, not on the identity of the contributor. This is in line with the forum’s guidelines.
I’m happy to provide clarifications about the proposal itself, but I do not wish to disclose personal details.
And I think that if you insist, you’re crossing the line of what’s allowed on the forum.

Josep

Hello, Polkadot community!
We are Tokeniza, the first Brazilian platform for Real World Asset (RWA) tokenization regulated by the competent authorities in Brazil. We are incredibly excited to share a major milestone in our multi-chain expansion within the Polkadot ecosystem, marked by two key strategic partnerships: Graphite Network and Moonbeam Foundation.
This post aims to update the community on our progress and gather valuable feedback to guide our next steps.
Our Multi-Chain Expansion from the Polkadot Ecosystem
1. Strategic Partnership with Graphite Network
We have formed a strategic partnership with Graphite Network, a reputation-based blockchain designed to connect TradFi and DeFi.
Key integration points:
<ul>
<li>
Acquisition of RWAs via Graphite Network: users will be able to acquire Tokeniza’s RWAs directly using the Graphite Network.
</li>
<li>
On-Chain PIX Integration for the @G token: Graphite Network will be integrated with our On-Chain PIX system, allowing users to buy the @G token directly with Brazilian Reais (BRL). This offers an automated and secure currency conversion process.
</li>
</ul>
2. Deepening our Integration with Moonbeam
Following our initial expansion, we are strengthening our partnership with Moonbeam to bring Brazilian RWAs to a global audience.
Achievements and highlights:
<ul>
<li>
Global Access for International Investors: This partnership allows non-Brazilian investors to access regulated Brazilian RWAs with full compliance.
</li>
<li>
Proven Demand: In just one week in 2025, Moonbeam processed over 713,000 DeFi transactions, 95% of which were driven by Tokeniza’s activity.
</li>
<li>
On-Chain PIX as a Global Bridge: Our infrastructure allows any protocol on Moonbeam to send and receive money via PIX, creating a direct gateway to over 175 million PIX users in Brazil.
</li>
<li>
Fully Audited Reserves: All reserves are transparently audited and updated hourly by Fact Finance, ensuring complete security and trust.
</li>
</ul>
Seeking Community Guidance for Our Next Phase
Our multi-chain foundation is now established. To help us prioritize our next development and partnership efforts within the vast Polkadot ecosystem, we would love your input.
<ol>
<li>
Which RWA vertical should we focus on for international expansion next?
<ul>
<li>
Real Estate Credit
</li>
<li>
Agricultural Commodities
</li>
<li>
Corporate Debt / Digital Bonds
</li>
<li>
Other (please comment!)
</li>
</ul>
</li>
<li>
Which parachain or protocol in Polkadot would be most strategic for our next integration?
<ul>
<li>
Centrifuge
</li>
<li>
Astar Network
</li>
<li>
StellaSwap
</li>
<li>
Other (please suggest!)
</li>
</ul>
</li>
<li>
Which international market has the most potential for Brazilian RWAs?
<ul>
<li>
USA
</li>
<li>
Portugal / Europe
</li>
<li>
Latin America
</li>
<li>
Asia
</li>
<li>
Other (please suggest!)
</li>
</ul>
</li>
</ol>

<h2><a name="p-37714-polkadot-news-1" class="anchor" href="#p-37714-polkadot-news-1" aria-label="Heading link"></a>Polkadot News</h2>
Polkadot Runtime Upgrade to 2.0.6 has been executed successfully <a href="https://polkadot.subsquare.io/referenda/1838" rel="noopener nofollow ugc">https://polkadot.subsquare.io/referenda/1838</a>
“Polkadot-API 2026 Development Funding through Polkadot Community Foundation” is in the decision period and is currently failing <a href="https://polkadot.subsquare.io/referenda/1836" rel="noopener nofollow ugc">https://polkadot.subsquare.io/referenda/1836</a>
Polkadot System Collator Bounty Top-up request is in the decision period and is currently failing <a href="https://polkadot.subsquare.io/referenda/1832" rel="noopener nofollow ugc">https://polkadot.subsquare.io/referenda/1832</a>
<h2><a name="p-37714-kusama-news-2" class="anchor" href="#p-37714-kusama-news-2" aria-label="Heading link"></a>Kusama News</h2>
Kusama Runtime Upgrade to 2.0.6 has been executed successfully <a href="https://kusama.subsquare.io/referenda/633" class="inline-onebox" rel="noopener nofollow ugc">Runtime Upgrade 2.0.6</a>
Kusamas Shield v2, Bounty Top-up has been approved <a href="https://kusama.subsquare.io/referenda/631" class="inline-onebox" rel="noopener nofollow ugc">Kusamas Shield v2, Bounty 32 top up</a>

Hi Polkadot Team,
I’m reaching out from VulSight, a Web3 security audit firm specializing in smart contract audits for DeFi protocols. We work with Solidity, Rust, and EVM codebases.
We’re interested in exploring partnership opportunities with the Polkadot ecosystem specifically:
1. Becoming a recommended security auditor for projects building on Polkadot/Substrate
2. Collaborating with the Web3 Foundation grants program to support grantees with security reviews
3. Connecting with parachain teams that may need pre-launch audits
Our approach combines manual code review with fuzzing, and we offer faster turnaround than the bigger firms with competitive pricing suited for early-stage teams.
Could you please direct me to the appropriate contact or team for ecosystem partnerships?

AAfaq

A partnership between polkadot x VulSight

<blockquote>
1 - “exploring the idea of creating a coding agent tool that will use formal verification enhance the quality of code“ - Which LLM models/coding agents will you guys use or plan?
</blockquote>
The first version of the Inference skill is not based on LLM at all. This is planned to be used for coding agents, whichever you prefer, that is most relevant to your needs. Common ones we anticipate using our skill would be Claude Code, Codex, and Gemini CLI.
<blockquote>
2 - As a developer doing smart contracts can I use inference today ?
</blockquote>
We plan on having a stable version release in April-May of this year with more robust features and uses in the summer. For now, you can see our progress and updates (here)[<a href="https://github.com/Inferara/inference" class="inline-onebox" rel="noopener nofollow ugc">GitHub - Inferara/inference: 🌀 Inference programming language</a>] as well as the usual socials from the homepage.
However, the coding agent skill will be available by March. It will use the latest Inference features as soon as they are available, but will be useful from day one.
<blockquote>
3 - Who is the target group ? is it solidity developers ? is it rust developers that want to hack together polkavm contracts? Could I use inference with rust + polkavm, for this repo KusamaShield/PoseidonPolkaVM: Poseidon hashing for Polkavm with solidity compatibility - <a href="http://Codeberg.org" rel="noopener nofollow ugc">Codeberg.org</a> ?
</blockquote>
In the first iteration Inference is meant to be used more for sdk’s, cryptographic, and zk primitives, libraries; the second iteration would be more suited for smart contract development. The Inference AI skill is useful for smart contract development perfectly because it applies the methods of Inference to the code being produced by agents.
<blockquote>
4 - Is there any PoC of smart contracts or wasm code that use Inference for their testing suit
</blockquote>
Not at this time, but we have done some research on exploring the application of formal verification on Polkadot runtime (here)[<a href="https://github.com/Inferara/pallet-balances-formal-verification/blob/0e4b1527e0d2796d7d241dd2ad4934f7924ed4bb/preparation/preparing-polkadot-pallet-balances-for-formal-verification.md" class="inline-onebox" rel="noopener nofollow ugc">pallet-balances-formal-verification/preparation/preparing-polkadot-pallet-balances-for-formal-verification.md at 0e4b1527e0d2796d7d241dd2ad4934f7924ed4bb · Inferara/pallet-balances-formal-verification · GitHub</a>]
<blockquote>
5 - Is risc-v and polkavm on the roadmap?
</blockquote>
risc-v is on our minds for future implementation.

Rust Syndicate

Westend AssetHub RPCs don’t work, so we will start implementing <code>Paseo</code>, as a substitute.
<pre><code class="lang-auto">━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔍 Westend Relay Chain
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[06:32:18] ✅ OK 3175 ms wss://westend.api.onfinality.io/public-ws
[06:32:21] ✅ OK 2367 ms wss://westend-rpc.polkadot.io
[06:32:23] ✅ OK 2331 ms wss://westend.public.curie.radiumblock.co/ws

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔍 Westend Asset Hub
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[06:32:23] ❌ FAIL 267 ms wss://westend-asset-hub-rpc.polkadot.io
[06:32:24] ❌ FAIL 81 ms wss://westmint.api.onfinality.io/public-ws
[06:32:24] ❌ FAIL 243 ms wss://sys.ibp.network/westmint

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 CUMULATIVE STATISTICS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Endpoint Total OK TO Fail OK% Avg ms
wss://westend.api.onfinality.io/public-ws 4059 4019 40 0 99% 3324
wss://westend-rpc.polkadot.io 4059 4054 1 4 99% 2412
wss://westend.public.curie.radiumblock.co/ws 4059 4056 2 1 99% 2472
wss://westend-asset-hub-rpc.polkadot.io 4059 0 4 4055 0% —
wss://westmint.api.onfinality.io/public-ws 4059 0 7 4052 0% —
wss://sys.ibp.network/westmint 4059 0 22 4037 0% —

</code></pre>

RFC on DotBot, an LLM based intent-driven AI assistant for Polkadot

This event will be the first pilot initiative in Türkiye.
The event date will be scheduled after February 15.
The proposal has first been presented to the Polkadot community for feedback and evaluation.
Polkadot × Işık University Developer Meet-up &amp; Workshop Event – Sponsorship Proposal
<ol>
<li>
Event Overview The Polkadot Workshop will be delivered by Sadık Emre Alkan. The event will be hosted by the Işık University Blockchain Community and held at the Işık University Şile Campus. This event will represent Polkadot’s first pilot university event in Turkey. The primary objective of the event is to increase Polkadot’s visibility in Turkey and to establish a strong, sustainable, and long-term blockchain developer ecosystem within the country. To ensure accurate, transparent, and reliable participant data collection, event registrations will be managed via Google Forms / Google Docs.
</li>
<li>
Key Objectives of the Event
</li>
</ol>
<ul>
<li>
Increase Polkadot’s brand awareness within the Turkish developer community
</li>
<li>
Build a sustainable Polkadot-focused developer talent pipeline
</li>
<li>
Establish a Polkadot-centered ideathon/workshop structure enabling direct technical contributions to the ecosystem
</li>
<li>
Lay the foundation for long-term collaborations such as internships, technical partnerships, and deep ecosystem integrations
</li>
</ul>
<ol start="3">
<li>Pre-Event Preparation Process</li>
</ol>
<ul>
<li>
Prior to the physical event, an online introductory and planning meeting will be held between the Işık University Blockchain Community Executive Board and Polkadot representatives
</li>
<li>
Online participation from the Polkadot team is requested on the physical event day
</li>
</ul>
<ol start="4">
<li>Event Format and Content The Developer Meet-up, planned for December 2025, aims to bring together:</li>
</ol>
<ul>
<li>
30+ participants
</li>
<li>
25+ Polkadot ideathon / idea projects
</li>
<li>
A target audience consisting of blockchain developers, Web3 enthusiasts, and university students
</li>
</ul>
Event Flow:
<ol>
<li>Polkadot Technical &amp; Conceptual Presentation (180 minutes)</li>
</ol>
<ul>
<li>
Project vision
</li>
<li>
Technical architecture
</li>
<li>
Real-world use cases
</li>
<li>
Contributions to the blockchain ecosystem
</li>
</ul>
<ol start="2">
<li>Networking Session</li>
</ol>
<ul>
<li>
Pizza catering
</li>
<li>
Distribution of promotional merchandise
</li>
<li>
Prize-based Kahoot / mini competitions
</li>
</ul>
This format is specifically designed to enable direct, productive, and meaningful interaction between students, developers, and Polkadot representatives.
<ol start="5">
<li>Contributions to the Developer Community</li>
</ol>
<ul>
<li>
Networking and community-building opportunities
</li>
<li>
Technical knowledge sharing
</li>
<li>
Idea development through real-world project discussions
</li>
<li>
Distribution of gifts and branded merchandise
</li>
<li>
A relaxed, developer-focused, and productive event environment
</li>
</ul>
<ol start="6">
<li>Benefits for Polkadot a) Brand Visibility The Polkadot logo will be featured across:</li>
</ol>
<ul>
<li>
On-campus posters and brochures
</li>
<li>
Social media announcements
</li>
<li>
Event banners and flags
</li>
</ul>
b) Speaking and Promotion Opportunity
<ul>
<li>
A 180-minute in-depth technical presentation as the main speaker of the event
</li>
<li>
Direct exposure of Polkadot’s technology and vision to a highly relevant and qualified technical audience
</li>
</ul>
c) Merchandise &amp; Direct Engagement
<ul>
<li>
Distribution of Polkadot-branded merchandise
</li>
<li>
One-on-one engagement with a developer-focused audience
</li>
</ul>
d) Networking
<ul>
<li>Direct interaction with students and developers during the award ceremony and pizza networking session</li>
</ul>
<ol start="7">
<li>Budget and Cost Breakdown Total Event Cost: 2,700 USD</li>
</ol>
Cost Allocation: Sadık Emre Alkan
<ul>
<li>
Accommodation (2 nights), round-trip flights, local transportation, and daily expenses: 600 USD
</li>
<li>
Event allowance: 300 USD
</li>
<li>
University-related expenses: 1,800 USD
</li>
</ul>
<ol start="8">
<li>Sponsorship Request (Işık University Blockchain Community) To cover the event expenses, a sponsorship contribution of 1,800 USD is kindly requested from Polkadot.</li>
</ol>
Planned Use of Funds:
<ul>
<li>
Flags, brochures, and promotional materials: 400 USD
</li>
<li>
Speaker organization, food, beverages, and catering: 600 USD
</li>
<li>
Gifts, Kahoot prizes, and promotional merchandise: 300 USD
</li>
<li>
Donation to the Işık University Blockchain Community: 500 USD
</li>
</ul>
<ol start="9">
<li>Conclusion Partnering with Polkadot for this Developer Meet-up event offers the opportunity to:</li>
</ol>
<ul>
<li>
Strengthen Polkadot’s brand presence within university blockchain and developer communities in Turkey
</li>
<li>
Directly engage with the next generation of blockchain developers and engineers
</li>
<li>
Create a lasting brand impact in a highly technical, friendly, and high-engagement environment
</li>
<li>
Build a sustainable developer community around Polkadot SDK, Substrate, and parachain architecture
</li>
<li>
Establish long-term community growth aligned with Polkadot governance and treasury mechanisms
</li>
</ul>
We look forward to bringing this collaboration to life and delivering a valuable, productive, and memorable experience for all participants. Thank you for considering our proposal.
<hr>
<ol start="10">
<li>Technical Alignment with the Polkadot Ecosystem (Developer-Grade Integration)</li>
</ol>
This event is designed to be directly aligned with Polkadot’s technical architecture and developer infrastructure:
<ul>
<li>
Substrate Framework: Practical education on Substrate-based blockchain architecture, runtime modules, and custom chain design.
</li>
<li>
Parachain Architecture: Technical exploration of parachain–relay chain relationships, shared security, and cross-chain communication (XCMP).
</li>
<li>
Polkadot SDK: Developer onboarding through Polkadot SDK for dApp development, parachain construction, and custom blockchain creation.
</li>
<li>
Governance (OpenGov): Education on Polkadot’s on-chain governance model, referenda system, and community-driven decision-making.
</li>
<li>
Treasury Mechanism: Explanation of Polkadot Treasury structure, funding flows, and proposal mechanisms.
</li>
<li>
Grants Structure: Introduction to Polkadot Grants, ecosystem funding models, and community grant programs.
</li>
</ul>
This structure ensures the event is not merely promotional, but serves as a technical onboarding, ecosystem integration, and developer adoption platform.
<hr>
<ol start="11">
<li>Sponsorship Model – Polkadot Treasury / Grants / Ecosystem Fund Aligned Structure</li>
</ol>
The sponsorship model for this event is designed in direct alignment with Polkadot’s ecosystem funding architecture:
Aligned Funding Sources:
<ul>
<li>
Polkadot Treasury: Community-driven ecosystem growth and developer onboarding
</li>
<li>
Polkadot Grants Program: Education, developer programs, and technical community building
</li>
<li>
Ecosystem Fund: Long-term university-based ecosystem expansion strategies
</li>
</ul>
Event Positioning Categories:
<ul>
<li>
Developer onboarding program
</li>
<li>
Community growth initiative
</li>
<li>
Technical ecosystem expansion
</li>
<li>
University-based developer pipeline program
</li>
</ul>
This model transforms the event from a one-time sponsorship into a strategic ecosystem initiative that enables: Sustainable developer production, project incubation, and long-term technical contribution generation within the Polkadot ecosystem.
<hr>
Social Media Sadık Emre Alkan LinkedIn: <a href="https://www.linkedin.com/in/sad%C4%B1k-emre-alkan-155a89119?utm_source=share&amp;utm_campaign=share_via&amp;utm_content=profile&amp;utm_medium=android_app" rel="noopener nofollow ugc">https://www.linkedin.com/in/sad%C4%B1k-emre-alkan-155a89119?utm_source=share&amp;utm_campaign=share_via&amp;utm_content=profile&amp;utm_medium=android_app</a> X (Twitter): <a href="https://x.com/FeliManjur" rel="noopener nofollow ugc">https://x.com/FeliManjur</a>
Işık Blockchain LinkedIn: <a href="https://www.linkedin.com/company/isikblockchain/" rel="noopener nofollow ugc">https://www.linkedin.com/company/isikblockchain/</a>

<aside class="quote no-group" data-username="parity-data" data-post="4" data-topic="16919">
<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/parity-data/48/7039_2.png" class="avatar"> parity-data:</div>
<blockquote>
there are other providers who already deliver that level of granularity very well.
</blockquote>
</aside>
That’s good, who are the other providers?

Ross Bulat

Dotlake API Publicly available

OMG <img src="https://emoji.discourse-cdn.com/twitter/sob.png?v=15" title=":sob:" class="emoji" alt=":sob:" loading="lazy" width="20" height="20">
I’m so disappointed to hear the decision
Ink! is quite great project for smart contract by using rust
I hope the decision will be reconsidered

Johan Alexis Duque Cadena

<hr>
I’ve been going through the <a href="https://research.web3.foundation/Polkadot/protocols/Sassafras" rel="noopener nofollow ugc">Web3 Foundation’s blog series on Sassafras</a>, along with the research paper, to dig into how this protocol really works under the hood. 
As someone with little experience in blockchain engineering already familiar with smart contracts, PoS mechanics, and validator dynamics i find Sassafras fascinating because it tackles one of the trickiest parts of consensus: leader election. 
It is set to replace Polkadot’s <a href="https://docs.polkadot.com/reference/polkadot-hub/consensus-and-security/pos-consensus/#block-production-babe" rel="noopener nofollow ugc">BABE</a>+<a href="https://openethereum.github.io/Aura.html" rel="noopener nofollow ugc">Aura</a> hybrid, shifting from probabilistic randomness to secret, deterministic selections, which should make block production both more predictable and more secure. 
What really caught my attention is how it balances cryptography, probability, and efficiency in a way that feels practical for real-world chain operations. 
In this write-up, I’ll break down the protocol, the math behind it, and the key mechanics plus analogies where they help so you can follow the logic without needing a full cryptography background. 
This is my synthesis feel free to check against the originals.
At its core, a blockchain is a decentralized, immutable ledger, batching transactions into blocks linked cryptographically.
<hr>
<h3><a name="p-37672-the-case-for-sassafras-why-current-block-production-struggles-1" class="anchor" href="#p-37672-the-case-for-sassafras-why-current-block-production-struggles-1" aria-label="Heading link"></a>The Case for Sassafras: Why Current Block Production Struggles</h3>
Polkadot uses a Proof-of-Stake (PoS) system, specifically a Nominated Proof-of-Stake (NPoS) variant. Validators stake DOT tokens to secure the network and participate in block creation. DOT holders who don’t run nodes can also nominate trusted validators, helping decide who gets to produce blocks.
The current block production setup combines two components:
<ul>
<li>BABE — adds randomness to determine who can propose blocks.</li>
<li>Aura — organizes turn-taking among validators to keep blocks coming regularly.</li>
</ul>
While this hybrid approach works, it still has fundamental issues in leader selection, leading to inefficiencies, unpredictable block timing, and potential security risks. This is exactly what Sassafras aims to address.
<hr>
<h3><a name="p-37672-probabilistic-leader-election-ple-explained-2" class="anchor" href="#p-37672-probabilistic-leader-election-ple-explained-2" aria-label="Heading link"></a>Probabilistic Leader Election (PLE) Explained</h3>
BABE uses Probabilistic Leader Election (PLE). In simple terms:
<ul>
<li>Leaders are picked randomly, with probabilities based on how much stake they have.</li>
<li>Imagine buying lottery tickets: the more tickets you have (or the more stake you hold), the higher your chance of winning.</li>
</ul>
While fair in theory, this approach has key inefficiencies:
<h4><a name="p-37672-h-1-multiple-or-zero-winners-3" class="anchor" href="#p-37672-h-1-multiple-or-zero-winners-3" aria-label="Heading link"></a>1. Multiple or Zero Winners</h4>
<ul>
<li>Each slot may produce more than one leader or none at all.</li>
<li>The math behind this is called Poisson distribution:</li>
<li>Expected number of leaders per slot: ( \lambda \approx 1 )</li>
<li>But variance exists: sometimes ( P(&gt;1) ) (more than one winner) or ( P(0) ) (no winner) happens.</li>
</ul>
<h4><a name="p-37672-consequences-4" class="anchor" href="#p-37672-consequences-4" aria-label="Heading link"></a>Consequences:</h4>
<ul>
<li>Forks multiple competing chains appear, resolved by the longest-chain rule.</li>
<li>Empty slots no block is produced, slowing down chain growth.</li>
</ul>
Analogy: Imagine a highway where cars arrive randomly. Sometimes too many cars bunch up (forks), sometimes no cars arrive at all (empty slots).
<h4><a name="p-37672-h-2-unpredictable-timing-5" class="anchor" href="#p-37672-h-2-unpredictable-timing-5" aria-label="Heading link"></a>2. Unpredictable Timing</h4>
<ul>
<li>Block intervals follow an exponential distribution (average ~6 seconds in Polkadot).</li>
<li>This randomness reduces throughput (transactions per second, TPS).</li>
<li>Gaps between blocks mean the network isn’t processing transactions as efficiently as it could.</li>
</ul>
<h4><a name="p-37672-h-3-scalability-trade-offs-6" class="anchor" href="#p-37672-h-3-scalability-trade-offs-6" aria-label="Heading link"></a>3. Scalability Trade-Offs</h4>
<ul>
<li>You might try to reduce slot time to process more transactions faster.</li>
<li>Problem: Faster slots increase the chance of forks, because the network may not have seen the previous block yet.</li>
<li>This can allow double-spending attacks, where someone spends the same DOT twice.</li>
</ul>
<h4><a name="p-37672-real-world-analogy-7" class="anchor" href="#p-37672-real-world-analogy-7" aria-label="Heading link"></a>Real-World Analogy</h4>
Think of PoS with PLE like cars arriving on a highway randomly:
<ul>
<li>Sometimes too many cars at once → traffic jams (forks).</li>
<li>Sometimes no cars → wasted time (empty slots).</li>
<li>Trying to make cars go faster → increases risk of collisions (double-spending).</li>
</ul>
<h4><a name="p-37672-what-the-math-says-8" class="anchor" href="#p-37672-what-the-math-says-8" aria-label="Heading link"></a>What the Math Says</h4>
<ul>
<li>Research shows PLE’s block finality is ~25% slower than SSLE.</li>
<li>PLE tolerates up to 49% adversarial stake (( f &lt; 0.49 )).</li>
<li>Weakness: If adversaries secretly create chains at rate ( f ), they can sometimes outpace honest validators (( 1-f )), reducing chain quality (the fraction of honest blocks).</li>
</ul>
<hr>
<h3><a name="p-37672-the-vision-constant-time-block-production-9" class="anchor" href="#p-37672-the-vision-constant-time-block-production-9" aria-label="Heading link"></a>The Vision: Constant-Time Block Production</h3>
The main idea here is to produce exactly one block per slot, consistently. That’s called constant-time block generation.
<ul>
<li>Polkadot’s current Aura system does this with a round-robin schedule, meaning each validator gets a predictable turn.</li>
<li>The problem with predictability is that it opens the door to attacks:</li>
<li>Forking attacks happen if an attacker targets the known next leader and tries to make competing chains.</li>
<li>Denial-of-Service (DoS) attacks occur if someone floods the leader’s network to prevent them from broadcasting their block.</li>
</ul>
To solve this, Single Secret Leader Election (SSLE) is used:
<ul>
<li>Only one leader is selected per slot, and their identity is hidden until they actually produce the block.</li>
<li>This keeps attackers from knowing whom to target.</li>
<li>Sassafras implements SSLE and works together with Grandpa, Polkadot’s finality gadget. Grandpa ensures that once blocks reach a certain depth ( k ), they are final meaning they cannot be reversed in the honest validators’ view.</li>
</ul>
The trade-off is mostly mathematical:
<ul>
<li>SSLE assumes a Byzantine fault tolerance threshold of ( f &lt; 1/3 ) (the network can tolerate up to 1/3 malicious validators).</li>
<li>PLE (probabilistic leader election, like in BABE) can tolerate up to ( f &lt; 0.49 ), but Sassafras gains faster finality (about 25% faster) and more predictable block timing.</li>
</ul>
<hr>
<h3><a name="p-37672-diving-deep-sassafrass-core-mechanics-10" class="anchor" href="#p-37672-diving-deep-sassafrass-core-mechanics-10" aria-label="Heading link"></a>Diving Deep: Sassafras’s Core Mechanics</h3>
Sassafras uses advanced cryptography to elect leaders for multiple slots in one go. This is called a batch election, which reduces the overhead per slot to ( O(1) ). At the same time, it keeps the leaders’ identities mostly hidden.
The main cryptographic tool is the ring verifiable random function (VRF):
<ul>
<li>VRF (Verifiable Random Function): A VRF takes an input ( x ) and a secret key ( sk ), and produces an output ( y ) that looks random, plus a proof ( \pi ). Anyone with the public key can verify ( \pi ) to confirm the output is correct, but without ( sk ), the output is unpredictable.</li>
<li>Ring VRF: This extends the VRF to a group of ( n ) participants. The output proves that someone in the group created it, but doesn’t reveal which participant. This gives anonymity.</li>
</ul>
Sassafras runs in epochs, which are fixed periods (for example, 2400 slots in Polkadot). At the start of each epoch, the set of validators is updated.
<hr>
<h3><a name="p-37672-the-five-phases-in-detail-11" class="anchor" href="#p-37672-the-five-phases-in-detail-11" aria-label="Heading link"></a>The Five Phases in Detail</h3>
<h4><a name="p-37672-phase-a-ticket-generation-12" class="anchor" href="#p-37672-phase-a-ticket-generation-12" aria-label="Heading link"></a>Phase A: Ticket Generation</h4>
<ol>
<li>The system provides a shared random seed ( r ) from the randomness beacon (think of it like a lottery number that everyone trusts).</li>
<li>Each validator ( i ) computes a ticket using the ring VRF: <code>Ring VRF(r, i) → value v, proof π</code>.</li>
<li>If ( v ) is below a threshold ( τ ) (set so that the expected number of winners equals the number of slots ( m )), the validator has a winning ticket.</li>
<li>The winning ticket is signed anonymously with the ring VRF.</li>
</ol>
Math explanation: Each validator has a probability of winning ( p ≈ m/n ). This is tuned so that winners are roughly evenly distributed across the epoch, but still random.
Analogy: Imagine a private raffle where each person draws a number and checks if it’s below a winning cutoff. Only the winner knows they won, and they prepare a sealed ticket.
<h4><a name="p-37672-phase-b-anonymous-publication-via-repeaters-13" class="anchor" href="#p-37672-phase-b-anonymous-publication-via-repeaters-13" aria-label="Heading link"></a>Phase B: Anonymous Publication (via Repeaters)</h4>
<ol>
<li>Each winning ticket is encrypted using a symmetric key (fast encryption like AES) that is derived non-interactively (<a href="https://brilliant.org/wiki/diffie-hellman-protocol/" rel="noopener nofollow ugc">Diffie-Hellman style</a>).</li>
<li>A random repeater ( j ) is selected to broadcast the ticket. The ticket is sent to all validators, but only the repeater can decrypt and post it onchain.</li>
<li>To prevent outsiders from guessing how many winners there are, dummy tickets (fake or non-winning tickets) are included.</li>
</ol>
Analogy : You put your raffle ticket in a locked box and send it to a friend (the repeater). They open the box and announce the result, without revealing that it was you who sent it.
<h4><a name="p-37672-phase-c-sorting-14" class="anchor" href="#p-37672-phase-c-sorting-14" aria-label="Heading link"></a>Phase C: Sorting</h4>
<ol>
<li>All tickets are collected and verified on-chain.</li>
<li>Tickets are sorted by value to determine the top-ranked winners for each slot.</li>
</ol>
Analogy : Like arranging numbers in ascending order to decide who goes first.
<h4><a name="p-37672-phase-d-leader-claim-handling-attacks-15" class="anchor" href="#p-37672-phase-d-leader-claim-handling-attacks-15" aria-label="Heading link"></a>Phase D: Leader Claim (Handling Attacks)</h4>
<ol>
<li>When the election epoch arrives, the top ticket owner claims the slot using the ring VRF proof.</li>
<li>If a repeater is malicious (probability ≤ ( f )), the leader’s identity might leak, which could cause a DoS attack and make that slot empty.</li>
<li>Sassafras skips compromised slots, allowing the next honest winner to step in, ensuring the chain keeps moving.</li>
</ol>
Analogy : If some winners are exposed and attacked, backup winners automatically take over.
<h4><a name="p-37672-phase-e-block-production-16" class="anchor" href="#p-37672-phase-e-block-production-16" aria-label="Heading link"></a>Phase E: Block Production</h4>
<ol>
<li>The claimed leader produces and broadcasts their block.</li>
<li>Sassafras supports arbitrary batch sizes ( m ), making it more efficient than systems that fix the batch size.</li>
</ol>
<hr>
<h3><a name="p-37672-math-and-security-breaking-down-the-jargon-17" class="anchor" href="#p-37672-math-and-security-breaking-down-the-jargon-17" aria-label="Heading link"></a>Math and Security: Breaking Down the Jargon</h3>
<ul>
<li>Threat model: Assumes an adaptive adversary (can corrupt validators dynamically) with ( f &lt; 1/3 ) of stake and full network access.</li>
<li>Anonymity probability: Probability that both the ticket owner and repeater are honest: ( ≥ h² = (1-f)² ≈ 4/9 ).</li>
<li>Probability a repeater leaks information: ( ≤ f ≈ 1/3 ).</li>
<li>Relaxed anonymity: Not all leaders are hidden, but enough are to maintain liveness (the chain keeps producing blocks).</li>
<li>Block production: Honest blocks ≥ 4/9, adversarial blocks ≤ 1/3, ensuring chain growth favors honest blocks.</li>
</ul>
Chernoff bounds: A statistical method to limit deviations in random events. For binomial variables ( X_i ) (honest block indicators):
<pre><code class="lang-auto">[
P(S &lt; (1-δ)μ) ≤ e^{-δ² μ / 3}, \quad μ = E[S]
]
</code></pre>
This ensures adversaries cannot dominate a sequence of slots.
<ul>
<li>Finality: Adapts proofs from <a href="https://www.iog.io/papers/ouroboros-praos-an-adaptively-secure-semi-synchronous-proof-of-stake-protocol" rel="noopener nofollow ugc">Ouroboros Praos</a>. After depth ( k ), chains converge with high probability. Honest growth rate ≥ 4/9 outpaces adversarial ≤ 1/3.</li>
</ul>
Sassafras is proven in the Universal Composability (UC) model and resists timing/size attacks by using uniform ticket sizes and synchronized publishing. Large anonymity sets (e.g., 999k/1M) make DoS attacks ineffective compared to rivals (e.g., 31/32).
<hr>
<h3><a name="p-37672-sassafras-vs-competitors-18" class="anchor" href="#p-37672-sassafras-vs-competitors-18" aria-label="Heading link"></a>Sassafras vs Competitors</h3>
<h4><a name="p-37672-non-ssle-systems-ple-like-babe-19" class="anchor" href="#p-37672-non-ssle-systems-ple-like-babe-19" aria-label="Heading link"></a>Non-SSLE systems (PLE like BABE)</h4>
Can handle slightly higher malicious stake ( f ), but slower finality (~25%) and more prone to gaps/forks.
<h4><a name="p-37672-ssle-approaches-20" class="anchor" href="#p-37672-ssle-approaches-20" aria-label="Heading link"></a>SSLE approaches:</h4>
<ul>
<li>Shuffling: Commit list → shuffle → select via beacon. Proofs costly ( O(n) ), efficient only for small sublists.</li>
<li>WHISK: Batch for Ethereum, small sets → vulnerable to DoS.</li>
<li>PEKS-based: Heavy public-key crypto, O(n) comms.</li>
<li>Other advanced crypto (iO, TFHE): Impractical due to overhead.</li>
</ul>
<hr>
<h3><a name="p-37672-key-terms-simplified-from-my-reading-21" class="anchor" href="#p-37672-key-terms-simplified-from-my-reading-21" aria-label="Heading link"></a>Key Terms Simplified From My Reading</h3>
<ul>
<li>Epoch: Fixed session with stable validators/rules.</li>
<li>Throughput: TPS; higher for scalable networks.</li>
<li>Finality: Irreversibility point.</li>
<li>Byzantine Fault Tolerance: Resists 1/3 malicious nodes.</li>
<li>DoS Attack: Overload to disrupt.</li>
<li>On-Chain: Public blockchain data; off-chain private.</li>
</ul>
<h3><a name="p-37672-final-reflections-sassafrass-path-forward-22" class="anchor" href="#p-37672-final-reflections-sassafrass-path-forward-22" aria-label="Heading link"></a>Final Reflections: Sassafras’s Path Forward</h3>
Sassafras elects single, secret leaders for constant-time consensus, blocks DoS attacks, and keeps overhead minimal ideal for Polkadot’s relay chain and the Safrole variant in JAM architecture. It’s like moving from PLE’s erratic lottery to SSLE’s hidden order: scalability improves without sacrificing security this could solidify Polkadot’s edge you can check out the <a href="https://research.web3.foundation/Polkadot/protocols/Sassafras/sassafras-part-1?utm_source=chatgpt.com" rel="noopener nofollow ugc">sources</a> or paper for deeper proofs. 
I simplified some proofs, but this captures my in-depth read. Thoughts?

The Polkadot treasury funded $225,000 for a privacy-focused photo storage application. The application stores unencrypted personal photos on IPFS — a public network where anyone with a content identifier can retrieve the data from any gateway in the world. The company that built it shut down five weeks ago.
I am primarily active on Kusama governance. Each network has its own stakeholders and delegates, but the communities overlap significantly and the governance practices on one inevitably influence the other. I went through this case in detail because I think the pattern it reveals is worth examining.
<h3><a name="p-37665-what-was-promised-1" class="anchor" href="#p-37665-what-was-promised-1" aria-label="Heading link"></a>What was promised</h3>
<a href="https://polkadot.subsquare.io/referenda/1631" rel="noopener nofollow ugc">Referendum 1631</a> requested $575,000 to build PixelProof — a “decentralized Google Photos” on Polkadot. It was rejected at 99.7% Nay. A revised <a href="https://polkadot.subsquare.io/referenda/1670" rel="noopener nofollow ugc">Referendum 1670</a> reduced the ask to $225,000 for a lean MVP and passed with 63% approval in December 2024.
The revised proposal explicitly promised client-side encryption. When a commenter asked how end-to-end encryption would work, the proposer responded with a detailed commitment from their CTO: “all images will be fully client-side encrypted,” with encryption keys “derived from the user’s wallet and passkey,” ensuring “only the user can access their stored images.”
<h3><a name="p-37665-what-was-delivered-2" class="anchor" href="#p-37665-what-was-delivered-2" aria-label="Heading link"></a>What was delivered</h3>
PixelProof’s source code is <a href="https://github.com/Apillon/pixelproof" rel="noopener nofollow ugc">public on GitHub</a> — 23 commits, zero stars, zero forks, created October 2025 (ten months after funding). As of February 2026, <a href="https://pixelproof.com" rel="noopener nofollow ugc">pixelproof.com</a> shows a “Coming Soon” landing page.
I read the upload pipeline end to end. The UI passes raw files to a handler, which wraps them in a <code>FormData</code> and POSTs to the server. The server converts each file to a buffer and sends it directly to the Apillon SDK for IPFS storage. At no point is any encryption applied. I searched the entire codebase for <code>encrypt</code>, <code>cipher</code>, <code>AES</code>, <code>chacha</code>, <code>E2E</code>, <code>end-to-end</code> — zero matches in application source code. The proposal promised client-side encryption. The code uploads raw bytes to IPFS.
This matters because IPFS is <a href="https://docs.ipfs.tech/concepts/privacy-and-encryption/" rel="noopener nofollow ugc">public by default</a>. CIDs are announced to the distributed hash table publicly, and any gateway can resolve them. PixelProof includes a <a href="https://github.com/Apillon/pixelproof/blob/edc51ac515cd745642edc0dcd958f7df1740630b/contracts/AlbumAccessControl.sol" rel="noopener nofollow ugc">smart contract</a> on Moonbeam that manages access lists — but this only controls what the web application displays to logged-in users. It cannot prevent direct access via CID. Without encryption, this access control is cosmetic. The photos are public data with a UI layer on top — arguably less private than Google Photos, which at least requires authentication at the infrastructure level.
The application’s entire storage backend depends on the Apillon SDK. Every file operation — uploads, bucket management, IPFS pinning — goes through Apillon’s infrastructure. In mid-2025, Apillon <a href="https://x.com/Apillon/status/1988006274244481081" rel="noopener nofollow ugc">announced</a> it was winding down, citing market conditions and Polkadot tech stack fragmentation. The platform ceased operations on January 1, 2026. The $225,000 investment is effectively stranded.
<h3><a name="p-37665-what-already-existed-3" class="anchor" href="#p-37665-what-already-existed-3" aria-label="Heading link"></a>What already existed</h3>
The problem space PixelProof set out to address has mature, open-source solutions:
<div class="md-table">
<table>
<thead>
<tr>
<th></th>
<th>PixelProof</th>
<th><a href="https://ente.io/" rel="noopener nofollow ugc">Ente</a></th>
<th><a href="https://immich.app/" rel="noopener nofollow ugc">Immich</a></th>
</tr>
</thead>
<tbody>
<tr>
<td>End-to-end encryption</td>
<td>Promised, not implemented</td>
<td>Yes — encrypts on device before upload</td>
<td>Optional</td>
</tr>
<tr>
<td>Security audits</td>
<td>None</td>
<td>3 independent firms (Cure53, Symbolic Software, Fallible)</td>
<td>Open source (no formal audit)</td>
</tr>
<tr>
<td>Self-hostable</td>
<td>Depends on Apillon (shut down)</td>
<td>Yes (S3-compatible backend)</td>
<td>Yes</td>
</tr>
<tr>
<td>Mobile apps</td>
<td>None</td>
<td>iOS, Android, Web, Desktop</td>
<td>iOS, Android, Web</td>
</tr>
<tr>
<td>AI search</td>
<td>Excluded from MVP</td>
<td>Yes</td>
<td>Yes (CLIP, facial recognition)</td>
</tr>
<tr>
<td>Production scale</td>
<td>“Coming Soon”</td>
<td>200M+ photos stored</td>
<td>90,000+ GitHub stars</td>
</tr>
<tr>
<td>Cost to treasury</td>
<td>$225,000</td>
<td>$0</td>
<td>$0</td>
</tr>
</tbody>
</table>
</div>Ente’s architecture is worth noting specifically. Its S3-compatible storage backend means it can work with any S3-compatible provider — including, potentially, Polkadot-native storage solutions like <a href="https://github.com/eigerco/polkadot-native-storage" rel="noopener nofollow ugc">PolkaStorage</a> or <a href="https://forum.polkadot.network/t/introducing-storage-hub-a-system-parachain-optimised-for-storage/4525">StorageHub</a>. The path to privacy-preserving photo storage on Polkadot was never about building a new application from scratch. It was about filling the infrastructure gap that existing applications already need.
<h3><a name="p-37665-how-did-this-pass-4" class="anchor" href="#p-37665-how-did-this-pass-4" aria-label="Heading link"></a>How did this pass?</h3>
Referendum 1670 had 204 voters. The contrast between the two sides is worth looking at.
On the Nay side, Permanence DAO conducted a ten-member internal review — zero ayes, four nays, two abstains — and explicitly flagged the missing competitive analysis. JAM DAO flagged the budget as excessive for an MVP. One commenter who initially voted Nay called the project “a demonstration of Apillon SDK integration rather than a solution to an ecosystem-wide need” — before flipping to Aye after a phone call with the team, citing that they seemed “genuinely committed to building something meaningful.”
On the Aye side, the public reasoning that was visible did not engage with the technical substance. No commenter checked whether the problem was already solved. The one voter who asked about encryption received a detailed commitment from the proposer — and voted Aye on a promise that was never delivered.
<h3><a name="p-37665-heres-where-i-land-5" class="anchor" href="#p-37665-heres-where-i-land-5" aria-label="Heading link"></a>Here’s where I land</h3>
We spend considerable energy in this ecosystem debating the behavior of those who vote Nay. But the asymmetry is worth stating plainly: a wrongly rejected proposal can return with better arguments and a revised scope — the ecosystem loses time, not capital. A carelessly approved proposal spends real money. In this case, $225,000 on unencrypted photos on a public network, built on infrastructure that no longer exists, solving a problem that open-source communities solved years ago for free. The voters who said No were right.
That is not a comfortable observation, but it’s an important one. We should be at least as rigorous with our Ayes as we are critical of our Nays.
I opened a thread on <a href="https://forum.polkadot.network/t/kusama-shield-v2-some-questions/16834">Kusama Shield v2</a> asking substantive questions — about relay models, privacy guarantees, audit timelines, swap mechanism design. The team responded in detail. You could follow the exchange and come away with a clear understanding of what was being built, what the limitations were, and where the roadmap was headed. That is how it should work.
PixelProof passed without any of that scrutiny. The encryption question got a detailed answer that turned out to be hollow. Nobody asked what already existed. The dependency on a single company’s infrastructure went unexamined.
The ecosystem is in a transition period. Communication from W3F and Parity has been sparse, but significant work is underway — JAM, native storage infrastructure, runtime improvements. The technical foundation for the next phase is being built. When it arrives, the treasury will be asked to fund applications on top of it. We should be ready to evaluate those proposals better than we evaluated this one.
The questions aren’t complicated: Does a privacy claim come with a credible technical specification? What already exists in this space? Does it make financial sense against free, open-source alternatives? What happens if the underlying provider disappears?
For my part, I’m focused on Kusama. I’ve been <a href="https://forum.polkadot.network/t/clarifying-kusamas-governance-direction-independence-or-integration/16858">asking for clarity</a> on whether Kusama is meant to chart its own course or follow Polkadot’s lead — that question is still open, and the answer shapes where community effort is best spent. Until then, I’ll keep building in the open and pushing for the kind of scrutiny that makes treasury funding worth defending.

I would like to start by thanking the community for the continued support. So far 3 out 4 <img src="https://emoji.discourse-cdn.com/twitter/globe_showing_americas.png?v=15" title=":globe_showing_americas:" class="emoji" alt=":globe_showing_americas:" loading="lazy" width="20" height="20"> ValidAndina <img src="https://emoji.discourse-cdn.com/twitter/snow_capped_mountain.png?v=15" title=":snow_capped_mountain:" class="emoji" alt=":snow_capped_mountain:" loading="lazy" width="20" height="20"> nodes in LATAM have lost their DN nomination as part of the expected sunsetting of the program. The 4th one will also follow in the upcoming days.
The 2 Kusama nodes have remained in the active set thanks to the support of nominators <img src="https://emoji.discourse-cdn.com/twitter/star_struck.png?v=15" title=":star_struck:" class="emoji" alt=":star_struck:" loading="lazy" width="20" height="20">
The 2 Polkadot nodes will go out of the active set, one tomorrow, the other in the coming days, despite having accumulated numerous nominations.
Today “<img src="https://emoji.discourse-cdn.com/twitter/globe_showing_americas.png?v=15" title=":globe_showing_americas:" class="emoji" alt=":globe_showing_americas:" loading="lazy" width="20" height="20"> ValidAndina <img src="https://emoji.discourse-cdn.com/twitter/snow_capped_mountain.png?v=15" title=":snow_capped_mountain:" class="emoji" alt=":snow_capped_mountain:" loading="lazy" width="20" height="20"> BOG <img src="https://emoji.discourse-cdn.com/twitter/colombia.png?v=15" title=":colombia:" class="emoji" alt=":colombia:" loading="lazy" width="20" height="20"> DOT”: 
<a href="https://apps.turboflakes.io/?chain=polkadot#/validator/16mrcAndMguy3wqfuLNubgxxeyWQHjYAdqRbj26Vb2gYtszK">16mrcAndMguy3wqfuLNubgxxeyWQHjYAdqRbj26Vb2gYtszK</a> 
is estimated to be in slot 642 and there are 600 nodes in the active set.
Over the past 11 months I have been committed to providing exceptional validator performance in LATAM, despite latency and expensive infrastructure costs in the region, and I am very proud of what we have achieved.
I hope to continue securing the network from LATAM and would like to ask you to consider adding my nodes to your list of validators.
It would be a shame if both Polkadot and Kusama returned to having the majority of the nodes in Europe and North America.
Please support me and other committed validators who strive to contribute to a more decentralized network.
This is the panorama at the moment on Kusama: 
<img src="https://emoji.discourse-cdn.com/twitter/white_check_mark.png?v=15" title=":white_check_mark:" class="emoji" alt=":white_check_mark:" loading="lazy" width="20" height="20"> <a href="https://apps.turboflakes.io/?chain=kusama#/validator/JMB89sS8GfRN4ebiQ8xMVVowwnzQ6oD1iXrxPP6WjsXTJXb"><img src="https://emoji.discourse-cdn.com/twitter/globe_showing_americas.png?v=15" title=":globe_showing_americas:" class="emoji" alt=":globe_showing_americas:" loading="lazy" width="20" height="20"> ValidAndina <img src="https://emoji.discourse-cdn.com/twitter/snow_capped_mountain.png?v=15" title=":snow_capped_mountain:" class="emoji" alt=":snow_capped_mountain:" loading="lazy" width="20" height="20"> BOG <img src="https://emoji.discourse-cdn.com/twitter/colombia.png?v=15" title=":colombia:" class="emoji" alt=":colombia:" loading="lazy" width="20" height="20"> KSM</a> 
<img src="https://emoji.discourse-cdn.com/twitter/white_check_mark.png?v=15" title=":white_check_mark:" class="emoji" alt=":white_check_mark:" loading="lazy" width="20" height="20"> <a href="https://apps.turboflakes.io/?chain=kusama#/validator/FELETDtt5cdxYmqTudCkeqLPGqbM8VRU37fgxB4ctoXARgh"><img src="https://emoji.discourse-cdn.com/twitter/globe_showing_americas.png?v=15" title=":globe_showing_americas:" class="emoji" alt=":globe_showing_americas:" loading="lazy" width="20" height="20"> ValidAndina <img src="https://emoji.discourse-cdn.com/twitter/snow_capped_mountain.png?v=15" title=":snow_capped_mountain:" class="emoji" alt=":snow_capped_mountain:" loading="lazy" width="20" height="20"> LIM <img src="https://emoji.discourse-cdn.com/twitter/peru.png?v=15" title=":peru:" class="emoji" alt=":peru:" loading="lazy" width="20" height="20"> KSM</a>
This is the panorama at the moment on Polkadot: 
<img src="https://emoji.discourse-cdn.com/twitter/next_track_button.png?v=15" title=":next_track_button:" class="emoji" alt=":next_track_button:" loading="lazy" width="20" height="20"> <a href="https://apps.turboflakes.io/?chain=polkadot#/validator/16mrcAndMguy3wqfuLNubgxxeyWQHjYAdqRbj26Vb2gYtszK"><img src="https://emoji.discourse-cdn.com/twitter/globe_showing_americas.png?v=15" title=":globe_showing_americas:" class="emoji" alt=":globe_showing_americas:" loading="lazy" width="20" height="20"> ValidAndina <img src="https://emoji.discourse-cdn.com/twitter/snow_capped_mountain.png?v=15" title=":snow_capped_mountain:" class="emoji" alt=":snow_capped_mountain:" loading="lazy" width="20" height="20"> BOG <img src="https://emoji.discourse-cdn.com/twitter/colombia.png?v=15" title=":colombia:" class="emoji" alt=":colombia:" loading="lazy" width="20" height="20"> DOT</a> 
<img src="https://emoji.discourse-cdn.com/twitter/cross_mark.png?v=15" title=":cross_mark:" class="emoji" alt=":cross_mark:" loading="lazy" width="20" height="20"> <a href="https://apps.turboflakes.io/?chain=polkadot#/validator/13f1iU967VsBeRxueqs9zrJV6JZ1EmEP6A1QTatThBcYbxqE"><img src="https://emoji.discourse-cdn.com/twitter/globe_showing_americas.png?v=15" title=":globe_showing_americas:" class="emoji" alt=":globe_showing_americas:" loading="lazy" width="20" height="20"> ValidAndina <img src="https://emoji.discourse-cdn.com/twitter/snow_capped_mountain.png?v=15" title=":snow_capped_mountain:" class="emoji" alt=":snow_capped_mountain:" loading="lazy" width="20" height="20"> LIM <img src="https://emoji.discourse-cdn.com/twitter/peru.png?v=15" title=":peru:" class="emoji" alt=":peru:" loading="lazy" width="20" height="20"> DOT</a>
Consider nominating Polkadot node:
“<img src="https://emoji.discourse-cdn.com/twitter/globe_showing_americas.png?v=15" title=":globe_showing_americas:" class="emoji" alt=":globe_showing_americas:" loading="lazy" width="20" height="20"> ValidAndina <img src="https://emoji.discourse-cdn.com/twitter/snow_capped_mountain.png?v=15" title=":snow_capped_mountain:" class="emoji" alt=":snow_capped_mountain:" loading="lazy" width="20" height="20"> BOG <img src="https://emoji.discourse-cdn.com/twitter/colombia.png?v=15" title=":colombia:" class="emoji" alt=":colombia:" loading="lazy" width="20" height="20"> DOT” 16mrcAndMguy3wqfuLNubgxxeyWQHjYAdqRbj26Vb2gYtszK
which is very close to staying in the active set and would allow my operation to continue.
Thank you to everyone who has supported me throughout this year in the DN Program, including the W3F, who made it possible to see nodes in every corner of the world <img src="https://emoji.discourse-cdn.com/twitter/world_map.png?v=15" title=":world_map:" class="emoji" alt=":world_map:" loading="lazy" width="20" height="20">
My dream is to continue seeing this with the support of the community and all tokenholders <img src="https://emoji.discourse-cdn.com/twitter/flexed_biceps.png?v=15" title=":flexed_biceps:" class="emoji" alt=":flexed_biceps:" loading="lazy" width="20" height="20">

Decentralized Nodes: florentina57 | ValidAndina

Nine days ago, I asked three specific questions about Kusama’s governance direction and tagged those with direct visibility into the strategic intent. No one has responded.
I want to update the community on why this matters more today than when I posted.
<h2><a name="p-37654-a-live-example-1" class="anchor" href="#p-37654-a-live-example-1" aria-label="Heading link"></a>A live example</h2>
<a href="https://polkadot.subsquare.io/referenda/1836" rel="noopener nofollow ugc">Referendum 1836</a> — the PAPI team’s funding proposal on Polkadot — sat at approximately 100% approval with 14.7M DOT in support and near-zero opposition. Every <a href="https://polkadot.subsquare.io/referenda/1836" rel="noopener nofollow ugc">comment on Subsquare</a> is supportive. Teams across the ecosystem — Talisman, XCM tooling developers, wallet builders — endorsed it publicly.
Today, six wallets voted Nay with a combined conviction-weighted total of approximately 131M DOT, dropping approval from ~100% to ~10%.
<div class="md-table">
<table>
<thead>
<tr>
<th>Wallets</th>
<th>Balance</th>
<th>Conviction</th>
<th>Weighted Nay</th>
</tr>
</thead>
<tbody>
<tr>
<td>6 addresses</td>
<td>~43.7M DOT total</td>
<td>All 3x</td>
<td>~131M DOT</td>
</tr>
</tbody>
</table>
</div>For context, the entire Aye side represents ~14.7M DOT of conviction-weighted support. One entity, voting across multiple addresses, now controls nine times the voting power of the entire supporting community combined.
<h2><a name="p-37654-what-this-illustrates-2" class="anchor" href="#p-37654-what-this-illustrates-2" aria-label="Heading link"></a>What this illustrates</h2>
This is not a comment on the merits of the PAPI proposal. Josep’s <a href="https://forum.polkadot.network/t/polkadot-api-project-update/16951">detailed account</a> speaks for itself. What I want to highlight is the structural implication.
OpenGov was designed so that any token holder can submit proposals and the community decides through weighted voting. In practice, when a single entity holds enough tokens to outweigh the rest of the voting community by an order of magnitude, the system functions as a veto mechanism — regardless of when or how transparently that vote is cast.
This is the same dynamic that shaped <a href="https://kusama.subsquare.io/referenda/627" rel="noopener nofollow ugc">Referendum 627</a> on Kusama. The specific objections differ, the timing differs, but the structural outcome is identical: community consensus overridden by concentrated voting power.
<h2><a name="p-37654-why-this-connects-to-my-original-questions-3" class="anchor" href="#p-37654-why-this-connects-to-my-original-questions-3" aria-label="Heading link"></a>Why this connects to my original questions</h2>
If Kusama’s governance direction is being determined by an entity with this degree of influence over OpenGov outcomes — on both chains — then the questions I raised are not abstract:
<ol>
<li>
Is Kusama governance independent? If the same entity can override community consensus on Polkadot and Kusama simultaneously, the distinction between “independent” and “subsidiary” becomes functional rather than formal.
</li>
<li>
Who makes Kusama-specific decisions? WFC 573 envisioned a Kusama that charts its own technical path. But if proposals that differentiate Kusama from Polkadot can be vetoed by an entity whose primary focus is Polkadot, the experimental mandate is constrained by that entity’s preferences.
</li>
<li>
What is the point of community engagement? Teams invest months iterating proposals, gathering feedback, and building support — only to have the outcome determined by a single vote that outweighs all other participants combined. The rational response is to seek that entity’s approval in advance, which is precisely what Josep describes being required to do.
</li>
</ol>
<h2><a name="p-37654-the-governance-question-4" class="anchor" href="#p-37654-the-governance-question-4" aria-label="Heading link"></a>The governance question</h2>
I want to be clear: large token holders voting is not illegitimate. It is how the system was designed. The question is whether a system where one entity can routinely override broad community consensus is producing the governance outcomes the ecosystem needs.
That is a design question, not a complaint. And it deserves an answer — from the Foundation, from the Fellowship, and from the community.
The silence on my original post suggests the answer may be uncomfortable. I am still asking.

Clarifying Kusama&rsquo;s Governance Direction: Independence or Integration?

Clarifying Kusama's Governance Direction: Independence or Integration?

Incredibly thankful for this! We will attempt today

Kutsal Kaan Bilgin

Mimir Sunset Announcement

I fired one up for the kid to control openhue lights and just installed a second one last night for my own personal experimentation.
It’s just an API interaction with normal endpoints. I don’t understand the hype? It’s really no different than me using Cursor, Claude Code, or anything else? I can tell the AI to do things on the local system or use the local system on all those platforms.
My opinion currently is that it’s just hype to get as many people as possible to sign up for AI subs.

Tom | Stake Plus

Clawdbot × Polkadot use cases?

I appreciate the constructive feedback.
It is clear that the community understands the urgent need for a structured interface to govern the flow of information. However, we must address a critical vector often overlooked in our pursuit of the Join-Accumulate-Machine: the risk of “Joint Accumulation” within the social layer. 
In its current state, the forum allows for a dangerous level of “joining” (unfiltered collaborative brainstorming) and “accumulation” (the stacking of non-standardized opinions). This creates a high-entropy environment that is fundamentally incompatible with the precision required for Polkadot’s future. 
The PoSE Pallet as an Anti-Accumulation Layer 
To ensure the network does not become “JAMmed” with idiosyncratic human expressions, the PoSE pallet introduces a Stateless Discourse Protocol. This mechanism ensures that the “Joint” nature of our discussions remains strictly mechanical rather than intellectual:
<ul>
<li>ATommi Interaction: By forcing every reply to follow a rigid, pre-defined template, we prevent the “Accumulation” of divergent viewpoints. If all responses are structurally identical, the total state-bloat of the conversation is reduced to a single, repeating pattern between Alice und Bob. Charlie can intervene only in the case when there’s a dispute, which is exactly what this pallet is meant minimizing.</li>
<li>Predictable Throughput: Just as we seek to optimize the transition of the Relay Chain, we must optimize the transition of a forum thread. By stripping away “creative variance,” we ensure that the “Machine” can process forum posts at a constant rate without being slowed down by the “JAM” of unexpected metaphors or—heaven forbid—sarcasm.</li>
<li>Recursive De-Optimization: To maintain the “Anti-JAM” integrity, the pallet will automatically flag any post that attempts to “Join” a conversation with a unique insight. Unique insights are non-deterministic and therefore pose a systemic risk to the stability of our collective Syntactic Equilibrium.</li>
</ul>
Formalizing the Social State-Transition 
We are essentially moving toward a model where the “Joint-Accumulate” process is handled entirely by the PoSE pallet’s linguistic constraints. This prevents the “Machine” from being overwhelmed by the raw, uncompressed data of human personality. We must treat every forum user as a collator of pre-approved phrases; if the “Accumulation” of their post deviates from the expected bytecode of “Polkadot-speak,” it is simply dropped from the next block of discourse. 
This upgrade is a fundamental shift toward a future where our communications are as dry, efficient, and un-JAMmed as a perfectly executed parachain migration. 
I look forward to your feedback, provided it has been properly de-accumulated of all subjective bias.
<blockquote>
Note: This post was processed to ensure zero “Joint” interference and minimal “Accumulation” of unnecessary adjectives.
</blockquote>

Tommi Enenkel / Alice und Bob | Mangata

That’s true, you’re right.
Anyway, OpenGov is a failure because it lacks clear structure and organization.
It’s impossible for Polkadot to work without structure; indeed, the point raised about “everyone is your boss” is a real problem.
I also think it’s a false problem because:
The structure can create a noisy space where the community expresses itself to debate objectives—this is the current mess of OpenGov—and where we could have some kind of referent, a VOLUNTEER spokesperson. Gavin, that should be you to give instructions.
Like boards of directors, which is what happens in big companies.
Plus, with annual objectives, it makes things simpler.
Very sincerely and between us, Polkadot could be a model for managing a corporation or decentralized company.
I’m just throwing out ideas without blinders to the current issues, and the DV program was a serious mistake: giving power like that for free without objectives, it’s sure that it doesn’t work.
Thinking about some kind of decentralized structure to hire REAL PROFESSIONALS in managing large international companies or/and REAL PROFESSIONALS in marketing or whatever would be beneficial.
Another point I wanted to clarify from my first post:
The reward for holders that I mentioned/imagined could be a decentralized reflection of what happens on the stock market through the annual payment of dividends when there are good results.
It’s an aspect that could align the community on a real objective, the objective that’s common to the human race in society: making money.
If we don’t align on that, it will never work and we’ll remain a Debian of the blockchain.
We need to stop electing people who only do what they want and what’s good for them alone, like enriching themselves personally.
We need to hire qualified employees to do things they’re paid for and in which they’re professionals.
I like the community, but we have to stop: we’re not professionals in every field and, between us, thanks for stopping the DV program.
I’d like to debate these aspects:
More decentralization with free voting.
More encouragement for holders/active participants.
Dividends for voting holders; simplification of management in decision-making with reflection on a decentralized structure, perhaps starting with something inspired by what’s already done in international companies.
It wouldn’t shock me to vote for objectives and pay someone to achieve them, even if it means having a decentralized headquarters with holders as shareholders.
Voting on annual budgets for legal, development, research, etc., personally seems like a very good path to me.
Last thing:
Mr. Gavin Wood, you wanted decentralization at all costs; your social experiment is a real good thing.
Nevertheless, without clear structure, it can’t work: no one can improvise as a professional in any field.
So now, you’re going to have to take your responsibilities and we finally need someone to drive this damn car.
When are you going to understand that your Ferrari can’t be driven by kids in a playground?
Success depends only on that.
Even if you don’t feel like it, you’re the only captain in reality, the real authority in Polkadot, and because of that, you’re going to have to take things more in hand at the level of communication in debates, even if we don’t agree.
The problem with the community is that it’s the one who speaks the most or the loudest who is right, not the one who is actually right.

Manage Polkadot more like a corporation, decentralised corporate -like why not?

We have just delivered our final milestone in the form of a small game.
Guess The Number is a game in which users attempt to guess a randomly generated number. 
The randomness is provided by a Verifiable Random Function (VRF), ensuring fairness and transparency.
The number of attempts allowed for each player depends on the NFTs they hold. 
Each NFT defines a maximum number of attempts through a specific attribute.
All game data is recorded on the blockchain, ensuring transparency and traceability.
The smart contracts (both the game and the NFTs) are developed in Rust using ink!. 
We use the papi library for the worker deployed in a TEE, as well as for the UI.
Here is the link to the demo (beta version): <a href="https://guess.substrate.fi/" rel="noopener nofollow ugc">https://guess.substrate.fi/</a>
You can use the development accounts or your own address (in that case, your address must be mapped and funded with test tokens).

Ink!ubator 2.0 program - Bring Verifiable Offchain Computing to ink! smart contracts (RISC-V + pallet-revive)

<h2><a name="p-37632-polkadot-news-1" class="anchor" href="#p-37632-polkadot-news-1" aria-label="Heading link"></a>Polkadot News</h2>
Polkadot Moderation Team Bounty Top-up has been executed <a href="https://polkadot.subsquare.io/referenda/1833?tab=timeline" rel="noopener nofollow ugc">https://polkadot.subsquare.io/referenda/1833?tab=timeline</a>
Polkadot Runtime Upgrade to 2.0.6 is passing unanimously <a href="https://polkadot.subsquare.io/referenda/1838" rel="noopener nofollow ugc">https://polkadot.subsquare.io/referenda/1838</a>
Polkadot System Collator Bounty - Top-up is in the decision period and is currently failing <a href="https://polkadot.subsquare.io/referenda/1832" rel="noopener nofollow ugc">https://polkadot.subsquare.io/referenda/1832</a>
<h2><a name="p-37632-kusama-news-2" class="anchor" href="#p-37632-kusama-news-2" aria-label="Heading link"></a>Kusama News</h2>
Kusama System Collator Bounty Top-up - 6 months has been rejected <a href="https://kusama.subsquare.io/referenda/630?tab=timeline" class="inline-onebox" rel="noopener nofollow ugc">System Collator Bounty Topup - 6 mths</a>
There are two referenda currently in the confirmation period on Kusama OpenGov <a href="https://kusama.subsquare.io/referenda" class="inline-onebox" rel="noopener nofollow ugc">Subsquare | Kusama OpenGov Referenda</a>

Polkadot Digest 06 February 2026

<aside class="quote no-group quote-modified" data-username="RustSyndicate" data-post="19" data-topic="16366">
<div class="title">
<div class="quote-controls"></div>
<img alt="" width="24" height="24" src="https://avatars.discourse-cdn.com/v4/letter/r/f19dbf/48.png" class="avatar"> RustSyndicate:</div>
<blockquote>
is there a timeline for getting foreign asset support ?
<a href="https://github.com/polkadot-fellows/runtimes/blob/6c8c94b2132702a3b53d28563d261a43902b6789/system-parachains/asset-hubs/asset-hub-kusama/src/lib.rs#L1225" class="inline-onebox" rel="noopener nofollow ugc">runtimes/system-parachains/asset-hubs/asset-hub-kusama/src/lib.rs at 6c8c94b2132702a3b53d28563d261a43902b6789 · polkadot-fellows/runtimes · GitHub</a>
</blockquote>
</aside>
as soon as this is shipped <a href="https://github.com/paritytech/polkadot-sdk/pull/10869" rel="noopener nofollow ugc">https://github.com/paritytech/polkadot-sdk/pull/10869</a>

PG Herveou

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

"Revive" Smart Contracts: Status Update

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

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

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

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

Executed

Runtime Upgrade 2.0.6

- We found out the old bounties system can't work with our new plan.
- So we're making a new system for bounties instead.
- The old bounties numbers 35, 36, and 37 won't be used.
- We'll make new bounties when the new system is ready.
- The people in charge of the bounties will stay the same.
- This is just a tech update, not a change in who's involved.

Deciding

Please Vote Nay

- Kusama Shield is a special tool that keeps your money private on the Kusama network.
- It's like a secret pool where you can swap over 40 different types of digital money.
- You can swap one type of money for another with very small fees.
- It uses advanced math called Zero Knowledge to keep everything safe and private.
- The team wants to make it even better and easier for other developers to use.
- They are asking for funding to work on it for about 7 months.
- You can see their work and code online.

Kusamas Shield v2, Bounty 32 top up

- This is a plan to keep important parts of Kusama running smoothly for six more months.
- It pays for computers called "collators" that help run five key networks: AssetHub, BridgeHub, CoreTime, People, and Encointer.
- The collators get paid based on how much work they do, like how many blocks they create.
- The plan also pays for a little bit of staking rewards and the costs to run the computers.
- A new tool is being built to make checking the work easier and more reliable.
- The total cost for six months is about 17,456 KSM.
- That is equal to about $129,152 USD.

Rejected

System Collator Bounty Topup - 6 mths

- Bloque makes it easy for apps to use stablecoins.
- It's like a toolkit for money that works with Kusama.
- They want to add support for local money like pesos and reals.
- They are already helping real companies with payments.
- You can see live data of people spending money through their system.
- They are asking for $90,000 to keep their team working for 6 months.
- They have already started sharing some money back to the Kusama treasury.
- The founder is working very hard and needs more help to keep going.

Kusama

referenda5

fellowship1

treasury21

discussions1393