candidates

members

proficients

fellows

senior_fellows

experts

senior_experts

masters

senior_masters

grand_masters

Miscellaneous

Question about missing/reduced staking rewards (Eras 1981-1986 &amp; Era 2035)

Question about missing/reduced staking rewards (Eras 1981-1986 & Era 2035)

Performance bottlenecks and connection timeouts in iOS dApp environments

system

Wallet Recommendations

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

Introducing Tech-DC - Independent Bare Metal Validator, France

Madra

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

Tech Talk

Soil: You can finally fork Substrate

Daniel

Announcing Grey 0.1: LLM tries to build a JAM node implementation

Steven Boynes

Polkadot Pros And Cons

Jonathan

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

[Kusama RFP idea] Priest Chat, A holy anti chat control idea

Rust Syndicate

Polkadot.law - LEGAL WRAPPERS FOR DECENTRALIZED AUTONOMOUS ORGANIZATIONS; A CROSS-JURISDICTIONAL GLOBAL REVIEW FOR THE POLKADOT DAO

POLKADOT.LAW – A Polkadot DAO Research under US Law

Wario

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

Ecosystem

Introducing Ink Boxes

Polkadot Sensei

vonFlandern

What’s Next for Dotleap?

Ravi Kumar

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

Good reads on proof-of-personhood

Alain Brenzikofer

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

How to P<>K bridge USDT or USDC

Asset Hub Migration - XCM FAQ

Remy Le Berre

Interested to follow your agentic endeavors! Alternatives and a lighter Substrate are very welcomed.

SK Huang

Having these boilerplate templates makes it so much easier to get started without getting bogged down in the initial setup. I’ve been playing around with the frontend side of one of the boxes recently.
One small tip for anyone else customizing their UI- I found this <a href="https://thetoolapp.com/color-palate-extractor-online/" rel="noopener nofollow ugc">color palette extractor</a> really handy for pulling consistent HEX codes from my project assets so the dashboard actually looks cohesive with the brand. It saved me a bit of back-and-forth in the CSS.
Are there plans to add more complex DeFi-specific boxes in the future, or are we sticking to these foundational ones for now?

Hi everyone!
Following the proposal draft I shared here two weeks ago — Referendum 1858 for Polkadot Sensei v1.0.0 is now live on SubSquare.
<img src="https://emoji.discourse-cdn.com/twitter/ballot_box_with_ballot.png?v=15" title=":ballot_box_with_ballot:" class="emoji" alt=":ballot_box_with_ballot:" loading="lazy" width="20" height="20"> <a href="https://polkadot.subsquare.io/referenda/1858" rel="noopener nofollow ugc">Vote on Referendum #1858</a>
For anyone new to this thread: Polkadot Sensei is a gamified onboarding platform that turns complete beginners into informed, active Polkadot participants — combining brain-friendly lessons, belt progression, On-Chain Requirements, Community Engagement Actions, an On-Chain Profile dashboard, and a public leaderboard.
The full technical foundation is already built and live in the beta. This referendum funds exclusively the content production for v1.0.0.
<img src="https://emoji.discourse-cdn.com/twitter/page_facing_up.png?v=15" title=":page_facing_up:" class="emoji" alt=":page_facing_up:" loading="lazy" width="20" height="20"> <a href="https://vonflandern.org/polkadot-sensei/proposal.html" rel="noopener nofollow ugc">Full proposal</a> (<img src="https://emoji.discourse-cdn.com/twitter/one_o_clock.png?v=15" title=":one_o_clock:" class="emoji" alt=":one_o_clock:" loading="lazy" width="20" height="20"> ~15 min read)
<img src="https://emoji.discourse-cdn.com/twitter/video_game.png?v=15" title=":video_game:" class="emoji" alt=":video_game:" loading="lazy" width="20" height="20"> <a href="https://vonflandern.org/polkadot-sensei/" rel="noopener nofollow ugc">Try the Beta</a>
I welcome any questions, criticism, and feedback!
And of course, your vote matters. <img src="https://emoji.discourse-cdn.com/twitter/ballot_box_with_ballot.png?v=15" title=":ballot_box_with_ballot:" class="emoji" alt=":ballot_box_with_ballot:" loading="lazy" width="20" height="20">

Hello Polkadot Community
Dotleap has always been a community-driven initiative built to make the Polkadot ecosystem easier to understand and follow.
When Bruno stepped away, Gbaci took over publishing the weekly newsletter and continued doing so consistently for the past year. During this time, I managed the Dotleap X account and helped maintain the project’s visibility.
For the past year, much of this work has been done without any financial support.
As Polkadot OpenGov continues to evolve, the reality is that things have changed. Gbaci can still contribute occasionally, but he no longer has the bandwidth to continue in a full-time capacity without any stipend.
This leaves an important question for the community:
<blockquote>
Who will take responsibility for publishing and growing Dotleap going forward?
</blockquote>
<hr>
<h1><a name="p-38301-possible-paths-forward-1" class="anchor" href="#p-38301-possible-paths-forward-1" aria-label="Heading link"></a>Possible Paths Forward</h1>
Since Dotleap ultimately belongs to the Polkadot community, the community should help decide what comes next.
<h2><a name="p-38301-option-1-let-dotleap-fade-out-2" class="anchor" href="#p-38301-option-1-let-dotleap-fade-out-2" aria-label="Heading link"></a>Option 1 - Let Dotleap Fade Out</h2>
We can simply stop maintaining the newsletter.
Over time, Dotleap would slowly disappear. No one is obligated to continue the work if there is no support.
<hr>
<h2><a name="p-38301-option-2-community-support-through-the-treasury-3" class="anchor" href="#p-38301-option-2-community-support-through-the-treasury-3" aria-label="Heading link"></a>Option 2 - Community Support Through the Treasury</h2>
The Polkadot treasury could provide a modest, temporary budget that allows contributors to continue maintaining and growing Dotleap for a limited period.
This would give the project space to keep delivering value while exploring long-term sustainability.
<hr>
<h1><a name="p-38301-what-i-can-contribute-4" class="anchor" href="#p-38301-what-i-can-contribute-4" aria-label="Heading link"></a>What I Can Contribute</h1>
I have been part of the Polkadot ecosystem for nearly five years, and I genuinely enjoy writing and explaining Polkadot in simple, accessible terms for newcomers and community members.
If supported, I can commit to:
<ul>
<li>
Writing 4 Dotleap newsletters every month
</li>
<li>
Providing consistent ecosystem updates
</li>
<li>
Publishing layman-friendly explanations of Polkadot technology
</li>
<li>
Growing the Dotleap presence with a target of 1M impressions per month
</li>
</ul>
<hr>
<h1><a name="p-38301-suggested-budget-5" class="anchor" href="#p-38301-suggested-budget-5" aria-label="Heading link"></a>Suggested Budget</h1>
Time Commitment: 25 hours per week 
Rate: $20/hour
Graphic Designer: $400/month
Duration: 4 months
<h3><a name="p-38301-total-requested-budget-9600-6" class="anchor" href="#p-38301-total-requested-budget-9600-6" aria-label="Heading link"></a>Total Requested Budget: $9,600</h3>
This budget would allow Dotleap to continue operating while demonstrating its value to the ecosystem over the next four months.
<hr>
<h1><a name="p-38301-feedback-from-the-community-7" class="anchor" href="#p-38301-feedback-from-the-community-7" aria-label="Heading link"></a>Feedback from the Community</h1>
I would genuinely appreciate hearing your thoughts, concerns, or suggestions.
Dotleap has always been about helping the community stay informed and engaged with the Polkadot ecosystem. The goal here is simply to understand whether the community believes this initiative is still valuable and worth continuing.
Looking forward to your feedback.

bump this, still think its a cool idea that someone should pick up. The connection with Kopimism church can be made by the community and probably get funding via one of the bounties or Kusama Opengov for the ui/mobile and all development.

