candidates

members

proficients

fellows

senior_fellows

experts

senior_experts

masters

senior_masters

grand_masters

Miscellaneous

Performance bottlenecks and connection timeouts in iOS dApp environments

system

Wallet Recommendations

Shaping the Future of OpenGov

Mark

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

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

Lohann Paterno Coutinho Ferreira

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

Aston

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

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.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

Kusama&rsquo;s Cypherpunk Direction: Plan or Aspiration?

Rust Syndicate

Kusama's Cypherpunk Direction: Plan or Aspiration?

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

Ecosystem

Introducing plaza.fun — Meme Infrastructure for Polkadot Hub

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

LoopGhost

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

Helping Nominators Protect Their Stakes

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

Care to give a comparison to Hydration’s Memepad?
<aside class="onebox allowlistedgeneric" data-onebox-src="https://app.hydration.net/memepad">
 <header class="source">
 <img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/7/7ecd7e36bf5cbaff3ebb677bcd7dbbcd69a46e67.png" class="site-icon" alt="" data-dominant-color="EC759D" width="16" height="16">

 <a href="https://app.hydration.net/memepad" target="_blank" rel="noopener nofollow ugc">app.hydration.net</a>
 </header>

 <article class="onebox-body">
 <div class="aspect-image" style="--aspect-ratio:690/360;"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/a/a744f8e56b59605c83807ef657ad5667ca28afde_2_690x360.jpeg" class="thumbnail" alt="" data-dominant-color="97A4AE" width="690" height="360"></div>

<h3><a href="https://app.hydration.net/memepad" target="_blank" rel="noopener nofollow ugc">Hydration - An Ocean of Liquidity</a></h3>

 Hydration is a next-gen DeFi protocol which is designed to bring an ocean of liquidity to Polkadot. Our tool for the job the Hydration - an innovative Automated Market Maker (AMM) which unlocks unparalleled efficiencies by combining all assets in a...


 </article>

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

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

I’d be remiss to say Polkadot has much of a meme culture. Pump.fun clones or ‘ded’icated memecoins have been floated before with little more than lasting regret. Though you’re welcome to do whatever you want (permissionless) you may find difficulty garnering support or funding unless there is a clear outline for success.

Elvis

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

Mn0 B

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.

<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

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

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.

Burnww

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)

I only pushed back against the idea that this improves defi. If ones ships defi like this then almost surely they’d ship some overly general shitty interface that nobody ever uses. I proposed defi schemes that address related concerns but have a less involved deployment.
We do want games that use drand’s timelock IBE to create action delays and information asymmetry. There are several reasons why games make more sense, with one reason being that games do not allow &amp; encourage that half-assed deployment options of a “financial” product.
Now 99% of the work is making the game, while 1% of the work is on-chain decryption, meaning adding an optimistic decryption layer and integrating a drand bridge.
Importantly, we need not anonymize the transaction for a game, meaning we’d change nothing in the real memepool itself, just add the on-chain decryption.
Actually there are zero memepool changes for defi either, or really anything here, but then you’d ideally want some zcash-like anonymity to ensure the tx fees get paid, which itself seems like a major effort.

Jeff Burdges

Tony Riemer

Encrypted Mempools: Turning Polkadot&rsquo;s MEV Leak into Treasury Revenue

Encrypted Mempools: Turning Polkadot's MEV Leak into Treasury Revenue

Hi everyone, I’m building a Web3 layer for a real-world B2B trade workflow and I want a reality check from people who’ve shipped on Polkadot.
The goal is an escrow-style settlement contract (plus supporting off-chain services) where a trade is created off-chain, signed, then executed on-chain with verifiable evidence for each step. We’re targeting Paseo / Asset Hub for testing and we’re trying to align with the PolkaVM toolchain (resolc + Parity Hardhat plugin stack) so compiled artifacts and verification are deterministic.
I’m just trying to learn what’s actually production-realistic and what risks I’m underestimating. If helpful, I can share a diagram and repo link, but I wanted to ask the questions first.
<h3><a name="p-38214-what-were-building-1" class="anchor" href="#p-38214-what-were-building-1" aria-label="Heading link"></a>What we’re building</h3>
<ul>
<li>Escrow settlement contract: milestone-based release, disputes, timeouts, pause and claims-pause controls.</li>
<li>Pull-over-push payouts: instead of sending funds during state transitions, we accrue claimable balances and recipients claim.</li>
<li>Operational verification: CI generates deterministic deploy/compile evidence (bytecode hash, toolchain versions, chainId, addresses, etc.).</li>
<li>Indexer + reconciliation: store events and generate audit-style reports for ops and evidence.</li>
</ul>
<h3><a name="p-38214-where-im-uncertain-and-i-would-like-some-guidance-on-thisquestions-2" class="anchor" href="#p-38214-where-im-uncertain-and-i-would-like-some-guidance-on-thisquestions-2" aria-label="Heading link"></a>Where I’m uncertain and i would like some guidance on this(questions)</h3>
I’d appreciate opinions, best practices, and “don’t do it this way” warnings:
<ol>
<li>PolkaVM toolchain and deploy flow</li>
</ol>
<ul>
<li>With resolc/PolkaVM compilation, what’s the most reliable way to ensure deployment uses the PolkaVM artifacts, not silently recompiled solc artifacts?</li>
<li>If using Hardhat Ignition, is it expected that it triggers recompilation unless the pipeline is configured very specifically?</li>
<li>In real deployments, what is the canonical flow teams use for compile → deploy → verify with evidence in a PolkaVM context?</li>
</ul>
<ol start="2">
<li>Runtime endpoints and Revive</li>
</ol>
<ul>
<li>I see references to revive-enabled endpoints and runtime support differences. What’s the right way to reason about “EVM-like dev deploys” vs actual PolkaVM deploys?</li>
<li>When is it acceptable to test logic on one environment and switch later?</li>
<li>What are common footguns where you compile one way but the runtime behaves differently?</li>
</ul>
<ol start="3">
<li>USDC-like assets on Asset Hub and production realism</li>
</ol>
<ul>
<li>If we want stablecoin settlement eventually, what’s the realistic approach on Asset Hub for asset choice on testnet vs production?</li>
<li>Any gotchas with decimals, metadata assumptions, and wallet compatibility?</li>
<li>Anything you’ve seen go wrong in production where “the asset exists” but tooling assumptions break?</li>
</ul>
<ol start="4">
<li>Verification and evidence (ops side)</li>
</ol>
<ul>
<li>If the goal is “every deployment has reproducible evidence,” what do you consider the minimum credible bundle?</li>
<li>compiler versions, chainId, bytecode hash, ABI hash, tx hash, contract address</li>
<li>anything else you’d include in professional deployments?</li>
<li>Any recommended patterns for source verification or bytecode match checks with PolkaVM artifacts?</li>
</ul>
<ol start="5">
<li>Claim-based settlement and treasury operations</li>
</ol>
<ul>
<li>We moved to a claim model to reduce risk and isolate failures (no push transfers during state transitions).</li>
<li>But treasury claiming becomes operational (keys might be multisig or cold).</li>
<li>Is a destination-locked sweep function (anyone can call, funds always go to treasury) reasonable, or frowned upon?</li>
<li>How do teams typically handle “fees accrue to treasury” without requiring treasury keys in hot paths?</li>
</ul>
<ol start="6">
<li>Governance and emergency controls</li>
</ol>
<ul>
<li>For contracts used in real flows, what pause/unpause patterns do you prefer?</li>
<li>Do you separate protocol pause vs claims pause, or keep it simpler?</li>
<li>What level of governance rigor do you expect before real usage?</li>
</ul>
<ol start="7">
<li>Indexing and long-term maintainability</li>
</ol>
<ul>
<li>If we rely heavily on events for reconciliation/audit proofs, any must-have event design patterns?</li>
<li>Any Polkadot-specific pitfalls for indexing, block finality assumptions, or reorg handling that differ from typical EVM mental models?</li>
</ul>
If anyone has shipped something similar (or adjacent), I’d love pointers: docs, repos, toolchain guidance, or “here’s how we do it” notes.
Also, if you think “this is not realistic on PolkaVM today for real-world usage,” I’d rather hear that early and understand why. For context our <a href="https://github.com/Agroasys/Agroasys.Web3layer" rel="noopener nofollow ugc">REPO</a>
Thanks.