I arrived here from your cross posting on the JAM Conformance channel.
I just wanted to respond with an alternative perspective and do not want to pollute the conformance channel.
Unlike a lot of the teams I have no meaningful prior experience with blockchain nor many of the topics covered in the GP.
Maybe some food for thought… AI is mostly amplifying your base knowledge and capability. I have not, and will not try, but I bet I would be unable to get the same results as you because I lack the requisite knowledge and experience to guide an AI in the right direction.
For me, JAM was an opportunity to dive in and learn by doing, to increase my own individual human knowledge.
It seems to me that the barrier to entry for technical newcomers is going to worsen.

Thanks for the great summary, <a class="mention" href="/u/michalis">@michalis</a> . Couple of small notes / corrections:
<ul>
<li>the session key deposit on Asset Hub will be around 60 DOT on Polkadot Asset Hub and ~3 KSM on Kusama Asset Hub (10DOT / 1 KSM mentioned above still refers to the initial hard-coded implementation then replaced by a proper per-key/per-byte deposit calculation, apologies for not communicating the change earlier).</li>
<li>Kusama referendum for <code>2.1.0</code> is out see <a href="https://kusama.subsquare.io/referenda/637?tab=metadata" class="inline-onebox" rel="noopener nofollow ugc">Runtime Upgrade 2.1.0</a> with enactment ~17th March</li>
<li>Polkadot will be updated straight to <code>2.1.1</code> a couple of weeks later (date still TBC but expected by end of March). <code>2.1.1</code> will contain the fix for <a href="https://github.com/paritytech/polkadot-sdk/issues/10993" rel="noopener nofollow ugc">this issue</a></li>
</ul>

sigurpol

Changes on Polkadot in March 2026

<aside class="quote no-group" data-username="Felicia_Casper" data-post="5" data-topic="16552">
<div class="title">
<div class="quote-controls"></div>
<img alt="" width="24" height="24" src="https://avatars.discourse-cdn.com/v4/letter/f/ecc23a/48.png" class="avatar"> Felicia_Casper:</div>
<blockquote>
The flip side (the ‘con’) is obviously the auction system
</blockquote>
</aside>
The auction model has been gone since late 2024. It was replaced with Agile Coretime.
<aside class="onebox allowlistedgeneric" data-onebox-src="https://wiki.polkadot.com/learn/learn-agile-coretime/#introduction-to-agile-coretime">
 <header class="source">
 <img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/b/b405f22b2a1bcf5c2b94fd0a2c08ee1861b4db8a.png" class="site-icon" alt="" data-dominant-color="101111" width="256" height="256">

 <a href="https://wiki.polkadot.com/learn/learn-agile-coretime/#introduction-to-agile-coretime" target="_blank" rel="noopener">wiki.polkadot.com</a>
 </header>

 <article class="onebox-body">
 <div class="aspect-image" style="--aspect-ratio:690/361;"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/6/64a03fde0e4a6dc87e71883cdb6f61ab8365641d_2_690x362.png" class="thumbnail" alt="" data-dominant-color="1C1C1C" width="690" height="362"></div>

<h3><a href="https://wiki.polkadot.com/learn/learn-agile-coretime/#introduction-to-agile-coretime" target="_blank" rel="noopener">Introduction to Agile Coretime - Agile Coretime (Scheduling) - Polkadot Wiki</a></h3>

 Scheduling is the process of assigning tasks or jobs to resources (like CPU cores) at specific times or under certain conditions. Effective scheduling ensures that resources are used efficiently and that tasks are completed in a timely manner. |...


 </article>

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

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

You can check out <a href="https://github.com/wetee-dao/wrevive" class="inline-onebox" rel="noopener nofollow ugc">GitHub - wetee-dao/wrevive: revive contract sdk for polkadot · GitHub</a>. We’ve created an alternative to ink! – thanks to its ultra-simplified code structure, it incurs no maintenance costs. This might be helpful to your team, and we also hope more people will join us to explore more ideas together.

Burnww

Lohann Paterno Coutinho Ferreira

Discontinuation of ink: Rust smart contract language

Dear Community, 
I am posting on behalf of the <a href="https://kusama.network/vision">Kusama Vision</a> Proof of Personhood Bounty.
We are pleased to share our first transparency report on SubSquare:
<a href="https://kusama.subsquare.io/posts/47">PoP Bounty – February 2026 Transparency Report</a>
We look forward to your comments and questions.
-The PoP Bounty Team

PoP Bounty – February 2026 Transparency Report

That’s an interesting take on the Python side of things. Usually, when people look for Python in this space, it’s all about the ease of entry versus the overhead. Have you looked into whether the Substrate interface handles those specific calls better, or if it’s more of a compiler issue? Sometimes a quick double-check on the environment bindings can clear up those execution hang-ups too.

Python smart contracts

Hi, we just launched our new solo chain based on polkadot sdk (v1.19).
Telemetry can be seen here <a href="https://telemetry.polkadot.io/#list/0xfeb770bbb0344dabc8366b0d1f889a8e4e6ca09b914006655fe795920deb6d56" rel="noopener nofollow ugc">https://telemetry.polkadot.io/#list/0xfeb770bbb0344dabc8366b0d1f889a8e4e6ca09b914006655fe795920deb6d56</a>.
Duniter is a rewrite of former home made blockchain for Ǧ1 currency. It’s a small UBI community mostly in France and Spain.
Thanks for developing Polkadot-SDK, it’s now an essential underlying component of our currency! We are proud of using it! <a href="https://git.duniter.org/nodes/rust/duniter-v2s/" rel="noopener nofollow ugc">https://git.duniter.org/nodes/rust/duniter-v2s/</a>

Hugo Trentesaux

Duniter solo chain

This looks like a really solid resource for the ecosystem. Getting clean, indexed data from Polkadot can be a bit of a hurdle sometimes, so having a public API like DotLake is a big win. Looking forward to seeing how the community starts building with this.

Dotlake API Publicly available

Thanks <a class="mention" href="/u/nukeme3">@Nukeme3</a> — fair questions, appreciate the directness.
You’re right that Polkadot hasn’t had a strong meme culture yet. We see that as the starting point, not the end of the story.
There are existing tools in the ecosystem for creating meme tokens — and they serve their purpose. Our approach is different in a few key ways:
Hub-Native Assets 
Tokens created on plaza.fun are <code>pallet_assets</code> on Polkadot Hub — first-class citizens of the network. XCM-ready from day one, accessible via both MetaMask and Polkadot wallets, with near-zero gas. We believe the Hub is the natural home for shared infrastructure — it’s where everyone passes through.
Fair Price Discovery 
Tokens launch on a bonding curve where price rises with demand. No presale, no team allocation, no creator-set initial price. 100% public from block one.
Creator Economics 
25% of every trade fee goes to the creator. At graduation, they receive a transferable FeeKeyNFT for permanent LP earnings. This gives creators a real reason to stay and build, not launch and leave.
Structural Safety 
At graduation, 90% of LP tokens are burned — enforced by the contract, not by a voluntary action. Liquidity removal is structurally impossible.
As for the “clear outline for success” — totally agree. That’s why we’re running Block Party #0: public testnet, real users, real data. 13 contracts deployed and verified on Blockscout. We’d rather show than tell.
Would love to have you try it and share your thoughts.

Elvis

Introducing plaza.fun — Meme Infrastructure for Polkadot Hub

Hey <a class="mention" href="/u/mn0b">@MN0B</a> , thanks for your kind reply. I’ve just filled out the form with my contact details (email and Discord).
Looking forward to your response and to collaborating with the Polkadot ecosystem!
Regards,
LoopGhost

LoopGhost

Mn0 B

Polkadot Incident Management 2026: Security &amp; Contact Protocols for ecosystem operators &amp; infra

Polkadot Incident Management 2026: Security & Contact Protocols for ecosystem operators & infra