Is PolkaVM + Asset Hub viable for non-custodial USDC escrow settlement?

I take this perspective:
Quantum computers appear unlikely within the next 20 years. It’s not my field but the level of bullshit there, including the numerous startups, suggests no real progress. I could be wrong, we solved blockchain scaling but the level of bullshit in the blockchain world did not decrease. <img src="https://emoji.discourse-cdn.com/twitter/wink.png?v=15" title=":wink:" class="emoji" alt=":wink:" loading="lazy" width="20" height="20">
There is no real economic gain from quantum computers, so not much reason for moon shot efforts. Yes, you could break the elliptic curve cryptography, but that’s useless once TLS and the messangers adopt post-quantum KEMs. Any “real” applications for quantum computers require much larger ones, so not realistic this century.
We do authentication not encryption. If you do encryption then you want to be 30 years ahead of the quantum computers. If you do authentication then you just need to be far enough ahead to rotate the key.
For us, post-quantum has one real advantage this decade:
We can handle more data than other blockchains, so post-quantum would let us “throw down the gauntlet” and push them into becoming even slower, while giving us good PR. Imagine if our adopting post-quantum helped push BTC to adopt post-quantum, and this dropped them from 4 tps to 1 tps, and this plus their <a href="https://finance.yahoo.com/news/bitcoin-won-over-wall-street-124511013.html" rel="noopener nofollow ugc">ETFs</a> <a href="https://www.marketwatch.com/story/bitcoin-etfs-are-hemorrhaging-billions-heres-what-investors-awaiting-a-crypto-turnaround-should-watch-for-33d31eed?st=eeRHxS&amp;reflink=desktopwebshare_permalink" rel="noopener nofollow ugc">killing</a> them cause another alt season.
Although possible, that’s all kinda fantasy. It’s likely better to ship some really successful game.
As a fun aside, I’ve ignored DJB’s rants about the NSA backdooring the NIST post-quantum effort, way too long winded, but <a href="https://eprint.iacr.org/2025/1577" rel="noopener nofollow ugc">IACR 2025/1577</a> says something interesting: “One of the drawbacks of the ongoing side channel analysis research related to PQC schemes is the availability of open-source datasets. Luckily some open-source datasets start popping up.” There are different skills involved in improving power analysis side-channel attack, extracting the power traces requires one, while exploring the applied mathematics requires another. To me, this quote says we’ve never done the serious side-channel work against post-quantum primitives. It’s fine if we use hybrid PQ+ECC, but <a href="https://web.archive.org/web/20260218044903/https://mailarchive.ietf.org/arch/msg/tls/-Te4ZxhhFiQ9CwPaLnAta63mCn0/" rel="noopener nofollow ugc">NIST wants to standardize non-hybrid PQ KEMs</a> and the NSA wants this too. Imho that’s suspicious and should wait several years for more side-channel work.

Post Quantum Cryptography Roadmap for Polkadot and JAM

Hi everyone, 
I’ve been working on a proof-of-concept for a mobile-first dApp on Polkadot, but I’ve hit a significant roadblock with the <a class="mention" href="/u/polkadot">@polkadot</a>/api initialization on iOS. While the desktop browser extension (Talisman/Polkadot.js) works flawlessly, my mobile integration keeps hanging during the “Initializing API” phase, especially when trying to handle custom extrinsic signers in a background thread.
I actually started looking into how other mobile-optimized script environments handle high-frequency execution without triggering iOS’s native memory protection. I found some interesting discussion points <a href="https://deltaexector.com/ios/" rel="noopener nofollow ugc">from deltaexector com</a> regarding how they manage script injection on mobile, and it made me wonder if the Polkadot light client (smoldot) might be clashing with similar browser-level security restrictions on iPhones. You can see the specific iOS implementation I’m comparing it to at deltaexector com, as I’m trying to figure out if their method of sandboxing JS could be adapted to make our wallet connections more stable.
I’m also running into a related issue where the window.injectedWeb3 object isn’t being detected by the dApp when opened through a mobile browser wrapper, even if the wallet app is running in the background. Has anyone else noticed that iOS-specific power-saving modes are throttling the RPC provider heartbeat? I’ve already tried switching to a shorter metadata version (v14/v15) to reduce the bundle size, but the “Initializing Connection” spinner just won’t clear on older iPhone models. Is there a way to force a synchronous provider check, or should I be looking into a different discovery protocol to ensure the script environment remains active during the signing request? Any insights on mobile JS stability for Polkadot would be a huge help!

I’ve been thinking about a way to give Kusama real momentum again.
1- Proposal:
A privacy-focused parachain where KSM remains the only currency. No new token. No inflation. No DeFi. No smart contracts. No grifter shit. Cheap to maintain. 
Just private transfers. 
Think Monero level on-chain privacy — hiding sender, receiver, and amounts — but built as a minimal, dedicated transfer layer for KSM inside the Kusama ecosystem. 
KSM goes in. 
Becomes privately transferable. 
Comes out when needed. 
That’s it. 
A digital cash mode for KSM.
2- Regulatory Proofs:
Users can generate cryptographic proofs to demonstrate the legality of specific transactions. 
Methods include view keys (Monero-style) or zero-knowledge proofs (zk-proofs). 
Only the transactions the user chooses to disclose are revealed; the rest of the account history remains private. 
Some proofs may reveal the counterpart if the regulator needs to know it, but only for the specific transaction.
This development will be carried out exclusively by Parity Technologies and Fellowship, ensuring maximum security, maintainability, and alignment with Kusama’s interests.

Kusama privacy chain

When will you submit the proposal? The longer you wait, the greater the competitive advantage for DOT (and the competitive disadvantage for KSM), because the parameter change for the latter will be implemented in a few weeks.

Proposal discussion: Adapting Kusama to demand and its JAM future