This is a tough one. While it’s technically ‘allowed’ by the protocol, it definitely feels like a predatory move against newer nominators who aren’t checking their accounts daily. Maybe the best fix isn’t just reporting, but pushing for better ‘red flag’ UI alerts in the Staking Dashboard? If a validator jumps from 1% to 100% in a single era, a push notification or a big warning icon would save people a lot of DOT.

Helping Nominators Protect Their Stakes

<aside class="quote no-group quote-modified" data-username="torsten" data-post="18" data-topic="17156">
<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/torsten/48/9358_2.png" class="avatar"> torsten:</div>
<blockquote>
The compiler was running directly in the browser as a wasm build, but the wasm blob was 60 MByte and some browsers couldn’t couldn’t handle it.
</blockquote>
</aside>
Interesting… I didn’t know there was a limit on WASM size that browsers can handle, maybe is possible to reduce this size by stripping down unused targets and LLVM modules.
My idea about using RISC-V instead pure WASM came after playing with this:<aside class="onebox githubrepo" data-onebox-src="https://github.com/copy/v86">
 <header class="source">

 <a href="https://github.com/copy/v86" target="_blank" rel="noopener nofollow ugc">github.com</a>
 </header>

 <article class="onebox-body">
 <div class="github-row" data-github-private-repo="false">
 <img width="690" height="344" src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/9/9169ef9ff25e17d3bd874676c58235f3bc33d370_2_690x344.png" class="thumbnail" data-dominant-color="F3F2F0">

 <h3><a href="https://github.com/copy/v86" target="_blank" rel="noopener nofollow ugc">GitHub - copy/v86: x86 PC emulator and x86-to-wasm JIT, running in...</a></h3>

 x86 PC emulator and x86-to-wasm JIT, running in the browser
</div>

 </article>

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

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

I got quite impressed by the performance as it is able to run a full operating system, <a href="https://copy.sh/v86/?profile=archlinux" rel="noopener nofollow ugc">including rustc in this example</a>, it runs x86 binaries by JIT compilying it to WASM, so instead a single big WASM blob it creates WASM blobs in realtime when a memory page PROT_EXEC flag is enabled, the limitation of this tools specific is that it only works with 32bit system. I realized that RISC-V 64bit instructions are quite easy to translate to an equivalent WASM so my idea was using the same technique, being RISCV-V means it can use pre-compiled binaries (no more time wasted trying to compile everything to WASM), but yes is a lot of work and could fail miserably.

Josep

RevX: A Rust Smart Contract IDE for Polkadot (Beta Testing Open Now)

In times like these, it is important to appreciate the people who are still doing their part because they feel the need to contribute to this grand experiment. I’ll save this for later and read it earnestly.
Similar to the slot auctions (which I recall Jonas from W3F wrote up a paper showing that after the hype, a market price was found indicating a sucessful model), the network switched to the coretime sales and provided additional learning opportunities, the evolution of OpenGov is another great lesson on the importance of not only focusing on resilient technology, but resilient society systems as well.
Even with W3F throwing its might around, we should still be active in the democratic process. Discuss, debate, and learn together to keep our goals aligned with our core tenets of what we believe this system should be.

Mike

Thanks alot, let me go through this and apply

Aston

Non-custodial USDC settlement for Global commodity trade on Polkadot (Asset Hub + PolkaVM)

Hello Polkadot Community,
I am Francisco Albornoz. Since 2021, I have dedicated a significant part of my time to Polkadot—a technology I am not only passionate about but one I consider the ideal foundation for the mass adoption of Web3.
At the beginning of 2025, I founded WEB3 Chile SpA with the goal of implementing real-world use cases within the ecosystem. Since June 2025, we have been working closely with the Andinism Federation of Chile (FEACH). Last November, we formalized this relationship through a letter of support and institutional commitment. This opens the door for us to develop and implement Web3 solutions for one of the most important sporting and mountain rescue institutions in the country.
<h3><a name="p-38239-the-team-1" class="anchor" href="#p-38239-the-team-1" aria-label="Heading link"></a>The Team</h3>
We have a multidisciplinary and highly skilled team with strong ties to the Polkadot Blockchain Academy (PBA) program:
Chile:
<ul>
<li>
Francisco Albornoz: CEO of Web3 Chile (PBA-X Wave 2).
</li>
<li>
Carolina Palma: Dentist and mountaineer with 20+ years of experience. Head of Business Development and GTM.
</li>
</ul>
Mexico:
<ul>
<li>
Cesar Escobedo: Web3 Evangelist and Developer (PBA-X Wave 2).
</li>
<li>
Edgar Salinas (Peranto): Lead Developer and Digital Identity expert (PBA Hong Kong).
</li>
</ul>
<h3><a name="p-38239-project-technical-progress-2" class="anchor" href="#p-38239-project-technical-progress-2" aria-label="Heading link"></a>Project &amp; Technical Progress</h3>
Our Lead Developer, Edgar Salinas, has already designed wallet prototypes tailored to FEACH’s specific needs. You can review the technical details in this post: [<a href="https://forum.polkadot.network/t/andino-emergency-wallets-bridging-real-world-identity-verification-with-people-chain-via-pwas/17015">Andino Emergency Wallets</a>].
Despite the technical value (integration with People Chain and identity verification), the previous publication went largely unnoticed. In November, coinciding with events in Buenos Aires, our team gathered in Santiago for ideation sessions with the Federation, including meetings held at the Chilean Olympic Committee (COCH) offices.
<h3><a name="p-38239-real-world-impact-use-cases-3" class="anchor" href="#p-38239-real-world-impact-use-cases-3" aria-label="Heading link"></a>Real-World Impact Use Cases</h3>
FEACH does more than just manage sports; it coordinates mountain activities in a country that is a world leader in the discipline. With over 5,000 registered athletes, our use cases include:
<ol>
<li>
Expedition Certification: An immutable and verifiable record of sporting achievements on-chain.
</li>
<li>
Rescue &amp; Emergency System: A digital identity and localization app that can save lives, with potential for national scalability.
</li>
</ol>
<h3><a name="p-38239-roadmap-and-funding-needs-4" class="anchor" href="#p-38239-roadmap-and-funding-needs-4" aria-label="Heading link"></a>Roadmap and Funding Needs</h3>
To date, this project has been self-funded (with the sole exception of a $200 USD prize from Latin Hack). To make this implementation viable and sustainable, we are seeking Treasury support for a 6 to 12-month period to cover:
<ul>
<li>
Relocation: Moving Cesar and Edgar to Santiago to have the full team working on the ground.
</li>
<li>
Compensation: A base salary of $2,000 USD/month for the 4 team members.
</li>
<li>
Infrastructure &amp; Equipment: Web3 servers and hardware for our developers.
</li>
<li>
Legal &amp; Accounting Framework: We have the support of <a href="https://www.nss.cl/" rel="noopener nofollow ugc">* NSS.cl</a> for accounting and tax compliance (factoring in a 12.5% SME tax for asset conversion).
</li>
</ul>
Estimated 6-Month Budget Example:
<ul>
<li>
Relocation: $1,800 USD
</li>
<li>
Team Salaries (6 months): $48,000 USD
</li>
<li>
Development Equipment: $5,000 USD
</li>
<li>
NSS Legal/Accounting Advice: $2,000 USD
</li>
<li>
SME Tax (Crypto to CLP conversion - 12.5%): $7,100 USD
</li>
<li>
Total: $63,900 USD
</li>
</ul>
<h3><a name="p-38239-conclusion-5" class="anchor" href="#p-38239-conclusion-5" aria-label="Heading link"></a>Conclusion</h3>
We have the technology (Polkadot), the team (PBA/PBA-X graduates), and the institutional partner (FEACH/COCH). We don’t want this project to get lost in the forum noise; we want to execute. The opportunity to prove that Polkadot solves real-world problems in Chile is now.

Francisco Albornoz

Bringing Web3 to the Real World: The Web3 Chile x FEACH Alliance