If you’ve spent time building extrinsics on Polkadot, you’ve probably fought with the same things I have. Is this balance in planck or DOT? Is this hex 32 bytes or 64? Did I get the SCALE encoding right? Most tools read the type name from metadata and give you a text field. You figure out the rest.
I built <a href="https://relaycode.org" rel="noopener nofollow ugc">Relaycode</a> to fix this. It’s a dual-pane extrinsic builder: human-readable form on one side, live SCALE-encoded hex on the other. Edit the form, hex updates. Paste encoded call data, the form populates.
<img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/0/0cc52df172beb92bef3b80f5d1eee56731a429d1.gif" alt="bidirectional-editing_beautified" data-base62-sha1="1OYbrZBHvkJwotov42jG68o40F3" width="690" height="459" class="animated">
You can connect your wallet (Polkadot.js, Talisman, SubWallet via <a href="https://lunokit.xyz" rel="noopener nofollow ugc">LunoKit</a>), sign, and submit transactions directly from the builder. Works across Polkadot, Kusama, and Westend right now.
<a href="https://relaycode.org" rel="noopener nofollow ugc">relaycode.org</a> | <a href="https://github.com/itsyogesh/relaycode" rel="noopener nofollow ugc">GitHub</a> | <a href="https://relaycode.org/docs" rel="noopener nofollow ugc">Docs</a>
<h2><a name="p-38182-how-the-inputs-work-1" class="anchor" href="#p-38182-how-the-inputs-work-1" aria-label="Heading link"></a>How the inputs work</h2>
There’s a priority-based component registry under the hood. When the builder encounters a type, it walks the registry top to bottom and the first pattern match wins. So <code>Compact&lt;Balance&gt;</code> gets the Balance component (with denomination switching, planck display, and a Max button) before the generic Amount component catches it. <code>Vec&lt;u8&gt;</code> gets a multi-mode bytes editor (hex, text, JSON, Base64, file upload) instead of the Vector component trying to render individual u8 fields.
<div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/e/ea3fa15d6ea6ab37a2fb1ffc5a4aa0445e0ae067.jpeg" data-download-href="/uploads/short-url/xqg3r7uvFm2SCKT0khJYfEH3qHZ.jpeg?dl=1" title="ray-so-export (3)" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/e/ea3fa15d6ea6ab37a2fb1ffc5a4aa0445e0ae067_2_690x343.jpeg" alt="ray-so-export (3)" data-base62-sha1="xqg3r7uvFm2SCKT0khJYfEH3qHZ" width="690" height="343" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/e/ea3fa15d6ea6ab37a2fb1ffc5a4aa0445e0ae067_2_690x343.jpeg, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/e/ea3fa15d6ea6ab37a2fb1ffc5a4aa0445e0ae067_2_1035x514.jpeg 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/e/ea3fa15d6ea6ab37a2fb1ffc5a4aa0445e0ae067_2_1380x686.jpeg 2x" data-dominant-color="8F78B2"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg>ray-so-export (3)1920×956 106 KB<svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div>
22 input components and 10 contextual selectors. A few I’m particularly happy with:
<code>AccountId</code> becomes a wallet-connected selector with identicons, display names, and balance previews. Handles <code>MultiAddress</code> wrapping automatically.
<img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/2/26f2c6355c2adec5976e6af89c969908036c17d0.gif" alt="account-input_beautified" data-base62-sha1="5yyhGJX8NDh7dQ1hHJpwUVppiww" width="690" height="459" class="animated">
<code>Balance</code> reads the chain’s decimals and symbol. Type “1.5 DOT” and it converts to planck for you.
<img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/d/d6635461dc37e6cff92bb39818f5f24ec409f8b3.gif" alt="balance-input_beautified" data-base62-sha1="uAyZsWMbQgSCKdQ4qZwd3mGk7gT" width="690" height="459" class="animated">
<code>Call</code> is a recursive mini-builder. This is what makes <code>utility.batch</code> actually usable – you build each inner call visually.
<img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/3/3d8a88717e0ff5b440ef7afdd2641099ab6cc022.gif" alt="batch-call-input_beautified" data-base62-sha1="8MpVJH20PpyE9T8OOuctuNCpu94" width="690" height="459" class="animated">
Enum, Struct, Tuple, Option, Vector, BTreeMap all compose recursively. <code>Option&lt;Vec&lt;(AccountId, Balance)&gt;&gt;</code> renders as a toggle wrapping a vector of tuples, each with an account selector and balance input. No special-casing for that combination – the components just delegate inner types back to the registry.
<h2><a name="p-38182-contextual-selectors-2" class="anchor" href="#p-38182-contextual-selectors-2" aria-label="Heading link"></a>Contextual selectors</h2>
Type matching covers about 90% of cases, but some fields need on-chain context. A <code>u32</code> representing a referendum index is more useful as a selector showing active proposals than a plain number field. So there’s a second layer – pallet-level overrides:
<ul>
<li><code>convictionVoting.vote.poll_index</code> shows active referenda with titles and vote tallies (via Polkassembly)</li>
<li><code>staking.nominate.targets</code> shows validators with commission rates and identity (via Subscan)</li>
<li>Pool, Bounty, Asset, Track, and Era selectors work the same way – they query chain state and show what’s actually available</li>
</ul>
<img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/3/3c3eece9f860728dae609324b5163c400bd80a26.gif" alt="referendum-selector_beautified" data-base62-sha1="8AXsQT0LmHoVDopAbJWL99atWbY" width="690" height="459" class="animated">
<h2><a name="p-38182-for-power-users-3" class="anchor" href="#p-38182-for-power-users-3" aria-label="Heading link"></a>For power users</h2>
One of the earliest requests I got was from people who already work with raw encoded call data. They’d have a hex-encoded extrinsic from somewhere – a governance proposal, a multisig call, a batch they built before – and they just wanted to paste it, see what it actually contains, tweak one parameter, and resubmit. That’s exactly what the bi-directional editing does. Paste hex into the right pane, the form populates with decoded values. Change the one field you need, the hex updates, sign and submit.
This side-by-side view with two-way sync turned out to be the thing that makes the builder fast for people who already know what they’re doing.
<h2><a name="p-38182-tech-stack-4" class="anchor" href="#p-38182-tech-stack-4" aria-label="Heading link"></a>Tech Stack</h2>
All the Polkadot integration is through <a href="https://dedot.dev" rel="noopener nofollow ugc">Dedot</a> by for type-safe chain interactions. Wallet connection is built from <a href="https://lunokit.xyz" rel="noopener nofollow ugc">LunoKit</a>. Frontend is Next.js + TypeScript + shadcn/ui. Both milestones of our W3F grant are complete.
<h2><a name="p-38182-what-id-like-feedback-on-5" class="anchor" href="#p-38182-what-id-like-feedback-on-5" aria-label="Heading link"></a>What I’d like feedback on</h2>
The part I care most about is whether the input components feel right. What Substrate types or extrinsic workflows does the current tooling handle badly? What would you want a builder like this to do better?
I wrote a detailed walkthrough of every component here: <a href="https://medium.com/@itsyogesh18/every-substrate-type-deserves-a-better-input-296c7997d229" rel="noopener nofollow ugc">Every Substrate Type Deserves a Better Input</a> and an intro article if you just want the tl;dr <a href="https://medium.com/p/a76b43518b33" rel="noopener nofollow ugc">Building an Extrinsic Builder for Polkadot</a>
Links:
<ul>
<li>Live: <a href="https://relaycode.org" rel="noopener nofollow ugc">relaycode.org</a></li>
<li>Component docs: <a href="https://relaycode.org/docs/components" rel="noopener nofollow ugc">relaycode.org/docs/components</a></li>
<li>GitHub: <a href="https://github.com/itsyogesh/relaycode" rel="noopener nofollow ugc">github.com/itsyogesh/relaycode</a></li>
</ul>