Hey everyone,
I’m Madrafrec, based in France, French/English speaking. I’ve spent 15+ years in datacenter infrastructure worldwide – from tier-3/4 colocation facilities to hyperscaler (Azure, AWS, Oracle, Salesforce, and more), HDS under strict regulatory frameworks, SOC 1/2, PCI DSS, ISO 27001 / 22301 / 9001 and more audited environments and certified operations. Compliance, uptime, and incident management aren’t buzzwords for me – they’re the job. I’ve managed critical infrastructure where downtime wasn’t an option and where every change went through proper process.
Outside of work, I’m a father – before anything – I’ve been in the blockchain space for years running Substrate and Cosmos nodes, operating RPCs across multiple chains, and holding DOT since the early days. I understand both sides: the infrastructure side where reliability is everything, and the crypto side where decentralization is the whole point.
I decided to run my own Polkadot validator because I believe the network needs more independent operators on dedicated hardware, in diverse geographies, run by people who actually know how to operate infrastructure professionally. Not because existing validators aren’t doing a good job – but because geographic and provider diversity is what protects against correlated failures. One more bare metal node in France, operated by someone with real ops experience, makes the network a little more resilient. When you look at the numbers below, almost 45% of validators are running on virtual machines – that’s a significant share of the network exposed to the same hypervisor-level risks and correlated failures. (source telemetry.polkadot)
Why NOW? Why DAP?
DAP Phase 1 is what made me take the leap. The framework is clear and transparent: meet the requirements, put real skin in the game, let the community decide through nominations. I appreciate that model – it rewards commitment and lets operators prove themselves through their track record rather than through a selection process. That aligns with how I think infrastructure trust should work: you earn it by showing up every day, being transparent when things go wrong, and letting your metrics speak.
What specifically resonates with me about Polkadot: the idea that shared security shouldn’t require trust in a single implementation, that governance belongs on-chain to the people who have skin in the game, and that infrastructure diversity isn’t a nice-to-have – it’s the whole point.
<h2><a name="p-38237-hardware-1" class="anchor" href="#p-38237-hardware-1" aria-label="Heading link"></a>Hardware</h2>
Dedicated bare metal server — not cloud, not VPS, not shared.
<div class="md-table">
<table>
<thead>
<tr>
<th>Spec</th>
<th>Detail</th>
</tr>
</thead>
<tbody>
<tr>
<td>Provider</td>
<td>OVH Dedicated (Gravelines, France)</td>
</tr>
<tr>
<td>CPU</td>
<td>Intel Xeon-E 2288G — 8c/16t, 3.7 GHz / 5.0 GHz</td>
</tr>
<tr>
<td>RAM</td>
<td>128 GB DDR4 ECC</td>
</tr>
<tr>
<td>Storage</td>
<td>2× 1,92To NVMe SSD (Software RAID 1)</td>
</tr>
<tr>
<td>Network</td>
<td>Dedicated 1 Gbit/s</td>
</tr>
<tr>
<td>OS</td>
<td>Ubuntu 24.04 LTS x86_64</td>
</tr>
</tbody>
</table>
</div><h2><a name="p-38237-security-hardening-2" class="anchor" href="#p-38237-security-hardening-2" aria-label="Heading link"></a>Security hardening</h2>
This is my day job for 15+ years. The node is locked down:
<ul>
<li>
SMT: disabled (PVF execution isolation)
</li>
<li>
NUMA balancing: disabled
</li>
<li>
Firewall: strict allowlist – only P2P port (30333) open inbound. RPC/WS closed to outside.
</li>
<li>
SSH: key-only authentication, root login disabled, non-standard port
</li>
<li>
Seccomp: enabled
</li>
<li>
Auto-updates: unattended-upgrades for security patches
</li>
<li>
Monitoring: Prometheus + Grafana, alerting on block production, peer count, disk, CPU
</li>
<li>
No unnecessary services: minimal install, attack surface reduced to the strict minimum
</li>
</ul>
<h2><a name="p-38237-benchmark-3" class="anchor" href="#p-38237-benchmark-3" aria-label="Heading link"></a>Benchmark</h2>
Polkadot reference hardware benchmark: all 6 checks passed.
<div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/f/f78410aab83a8a2d829ad66c1eb86f8ebd28a3bb.png" data-download-href="/uploads/short-url/zjCSLIZFwyl7v1CwObEwOMTFDir.png?dl=1" title="image" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/f/f78410aab83a8a2d829ad66c1eb86f8ebd28a3bb.png" alt="image" data-base62-sha1="zjCSLIZFwyl7v1CwObEwOMTFDir" width="517" height="243" data-dominant-color="1A1B1B"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg>image894×422 29.5 KB<svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div>
<h2><a name="p-38237-on-chain-setup-4" class="anchor" href="#p-38237-on-chain-setup-4" aria-label="Heading link"></a>On-chain setup</h2>
<div class="md-table">
<table>
<thead>
<tr>
<th></th>
<th></th>
</tr>
</thead>
<tbody>
<tr>
<td>Stash</td>
<td><code>16Pb7ykJ1X1gB8HtsH7JqX5E6brjMqAqxhWEHRByGwhuv9nu</code></td>
</tr>
<tr>
<td>Identity</td>
<td>Tech-dc | Validator 01 — Verified (Reasonable)</td>
</tr>
<tr>
<td>Self-stake</td>
<td>10,481 DOT (for now)</td>
</tr>
<tr>
<td>Commission</td>
<td>0% until march 14th → 10% (DAP minimum)</td>
</tr>
<tr>
<td>Rewards</td>
<td>Auto-compound (staked)</td>
</tr>
<tr>
<td>Proxy</td>
<td>Non-transfer proxy for operations — stash stays cold on Ledger</td>
</tr>
</tbody>
</table>
</div><h2><a name="p-38237-what-i-commit-to-5" class="anchor" href="#p-38237-what-i-commit-to-5" aria-label="Heading link"></a>What I commit to</h2>
<ul>
<li>
OpenGov participation: vote on referendum and publish reasoning.
</li>
<li>
Commission stability: 10% (DAP minimum). 7 days public notice before any change. Currently at 0% until March 14th
</li>
<li>
Transparent incidents: if something breaks, I’ll post about it here, on Twitter, and on Element. No silent downtimes.
</li>
</ul>
<h2><a name="p-38237-what-are-my-plans-for-the-future-6" class="anchor" href="#p-38237-what-are-my-plans-for-the-future-6" aria-label="Heading link"></a>What are my plans for the future?</h2>
If I make it to the active set, the goal is to expand to new locations in new metros – always the same idea: more decentralized, more resilient.
<h2><a name="p-38237-what-im-honest-about-7" class="anchor" href="#p-38237-what-im-honest-about-7" aria-label="Heading link"></a>What I’m honest about</h2>
This is a single dedicated server. If the hardware fails, there’s downtime until OVH replaces the component – typically a few hours. I have auto-restart for software issues, 24/7 monitoring with alerts, and RAID 1 for disk redundancy. But I’m not going to claim five nines.
That said – independent validators on diverse providers and diverse geographies are exactly what prevents correlated failures across the network. That’s the tradeoff, and it’s the right one.
<h2><a name="p-38237-links-8" class="anchor" href="#p-38237-links-8" aria-label="Heading link"></a>Links</h2>
<ul>
<li>
Website: <a href="https://tech-dc.fr" rel="noopener nofollow ugc">tech-dc.fr</a> — live metrics, full specs, status endpoint
</li>
<li>
Subscan: <a href="https://assethub-polkadot.subscan.io/account/16Pb7ykJ1X1gB8HtsH7JqX5E6brjMqAqxhWEHRByGwhuv9nu" rel="noopener nofollow ugc">Validator page</a>
</li>
<li>
Twitter/X: @madrafrec
</li>
<li>
Element/Matrix: @madrafrec:matrix.org
</li>
</ul>
Happy to answer any questions. Technical deep-dives welcome.
– Madrafrec