Yogesh Kumar

Relaycode - Type-aware extrinsic builder for Polkadot

<h2><a name="p-38180-polkadot-news-1" class="anchor" href="#p-38180-polkadot-news-1" aria-label="Heading link"></a>Polkadot News</h2>
Check out the Polkadot Smart Contract developer resources and tools here <a href="https://x.com/paritytech/status/2027314772731904377" rel="noopener nofollow ugc">https://x.com/paritytech/status/2027314772731904377</a>
The referendum to retain bkchr at Rank 6 in the Polkadot Technical Fellowship is passing unanimously <a href="https://polkadot.subsquare.io/referenda/1846" rel="noopener nofollow ugc">https://polkadot.subsquare.io/referenda/1846</a>
“Polkadot-API 2026 Development Funding through Polkadot Community Foundation” is in the last day of 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>
Tip Request for Livestream Pilot “LIVE HACKS” by Sacha Lansky is now up for voting <a href="https://polkadot.subsquare.io/referenda/1847" rel="noopener nofollow ugc">https://polkadot.subsquare.io/referenda/1847</a>
<h2><a name="p-38180-kusama-news-2" class="anchor" href="#p-38180-kusama-news-2" aria-label="Heading link"></a>Kusama News</h2>
“Stage 3: Support the ONLY project generating revenue in Kusama. Expand, strengthen, and scale Card infrastructure for Kusama.” is in the confirmation period <a href="https://kusama.subsquare.io/referenda/634" class="inline-onebox" rel="noopener nofollow ugc">Stage 3: Support the ONLY project generating revenue in Kusama. Expand, strengthen, and scale Card infrastructure for Kusama.</a>