<h1><a name="p-38226-looking-for-an-ink-successor-on-polkadot-introducing-wrevive-1" class="anchor" href="#p-38226-looking-for-an-ink-successor-on-polkadot-introducing-wrevive-1" aria-label="Heading link"></a>Looking for an ink! Successor on Polkadot? Introducing <code>wrevive</code></h1>
Over the last months it has become increasingly clear that ink! is effectively unmaintained. 
For teams who have invested in ink! and for new developers entering the Polkadot ecosystem, this creates a painful gap: there is no simple, actively-maintained, ink!-style smart contract SDK that feels familiar and is pleasant to use.
We (a small community team) ended up in the same situation. 
Instead of giving up on the ink! developer experience, we decided to build a lightweight, pragmatic replacement on top of PolkaVM:
<img src="https://emoji.discourse-cdn.com/twitter/backhand_index_pointing_right.png?v=15" title=":backhand_index_pointing_right:" class="emoji" alt=":backhand_index_pointing_right:" loading="lazy" width="20" height="20"> <code>wrevive</code> — a Rust contract toolkit for <code>pallet-revive</code> (PolkaVM) 
GitHub: <a href="https://github.com/wetee-dao/wrevive" rel="noopener nofollow ugc">https://github.com/wetee-dao/wrevive</a>
Our goal is not to reinvent everything. Our goal is to provide:
<ul>
<li>A familiar experience for ink! developers</li>
<li>A minimal, easy-to-read codebase that welcomes contributors</li>
<li>A clean path forward for Polkadot contracts on PolkaVM</li>
</ul>
We are looking for early users, reviewers, and maintainers from the Polkadot community.
<hr>
<h2><a name="p-38226-what-is-wrevive-2" class="anchor" href="#p-38226-what-is-wrevive-2" aria-label="Heading link"></a>What is <code>wrevive</code>?</h2>
<code>wrevive</code> is a Cargo workspace that currently includes:
<ul>
<li><code>wrevive-api</code> – contract runtime API with a unified <code>Env</code> (on-chain/off-chain) plus:
<ul>
<li><code>Storage</code>, <code>Mapping</code>, <code>List</code>, <code>List2D</code></li>
</ul>
</li>
<li><code>wrevive-macro</code> – ink!-style proc macros:
<ul>
<li><code>#[revive_contract]</code></li>
<li><code>#[revive(constructor)]</code> / <code>#[revive(message)]</code></li>
<li>Generates <code>deploy()</code> / <code>call()</code> dispatch and ABI</li>
</ul>
</li>
<li><code>cargo-wrevive</code> – <code>cargo wrevive build</code> subcommand
<ul>
<li>Builds PolkaVM <code>.polkavm</code> artifacts</li>
<li>Emits ABI JSON (including ink!-style ABI)</li>
</ul>
</li>
<li><code>examples</code>
<ul>
<li><code>wrevive-contract</code>: a SCALE-codec example contract using <code>wrevive-api</code> + <code>wrevive-macro</code> (recommended starting point)</li>
</ul>
</li>
</ul>
Repo: <a href="https://github.com/wetee-dao/wrevive" rel="noopener nofollow ugc">wrevive on GitHub</a>
Workspace layout:
<pre><code class="lang-auto">wrevive/
├── Cargo.toml
├── crates/
│ ├── wrevive-api/
│ ├── wrevive-macro/
│ └── cargo-wrevive/
├── examples/
│ └── wrevive-contract/
├── COVERAGE.md
└── README.md
</code></pre>
<hr>
<h2><a name="p-38226-design-philosophy-3" class="anchor" href="#p-38226-design-philosophy-3" aria-label="Heading link"></a>Design Philosophy</h2>
We built <code>wrevive</code> with a few strict principles:
<ul>
<li>Extreme simplicity &amp; lightness
<ul>
<li>Small, focused codebase</li>
<li>Minimal “magic” so contributors can understand the whole stack</li>
</ul>
</li>
<li>Familiarity for ink! users
<ul>
<li>ink!-style macros, entrypoints, and call conventions</li>
<li>ink!-style ABI output for tool compatibility</li>
</ul>
</li>
<li>Leverage existing work
<ul>
<li>We carefully studied ink! and PolkaVM code and re-applied the good ideas</li>
<li>We intentionally avoid over-engineering or building a huge framework</li>
</ul>
</li>
<li>Developer experience first
<ul>
<li>This is essentially a DX layer on top of <code>cargo-pvm-contract</code></li>
<li>We keep close to the existing PolkaVM toolchain, but smoother to use</li>
</ul>
</li>
</ul>
In other words: as close as possible to ink!, but on a modern, maintainable, minimal foundation.
<hr>
<h2><a name="p-38226-developer-experience-writing-contracts-4" class="anchor" href="#p-38226-developer-experience-writing-contracts-4" aria-label="Heading link"></a>Developer Experience: Writing Contracts</h2>
The recommended way to write contracts is to use <code>wrevive-api</code> + <code>wrevive-macro</code>.
From the example in <code>examples/wrevive-contract/src/contract.rs</code>:
<ul>
<li>Entrypoints: put <code>#[revive_contract]</code> on <code>mod contract { ... }</code></li>
<li>Constructor: <code>#[revive(constructor)] pub fn deploy(...) -&gt; ...</code></li>
<li>Messages: <code>#[revive(message)] pub fn foo(...) -&gt; ...</code></li>
</ul>
Storage helpers:
<ul>
<li><code>storage!(b"...")</code> → <code>Storage&lt;T&gt;</code></li>
<li><code>mapping!(b"...")</code> → <code>Mapping&lt;K, V&gt;</code></li>
<li><code>list!(b"...")</code> → <code>List&lt;Idx, V&gt;</code></li>
<li><code>list_2d!(b"...")</code> → <code>List2D&lt;K1, Idx, V&gt;</code></li>
</ul>
Prefixes for these storage items are derived from Blake2s256 (first 4 bytes), and <code>#[revive_contract]</code> will check for duplicate prefixes at compile time.
<h3><a name="p-38226-common-types-5" class="anchor" href="#p-38226-common-types-5" aria-label="Heading link"></a>Common types</h3>
<code>wrevive-api</code> offers a set of SCALE-friendly types that you can use directly in storage and messages:
<ul>
<li><code>Address</code> – 20-byte address (EVM/account compatible)</li>
<li><code>H256</code> – 32-byte hash</li>
<li><code>U256</code> – 256-bit unsigned integer (big-endian, EVM compatible)</li>
<li><code>BlockNumber</code> – <code>u32</code></li>
<li><code>Bytes</code> – alias for <code>Vec&lt;u8&gt;</code></li>
</ul>
Examples: <code>Storage&lt;Address&gt;</code>, <code>Mapping&lt;Address, U256&gt;</code>, <code>Mapping&lt;H256, Bytes&gt;</code>.
<code>Address</code> and <code>H256</code> can be converted to / from <code>[u8; 20]</code> / <code>[u8; 32]</code> via <code>From</code>/<code>Into</code> implementations, which is convenient when interfacing with other tooling.
<hr>
<h2><a name="p-38226-call-convention-ink-style-6" class="anchor" href="#p-38226-call-convention-ink-style-6" aria-label="Heading link"></a>Call Convention (ink!-style)</h2>
The generated <code>call()</code> method follows an ink!-compatible call convention:
<ol>
<li>Read the first 4 bytes of call data as selector (<code>u32::from_be_bytes</code>).</li>
<li>Decode <code>call_data[4..]</code> as SCALE-encoded arguments, in order.</li>
</ol>
So the payload layout is:
<ul>
<li><code>payload = selector (4 bytes) ++ SCALE(args...)</code></li>
</ul>
Selector rules:
<ul>
<li>With <code>#[revive(message, selector = 0x...)]</code>: 
use the provided 4-byte selector.</li>
<li>Otherwise: use the first 4 bytes of BLAKE2s256(function_name) (ink!-compatible behavior).</li>
</ul>
This makes it much easier to integrate <code>wrevive</code> contracts with existing ink!-oriented tooling and workflows.
<hr>
<h2><a name="p-38226-quick-start-7" class="anchor" href="#p-38226-quick-start-7" aria-label="Heading link"></a>Quick Start</h2>
Prerequisites
<ul>
<li>Rust toolchain (nightly recommended)
<ul>
<li><code>cargo wrevive build</code> may rely on unstable <code>-Z ...</code> flags</li>
<li>If you must use stable, you might need <code>RUSTC_BOOTSTRAP=1</code> (not recommended for production)</li>
</ul>
</li>
<li><code>rust-src</code> component (for build-std / cross builds):</li>
</ul>
<pre data-code-wrap="bash"><code class="lang-bash">rustup component add rust-src
</code></pre>
Install <code>cargo wrevive</code>
From the repo root:
<pre data-code-wrap="bash"><code class="lang-bash">cargo install --path crates/cargo-wrevive
</code></pre>
Build the example contract (.polkavm + ABI)
<pre data-code-wrap="bash"><code class="lang-bash">cargo wrevive build -p wrevive-contract
</code></pre>
This produces (under the workspace <code>target/</code> directory):
<ul>
<li>PolkaVM bytecode: <code>target/&lt;bin&gt;.release.polkavm</code></li>
<li>ABI (JSON): <code>target/&lt;bin&gt;.release.abi.json</code> (emitted by <code>cargo-wrevive</code>)</li>
<li>ABI (ink!-style): <code>target/contract/&lt;contract_name&gt;.json</code> (emitted at compile time by <code>#[revive_contract]</code>)</li>
</ul>
Filenames depend on the bin name and contract name resolution—check <code>target/</code> after building.
<hr>
<h2><a name="p-38226-status-work-in-progress-not-production-ready-yet-8" class="anchor" href="#p-38226-status-work-in-progress-not-production-ready-yet-8" aria-label="Heading link"></a>Status: Work in Progress (Not Production-Ready… Yet)</h2>
We want to be very clear:
<blockquote>
Status: Work in progress. Not production-ready. 
APIs, ABIs, and behaviors may change without notice. Use at your own risk.
</blockquote>
That said, this is exactly the phase where community feedback and contributions matter most:
<ul>
<li>We can still change APIs relatively freely</li>
<li>We can still simplify and improve the design</li>
<li>We can still align with the expectations of ink! and Polkadot developers before ossifying anything</li>
</ul>
<hr>
<h2><a name="p-38226-why-were-posting-this-here-9" class="anchor" href="#p-38226-why-were-posting-this-here-9" aria-label="Heading link"></a>Why We’re Posting This Here</h2>
Because ink! is no longer actively maintained, the Polkadot ecosystem risks:
<ul>
<li>Fragmentation across multiple small contract frameworks</li>
<li>Loss of the familiar ink!-style developer experience</li>
<li>Higher barrier to entry for new Rust developers</li>
</ul>
<code>wrevive</code> is our attempt to offer a realistic path forward:
<ul>
<li>Stay close to ink!'s mental model and tooling</li>
<li>Build on PolkaVM and <code>pallet-revive</code></li>
<li>Keep the implementation extremely simple and transparent, so more people can read, audit, and contribute</li>
</ul>
We are not a big company or a foundation project. We are just builders who need this tooling to exist—and we suspect many of you do too.
<hr>
<h2><a name="p-38226-how-you-can-help-10" class="anchor" href="#p-38226-how-you-can-help-10" aria-label="Heading link"></a>How You Can Help</h2>
If any of this resonates with you, there are several ways to get involved:
<ul>
<li>Kick the tires
<ul>
<li>Clone the repo, build the example contract, and try writing a small contract:</li>
<li><a href="https://github.com/wetee-dao/wrevive" rel="noopener nofollow ugc">https://github.com/wetee-dao/wrevive</a></li>
</ul>
</li>
<li>Review the design
<ul>
<li>Look at <code>wrevive-api</code>, <code>wrevive-macro</code>, and <code>cargo-wrevive</code></li>
<li>Open issues for API ergonomics, missing features, or edge cases</li>
</ul>
</li>
<li>Contribute code
<ul>
<li>Help us:
<ul>
<li>Improve documentation and examples</li>
<li>Stabilize the ABI / call conventions</li>
<li>Polish the macros and DX</li>
</ul>
</li>
</ul>
</li>
<li>Integrate with tools
<ul>
<li>If you maintain wallets, UIs, dev tools, or infra:
<ul>
<li>Check if our ink!-style ABI and call conventions are enough</li>
<li>Tell us what’s missing for smooth integration</li>
</ul>
</li>
</ul>
</li>
</ul>
We are especially interested in feedback from:
<ul>
<li>Teams currently using ink! in production or testnets</li>
<li>Tooling authors who want to keep supporting an ink!-like ecosystem</li>
<li>Runtime / node developers who care about <code>pallet-revive</code> / PolkaVM</li>
</ul>
<hr>
<h2><a name="p-38226-call-to-the-polkadot-community-11" class="anchor" href="#p-38226-call-to-the-polkadot-community-11" aria-label="Heading link"></a>Call to the Polkadot Community</h2>
If you believe that Rust-based smart contracts and ink!-style DX are still important for Polkadot, we would love your input and help.
<ul>
<li>Repo: <a href="https://github.com/wetee-dao/wrevive" rel="noopener nofollow ugc">https://github.com/wetee-dao/wrevive</a></li>
<li>Example contract: <code>examples/wrevive-contract</code></li>
<li>Issues &amp; discussions: please open them on GitHub</li>
</ul>
Let’s work together to keep the ink! spirit alive—with a simpler, more maintainable, community-driven successor on PolkaVM.

Ink! Is Stalling – Let’s Revive Polkadot Smart Contracts with wrevive

Nice. Glad it might help someone. I have some spare time to work for the ecosystem, so if you or anyone finds some feaures, bugs, or improvements, let me know happy to help and work on them.

Cedric | ajuna.io

Just an other explorer / indexer

Hey everyone, Kanasjnr here again.
After the really positive response on my <a href="https://forum.polkadot.network/t/can-sassafras-make-polkadot-faster-and-safer/16980">first post</a> (and the super helpful insights from <a href="https://forum.polkadot.network/u/elizabeth-crites">@elizabeth-crites</a>, <a href="https://forum.polkadot.network/u/danicuki">@danicuki</a>, and others), I wanted to go deeper into the practical details.
This post builds directly on the first, but I’ve slowed down the explanations, added more analogies, included concrete examples and even a new section diving into ticket mechanics and Ring VRF internals (since it was mentioned in comments).
<hr>
Everything here is based on:
<ul>
<li>The Web3 Foundation three-part blog series (SSLE details in Part 2, comparisons in Part 3)</li>
<li>The full Sassafras research paper (security proofs, Ring VRF usage)</li>
<li>The JAM Grey Paper, especially §6 on Safrole block production (with equations 6.1–6.12 for state transitions)</li>
<li>Logical extrapolation of how this will feel in actual validator operation</li>
</ul>
If I’ve got anything wrong, feel free to point it out this is based on my research and careful reading, not official docs.
<hr>
<h2><a name="p-38219-inside-sassafras-ticket-mechanics-ring-vrfs-and-deterministic-slot-assignment-1" class="anchor" href="#p-38219-inside-sassafras-ticket-mechanics-ring-vrfs-and-deterministic-slot-assignment-1" aria-label="Heading link"></a>Inside Sassafras: Ticket Mechanics, Ring VRFs, and Deterministic Slot Assignment</h2>
“How does it really work?” Let’s tackle that head-on.
This is protocol-level exposition on ticket generation and why Ring VRFs are essential. I’ve kept steps and math from the papers for reference.
<hr>
<h3><a name="p-38219-from-per-slot-lottery-to-epoch-wide-sampling-2" class="anchor" href="#p-38219-from-per-slot-lottery-to-epoch-wide-sampling-2" aria-label="Heading link"></a>From Per-Slot Lottery to Epoch-Wide Sampling</h3>
Today (BABE): Each slot is independent. Validators compute:
<pre data-code-wrap="python"><code class="lang-python">VRF_sk(epoch_randomness || slot_number)
</code></pre>
If the output &lt; threshold, you’re eligible.
Independence creates Poisson variance:
<ul>
<li>Probability of an empty slot: (P(empty) = \prod(1 - p_i))</li>
<li>Probability of multiple winners: &gt;0 → forks and empty slots</li>
</ul>
Sassafras: Tickets are sampled once per epoch and leadership is precomputed.
There’s no per-slot randomness during executiononly at epoch boundaries.
<hr>
<h3><a name="p-38219-epoch-randomness-as-anti-grinding-anchor-3" class="anchor" href="#p-38219-epoch-randomness-as-anti-grinding-anchor-3" aria-label="Heading link"></a>Epoch Randomness as Anti-Grinding Anchor</h3>
Let:
<ul>
<li>(R_e) = finalized randomness from epoch (e-1) (from the beacon, bound to chain—prevents retroactive influence)</li>
<li>(V) = set of active validators</li>
</ul>
At the start of epoch (e), validator (i) computes multiple ticket candidates to ensure enough winners:
<pre data-code-wrap="python"><code class="lang-python">ticket_j = Ring_VRF_sk_i(R_e || j) # j = counter for multiplicity
</code></pre>
Multiplicity (e.g., ≥6 for 100 elections, per paper) tunes expected winners ≈ slots.
<hr>
<h3><a name="p-38219-ticket-structure-4" class="anchor" href="#p-38219-ticket-structure-4" aria-label="Heading link"></a>Ticket Structure</h3>
<pre data-code-wrap="python"><code class="lang-python">ticket = (y, π, commitment)
</code></pre>
Where:
<ul>
<li>y = pseudorandom scalar (sortable; lower y = higher priority)</li>
<li>π = ring proof (verifies y came from some sk in V, without revealing which)</li>
<li>Commitment ensures later claimable only by owner</li>
</ul>
<hr>
<h3><a name="p-38219-deterministic-ordering-5" class="anchor" href="#p-38219-deterministic-ordering-5" aria-label="Heading link"></a>Deterministic Ordering</h3>
All valid tickets (T) are collected and sorted ascending by y.
The top N (N = slots) become the leader schedule:
<pre data-code-wrap="python"><code class="lang-python">slot_k ← k-th smallest ticket
</code></pre>
This guarantees one primary per slot, with a deterministic epoch-wide order, provided (T) is known.
<hr>
<h3><a name="p-38219-why-ring-vrfs-mechanics-breakdown-6" class="anchor" href="#p-38219-why-ring-vrfs-mechanics-breakdown-6" aria-label="Heading link"></a>Why Ring VRFs? (Mechanics Breakdown)</h3>
A normal VRF reveals the signer via pk.
Ring VRFs hide the signer within a ring (R = {pk_1, …, pk_n}).
Setup: Global parameters from SRS. The ring uses Bandersnatch curve for speed.
Evaluation by validator i: Input (x = R_e || j), compute (y = VRF_sk_i(x)), produce (\pi) proving “y correct for some sk matching pk in R.” Proof size is constant/log in n.
Verification: Check (\pi) against (R, x, y). Accept if valid from some member, but without knowing which.
In Sassafras: Early for anonymous tickets. Later, normal VRF reveals identity in the claim phase.
<ul>
<li>Anonymity window protects leader privacy just long enough for execution.</li>
<li>“Relaxed” because it’s not permanent, but sufficient (&gt;2/3 honest = progress).</li>
</ul>
Grinding attempts are blocked since (R_e) is bound to the chain.
Variance now comes from validator reliability, not protocol randomness.
This structural shift defines Sassafras: randomness in selection, determinism in execution.
<hr>
<h2><a name="p-38219-h-1-deterministic-vs-probabilistic-production-from-lottery-chaos-to-hidden-schedule-7" class="anchor" href="#p-38219-h-1-deterministic-vs-probabilistic-production-from-lottery-chaos-to-hidden-schedule-7" aria-label="Heading link"></a>1. Deterministic vs Probabilistic Production: From Lottery Chaos to Hidden Schedule</h2>
<h3><a name="p-38219-step-by-step-explanation-of-the-change-8" class="anchor" href="#p-38219-step-by-step-explanation-of-the-change-8" aria-label="Heading link"></a>Step-by-step explanation of the change</h3>
Today (BABE):
<ul>
<li>Every 6-second slot is an independent lottery.</li>
<li>Each validator computes a VRF output → if it’s below a threshold (determined by stake weight), you’re a winner for that slot.</li>
<li>Because it’s random, the number of winners per slot follows a Poisson distribution (λ ≈ 1):
<ul>
<li>Sometimes 0 winners → empty slot → chain pauses for 6 seconds (or more if unlucky streaks happen)</li>
<li>Sometimes 2+ winners → multiple blocks proposed → fork → network resolves via longest-chain rule</li>
</ul>
</li>
<li>Result: Block times are variable (exponential distribution around 6 s), throughput is inconsistent, latency jitter is high.</li>
</ul>
With Sassafras/Safrole:
<ul>
<li>Once per epoch (~4 hours = 2400 slots), the entire set of leaders is elected in batch.</li>
<li>Validators generate tickets using ring VRFs → tickets are anonymously published → sorted on-chain → sorted list becomes the secret leader schedule for the epoch.</li>
<li>Each slot gets exactly one assigned leader (unless attacked → skipped).</li>
<li>Identity is hidden until leader claims the slot (revealing the ring VRF proof).</li>
<li>Result: Block times very close to exactly 6 seconds under normal conditions.</li>
</ul>
<hr>
<h3><a name="p-38219-real-world-analogies-9" class="anchor" href="#p-38219-real-world-analogies-9" aria-label="Heading link"></a>Real-world analogies</h3>
<ul>
<li>BABE: Public lottery every 6 seconds. Sometimes nobody wins → shop closed. Sometimes 3 people win → fight over who gets served first.</li>
<li>Sassafras: Secret pre-booked appointment calendar for the next 4 hours. Everyone knows exactly one appointment per slot, but nobody knows who has which slot (except the current leader when it’s time).</li>
</ul>
<hr>
<h3><a name="p-38219-what-this-means-for-throughput-and-user-experience-10" class="anchor" href="#p-38219-what-this-means-for-throughput-and-user-experience-10" aria-label="Heading link"></a>What this means for throughput and user experience</h3>
<ul>
<li>Fewer empty slots → chain grows more steadily → effective TPS increases even if peak TPS stays similar.</li>
<li>Lower latency variance → dApps (DeFi, gaming, oracles) get predictable confirmation times.</li>
<li>Fewer forks → less time wasted on fork choice → GRANDPA finality reaches depth faster.</li>
</ul>
Quick math reminder (from Part 1):
<ul>
<li>Honest block probability ≥ 4/9 ≈ 44.4%</li>
<li>Adversarial ≤ 1/3 ≈ 33.3%</li>
</ul>
Even if 1/3 of leaders are attacked/skipped, honest blocks dominate → chain grows reliably.
Bottom line for validators:
You go from “pray my VRF wins this slot” → “I have a small number of known turns; I need to be online and ready exactly then”.
Workload more predictable, punctuality more important.
<hr>
<h2><a name="p-38219-h-2-validator-operational-impact-what-actually-changes-on-your-server-11" class="anchor" href="#p-38219-h-2-validator-operational-impact-what-actually-changes-on-your-server-11" aria-label="Heading link"></a>2. Validator Operational Impact: What Actually Changes on Your Server?</h2>
<h3><a name="p-38219-hardware-software-requirements-12" class="anchor" href="#p-38219-hardware-software-requirements-12" aria-label="Heading link"></a>Hardware &amp; software requirements</h3>
<ul>
<li>Almost no change required.</li>
<li>CPU (VRFs), RAM, fast SSD (state trie), good network still needed.</li>
<li>Ring VRF uses Bandersnatch curve (Substrate supports via bandersnatch_vrf crate).</li>
<li>Batch ticket generation once per epoch → CPU usage is bursty, not constant.</li>
<li>More multicast traffic during Phase B → slight bandwidth increase at epoch transitions.</li>
</ul>
<hr>
<h3><a name="p-38219-network-latency-dos-sensitivity-13" class="anchor" href="#p-38219-network-latency-dos-sensitivity-13" aria-label="Heading link"></a>Network latency &amp; DoS sensitivity</h3>
<ul>
<li>Today (BABE): Timing races matter missing your slot is costly.</li>
<li>Sassafras: Timing is fixed → 6 seconds to produce once it’s your turn.
<ul>
<li>Marginally slower? Less catastrophic.</li>
<li>Identity leaks → DoS target for that slot.</li>
</ul>
</li>
</ul>
<hr>
<h3><a name="p-38219-uptime-maintenance-14" class="anchor" href="#p-38219-uptime-maintenance-14" aria-label="Heading link"></a>Uptime &amp; maintenance</h3>
<ul>
<li>Today: Missing a slot is annoying but recoverable.</li>
<li>Sassafras: Missing pre-assigned slot → empty block → hurts chain liveness &amp; rewards.</li>
</ul>
Positive: Can plan maintenance outside assigned slots.
Negative: No more “quiet period” for restarts.
<hr>
<h3><a name="p-38219-reward-consistency-15" class="anchor" href="#p-38219-reward-consistency-15" aria-label="Heading link"></a>Reward consistency</h3>
<ul>
<li>Today: Highly variable. Some epochs produce many blocks; others almost none.</li>
<li>Sassafras: Smoother, proportional to stake across epoch (minus skips/attacks).</li>
</ul>
Smaller nominators benefit from predictable weekly earnings.
<hr>
<h2><a name="p-38219-h-3-liveness-under-stress-what-happens-when-things-break-16" class="anchor" href="#p-38219-h-3-liveness-under-stress-what-happens-when-things-break-16" aria-label="Heading link"></a>3. Liveness Under Stress: What Happens When Things Break?</h2>
<h3><a name="p-38219-normal-case-13-offline-17" class="anchor" href="#p-38219-normal-case-13-offline-17" aria-label="Heading link"></a>Normal case (&lt;1/3 offline)</h3>
<ul>
<li>Chain produces almost exactly one block every 6 seconds.</li>
</ul>
<h3><a name="p-38219-partial-offline-2025-down-18" class="anchor" href="#p-38219-partial-offline-2025-down-18" aria-label="Heading link"></a>Partial offline (~20–25% down)</h3>
<ul>
<li>Sorted ticket list acts as backup queue.</li>
<li>Leader offline/attacked → skip → next honest leader produces block.</li>
<li>JAM Grey Paper fallback: if ticket gen fails → direct Bandersnatch key series (round-robin). Rare mode.</li>
</ul>
<h3><a name="p-38219-network-partition-19" class="anchor" href="#p-38219-network-partition-19" aria-label="Heading link"></a>Network partition</h3>
<ul>
<li>Two partitions may temporarily fork.</li>
<li>When reconnected → GRANDPA chooses chain with most honest weight.</li>
<li>Fixed slots → partitions more visible, but resolution same.</li>
</ul>
<h3><a name="p-38219-targeted-dos-attacks-20" class="anchor" href="#p-38219-targeted-dos-attacks-20" aria-label="Heading link"></a>Targeted DoS attacks</h3>
<ul>
<li>Malicious repeaters leak identities (≤ f ≈ 1/3).</li>
<li>Adversary DoS-es leaked validators → those slots empty.</li>
<li>Honest block probability ≥ 4/9 &gt; adversarial ≤ 1/3 → chain grows.</li>
</ul>
Analogy: Queue of 10 people. First 3 blocked → 4th speaks. As long as majority free → conversation continues.
<hr>
<h2><a name="p-38219-h-4-how-it-fits-into-polkadot-20-jam-21" class="anchor" href="#p-38219-h-4-how-it-fits-into-polkadot-20-jam-21" aria-label="Heading link"></a>4. How it Fits into Polkadot 2.0 &amp; JAM</h2>
Sassafras/Safrole = foundational infrastructure for Polkadot 2.0.
<h3><a name="p-38219-elastic-scaling-agile-coretime-22" class="anchor" href="#p-38219-elastic-scaling-agile-coretime-22" aria-label="Heading link"></a>Elastic Scaling &amp; Agile Coretime</h3>
<ul>
<li>Polkadot 2.0 removes parachain slot auctions → parachains buy “coretime” on-demand or in bulk.</li>
<li>Sassafras → predictable relay chain blocks → multiple parablocks reliably submitted.</li>
<li>Stable 6s rhythm → coretime buyers get consistent execution guarantees.</li>
</ul>
<hr>
<h3><a name="p-38219-jam-architecture-23" class="anchor" href="#p-38219-jam-architecture-23" aria-label="Heading link"></a>JAM Architecture</h3>
<ul>
<li>Safrole is the block production engine.</li>
<li>Generates high-quality entropy η (from VRFs) → used by JAM components.</li>
<li>Maintains validator sets ι (pending), κ (active), γ_P (next epoch keys).</li>
<li>Uses Bandersnatch ring VRF → sealing keys pseudonymous.</li>
</ul>
Summary: Sassafras/Safrole = heartbeat for JAM/P2.0.
<hr>
<h2><a name="p-38219-final-thoughts-24" class="anchor" href="#p-38219-final-thoughts-24" aria-label="Heading link"></a>Final Thoughts</h2>
Sassafras moves Polkadot from “random, bursty, sometimes stalled” → “hidden, scheduled, steady, skip-tolerant” production.
For validators:
<ul>
<li>More predictable workload</li>
<li>Smoother rewards</li>
<li>Higher uptime &amp; DDoS importance</li>
<li>Less variance → better planning</li>
</ul>
For the network:
<ul>
<li>Higher effective throughput</li>
<li>Lower latency jitter</li>
<li>Stronger foundation for Polkadot 2.0 / JAM scaling</li>
</ul>
What do you think?
See you in Part 3 <img src="https://emoji.discourse-cdn.com/twitter/man_shrugging.png?v=15" title=":man_shrugging:" class="emoji" alt=":man_shrugging:" loading="lazy" width="20" height="20"> (maybe MEV implications or staking economics under Sassafras?).

Nasihudeen Adegboyega Jimoh

Can Sassafras make Polkadot faster and safer?(Part 2)

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

Encointer Retroactive Treasury Proposal for July-Dec 2025

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

Deciding

Runtime Upgrade 2.1.0

- Bloque is a tool that helps apps use stablecoins (digital money) easily.
- They have a live dashboard where you can see real-time spending.
- They are asking for $72,000 to pay their 4-person team for 6 months.
- They have processed over $380,000 in payments for customers.
- Their goal is to make their system work with local currencies like Colombian Pesos.
- They want to launch a new debit card and make their system very reliable.
- The founder is working very hard and needs help to keep growing.

V3 - Stage 3: Support the ONLY revenue generating project in Kusama for the cost of one engineer per year. 72K USD.

- Encointer is asking for funding to continue its work for the second half of 2025.
- They want 73,811 Swiss Francs (about 93,821 US Dollars).
- They created a stablecoin system that lets communities swap it for USDC.
- They made a documentary and got featured in an article about their work in Africa.
- Their app now has a "Bazaar" feature to help local businesses advertise.
- Their communities in Tanzania and Nigeria are still active despite real-world problems.
- They earned about 13,000 Swiss Francs from sources other than their treasury.

Kusama

referenda3

fellowship1

treasury28

discussions1397