Radhakrishna Dasari

Polkadot Digest 27 February 2026

I’ve been using Nova on my iPhone for a while now and honestly, it’s been a game-changer. The UI is super clean and it makes things like staking or joining crowdloans way less intimidating.

Hey <a class="mention" href="/u/xixi765">@xixi765</a> thanks for restarting the forum post just on time… we are about to drop the academic paper and would love to hear your comments, cheers

Xiena

Hi everyone!
The proposal draft for Polkadot Sensei is ready and can be viewed here:
<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"> <a href="https://vonflandern.org/polkadot-sensei/proposalDraft.html" rel="noopener nofollow ugc">Proposal Draft</a>
I welcome any criticism, suggestions, and feedback — and of course anyone who gives the
<a href="https://vonflandern.org/polkadot-sensei/" rel="noopener nofollow ugc">beta version</a> a try!

vonFlandern

Polkadot Sensei

Hi everyone <img src="https://emoji.discourse-cdn.com/twitter/waving_hand.png?v=15" title=":waving_hand:" class="emoji" alt=":waving_hand:" loading="lazy" width="20" height="20">
We’d like to introduce ABAKO to the Polkadot community.
Over the past months, our team has been building a DAO-governed coordination layer for Web3 development teams. ABAKO is designed to assemble temporary joint ventures of developers to execute client-funded Web3 projects—transparently, reputation-based, and governed by on-chain rules.
The solution has been developed in collaboration with the Virto Team, using Virto’s technology stack on Kusama.
We’re grateful that ABAKO has received funding from the Web3 Foundation (Founders Grant), which has allowed us to move from concept to working prototype.
<hr>
<h3><a name="p-38165-a-bit-of-context-1" class="anchor" href="#p-38165-a-bit-of-context-1" aria-label="Heading link"></a>A bit of context</h3>
A few months ago, we published a call for interest to developers to help us understand real workflow needs in Web3 development: quoting, team formation, coordination, reputation, availability, etc.
That feedback directly shaped the current version of the application.
Now we’re entering Milestone 3: User Testing.
<hr>
<h2><a name="p-38165-call-for-testers-paid-collaboration-2" class="anchor" href="#p-38165-call-for-testers-paid-collaboration-2" aria-label="Heading link"></a>Call for Testers (Paid Collaboration)</h2>
We are looking for participants to join structured user-testing sessions next week.
This includes:
<ul>
<li>
Web3 developers (Tech Leads and devs)
</li>
<li>
Potential customers (founders, startups, protocols, teams needing Web3 development)
</li>
</ul>
Format:
<ul>
<li>
1h30’ session
</li>
<li>
Paid collaboration: 20 KSM
</li>
<li>
Remote
</li>
<li>
Recorded (for internal UX analysis)
</li>
</ul>
We have a limited number of slots to test the full workflow of the application, including:
<ul>
<li>
Customer request flow
</li>
<li>
Tech Lead quotation and team proposal
</li>
<li>
Developer selection and coordination logic
</li>
</ul>
You will be interacting with a live prototype and giving direct feedback on UX, clarity, and coordination mechanics.
<hr>
If you’re interested, please send an old-fashioned email to:
<a href="mailto:sukiko@abako.xyz">sukiko@abako.xyz</a>
Tell us:
<ul>
<li>
Who you are
</li>
<li>
Your Web3 experience
</li>
<li>
Your role preference for the testing (Customer / Tech Lead / Developer)
</li>
<li>
Your availability next week
</li>
</ul>
We’ll confirm slots directly by email.
<hr>
We’re excited to finally open this phase to the community. 
Looking forward to building this together.
— 
Sukiko 
ABAKO Team

sukiko

Introducing ABAKO – DAO-governed coordination for Web3 dev teams (User Testing Call – paid collaboration)

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

- 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

referenda1

treasury44

discussions1394