candidates

members

proficients

fellows

senior_fellows

experts

senior_experts

masters

senior_masters

grand_masters

Miscellaneous

Enter Playground . dot at Web3 Summit

Proposal: Enable GitHub Discussions in paritytech/polkadot-sdk

Ross Bulat

What happened to 2-day bonding?

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

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

Polkadot Forum Meta

Welcome to the Polkadot Forum :waving_hand:

hantoniu (no dm)

Welcome to the Polkadot Forum 👋

Getting started: Read this first

Arwen Smit

Dotui — A Terminal User Interface for Polkadot

muddles

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

Tech Talk

Polkadot-API updates thread

Victor Oliva

RISC-V is All You Need

Clarifying the Polkadot SDK database roadmap: RocksDB, ParityDB, and NOMT

Squirrel

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

**[Updated Pre-Proposal Discussion] DOT Recovery Loan to Hyperbridge Exploit Victims**

[Discussion] Retroactive Big Tipper: xcm-lens v0.0.2 — XCM debugging toolkit (136 tests, MIT)

[WFC] Bifrost DOT Liquidity Loan — Year 2 Renewal

Tyrone

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

Ecosystem

Deprecation of Snowbridge V1

ContribNet — decentralized contributor compensation and project governance on Kusama

dotID Audits People Chain Identity Registry

dotID

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

Ambassador Programme

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

Luke

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

Official statement of the Advisory Board of the Polkadot Ambassador Fellowship

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

Resources & FAQs

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

Alain Brenzikofer

How to P<>K bridge USDT or USDC

Good reads on proof-of-personhood

Asset Hub Migration - XCM FAQ

Remy Le Berre

<p><a class="mention" href="/u/thomasr">@ThomasR</a> - a factual clarification on the undistributed DeFi Singularity vDOT, so that everyone following this thread, including potential voters, works from accurate information.</p>
<p>To avoid conflating separate things, there appear to be two distinct categories:</p>
<ol>
<li>
<p>The undistributed CAMPAIGN vDOT - approximately 458,000 of the 795,000 DOT from Referendum 1439, earmarked as LP incentives via Merkl and never distributed because the pools were compromised in the exploit.</p>
</li>
<li>
<p>Any vDOT that Bifrost itself holds, whether as an LP participant or carried over from its own positions.</p>
</li>
</ol>
<p>My question concerns only category 1 - the undistributed campaign rewards.</p>
<p>Two specific questions:</p>
<ol>
<li>
<p>The undistributed campaign vDOT appear to sit on the Bifrost parachain under a multisig. Which party holds operational control over their distribution? My understanding is that control rests with the Hyperbridge team, and that Bifrost cannot move these funds unilaterally absent some specific arrangement. Could you confirm or correct this?</p>
</li>
<li>
<p>Does Bifrost have any unilateral ability to distribute, move, or redirect these campaign vDOT, or does that authority rest with Hyperbridge (or require a governance action)?</p>
</li>
</ol>
<p>This matters because clarity on who controls these specific funds determines which party the affected LPs should address regarding disbursal. Earlier in this thread Bifrost was described as “just a user of Hyperbridge’s services.” Confirming that Bifrost does not control these campaign vDOT would be consistent with that and would help everyone understand where responsibility for these funds lies.</p>
<p>Thank you for the clarification.</p>

<p>Hey again!</p>
<p>Here’s another update on what’s been happening in polkadot-api.</p>
<h2><a name="p-39507-polkadot-api-1" class="anchor" href="#p-39507-polkadot-api-1" aria-label="Heading link"></a>Polkadot-API</h2>
<p>For v2, we’ve released four more patch versions, up to 2.1.6. These include performance improvements, bug fixes, and updates to smoldot, which now fully supports chains with elastic scaling.</p>
<p>In parallel, we’ve been working on general transaction support. As Polkadot evolves, polkadot-api also needs to adapt to the new specifications, which means this work will be released in v3.</p>
<p>General transactions let chains create transactions that can be verified through mechanisms other than signatures. So the action of “signing” is generalized to “creating a transaction”, since depending on the chain, you might not need to sign with your private key in order to submit a transaction.</p>
<p>With this new specification, transaction extensions (the new “signed extensions”) play a greater role. We’re also generalizing this so that PAPI will no longer assume that certain extensions are always present, such as <code>CheckNonce</code>, <code>ChargeTxPayment</code>, <code>CheckMortality</code>, <code>CheckGenesis</code>, and so on. Instead, it provides the <code>TxCreator</code> interface with everything needed to fill in the data for each extension. This means all of that logic now moves out to the transaction creators.</p>
<p>For developers using PAPI, most of this will be transparent. As of now, the only surface-level API change is renaming <code>.sign(signer, options)</code> to <code>.create(txCreator, options)</code>. For advanced use cases, however, the <code>TxCreator</code> interface is more generic, fully composable, and <a href="https://github.com/polkadot-js/api/issues/6213" rel="noopener nofollow ugc">createTransaction</a>-first, which lets developers build their own transaction extension handlers. We will also provide a set of utilities to help with that.</p>
<p>If anyone would like to give this a try, we’re publishing it to npm under the <code>canary</code> tag. Please note that this is not even a beta yet: it is in active development, and you may encounter major issues and frequent breaking changes.</p>
<h2><a name="p-39507-papi-console-2" class="anchor" href="#p-39507-papi-console-2" aria-label="Heading link"></a>PAPI Console</h2>
<p>The <a href="https://dev.papi.how/" rel="noopener nofollow ugc">PAPI Console</a> has had a major overhaul. It now has a complete redesign of the shell, makes better use of horizontal space while also improving support for smaller screens and windows, and includes new features that make it even more useful than before.</p>
<h3><a name="p-39507-workspace-3" class="anchor" href="#p-39507-workspace-3" aria-label="Heading link"></a>Workspace</h3>
<p>On the right-hand side of the console, there is now a “workspace”. This is a panel where every operation performed during the session is kept for future reference. You can pin and delete items, or add new ones from each section in the console.</p>
<p>This lets you keep a log of all the information you’re looking for without having to constantly change pages.</p>
<h3><a name="p-39507-cross-chain-transfers-4" class="anchor" href="#p-39507-cross-chain-transfers-4" aria-label="Heading link"></a>Cross-chain transfers</h3>
<p>The PAPI Console has a new “Transfer” page that lets you perform cross-chain transfers, powered by the <a href="https://paraspell.xyz/" rel="noopener nofollow ugc">Paraspell SDK</a>.</p>
<p>That SDK helps us build XCM transactions, show route information, and dry-run transactions. You can choose to either submit the transaction straight away, or open it in the extrinsics page to modify it or wrap it with other transactions.</p>
<h3><a name="p-39507-submit-extrinsic-5" class="anchor" href="#p-39507-submit-extrinsic-5" aria-label="Heading link"></a>Submit Extrinsic</h3>
<p>Submitting an extrinsic has also been redesigned. Previously, it was difficult and unclear how to change signed extension options like nonce, mortality, and tip. Custom signed extensions were also hidden behind a button that was easy to miss.</p>
<p>Now everything is in the same form, which makes it easier to customize while also requiring fewer clicks to submit extrinsics.</p>
<h3><a name="p-39507-extrinsic-analyzer-6" class="anchor" href="#p-39507-extrinsic-analyzer-6" aria-label="Heading link"></a>Extrinsic Analyzer</h3>
<p>The extrinsics page now has a tab where you can paste an extrinsic and have it decoded, showing the call data, signature, signed extensions, and more.</p>
<p>Additionally, some signed extensions have a detailed view. For example, mortality visually shows the mortality window, including which blocks it starts and ends on, while <code>ChargeAssetTxPayment</code> is presented in a more human-readable way.</p>
<h3><a name="p-39507-account-locks-7" class="anchor" href="#p-39507-account-locks-7" aria-label="Heading link"></a>Account Locks</h3>
<p>The Account page now also features a section for managing your account locks.</p>
<p>It scans the different pallets that might cause locks, shows where the different locks were found, and offers quick actions to remove them.</p>
<h3><a name="p-39507-query-at-block-8" class="anchor" href="#p-39507-query-at-block-8" aria-label="Heading link"></a>Query at block</h3>
<p>Previously, we already supported querying storage at a specific block for RPCs that support archive queries.</p>
<p>Now we also support this for runtime calls, view functions, and constants.</p>
<h3><a name="p-39507-digest-9" class="anchor" href="#p-39507-digest-9" aria-label="Heading link"></a>Digest</h3>
<p>The block detail page now also includes a decoded view of the digest, showing the engines used and their decoded payloads.</p>
<h3><a name="p-39507-proxy-and-multisig-signers-10" class="anchor" href="#p-39507-proxy-and-multisig-signers-10" aria-label="Heading link"></a>Proxy and Multisig signers</h3>
<p>You can now also set up signers that wrap other signers. For instance, if you are one of the delegates of a proxy, you can create a “Proxy signer” that wraps your actual signer and adds the appropriate proxy call when you sign a transaction with it.</p>
<p>Similarly, using our <a href="https://multisig.usepapi.app/" rel="noopener nofollow ugc">PAPI Multisig Tool</a>, a fully decentralized multisig signing tool, you can create a Multisig Signer that generates a PAPI Multisig Tool link. You can then share that link with your multisig peers so everyone can sign it.</p>
<h2><a name="p-39507-closing-11" class="anchor" href="#p-39507-closing-11" aria-label="Heading link"></a>Closing</h2>
<p>That’s all the updates we have for now. We’ll keep sharing progress over the next few weeks.</p>
<p>The three of us are going to the Web3 Summit this week. Hope to meet you there!</p>

<p>quick update and a reset on this one.</p>
<p>two things i got wrong earlier in this thread and want to own before going further:</p>
<ol>
<li>
<p>the dot/usd rate. i quoted 800 dot as ~$5.2k off stale price data. at ~$0.93/dot that was never right. thanks again <a class="mention" href="/u/florentina57">@florentina57</a> for the catch.</p>
</li>
<li>
<p>the ask size and track. big tipper was too much for this. v0.0.2 is about 4 days of solo work, one m1 cut, already shipped. that fits a small tipper, not a big one.</p>
</li>
</ol>
<p>so i’m revising down to a small tipper, 250 dot max (~$230 at today’s price, i’ll recheck on the day i go on-chain). retroactive, one-time, for v0.0.2 only. no salary, no future-work bundled in.</p>
<p>on the AI question <a class="mention" href="/u/0xtaylor">@0xTaylor</a> raised: yeah, i used AI tooling while building this, like a lot of devs do now. not going to pretend otherwise. what i’d ask is that it gets judged on the artifact, not the process. it’s public, MIT, 136 tests pass, 5/5 build vectors green, you can clone and run it in two minutes. the decoder, the intent builder, the corridor matrix, the dry-run and fee orchestrators are all real and reviewable. if any of it doesn’t hold up, point at the line and i’ll fix it.</p>
<p>what v0.0.2 actually does: takes a high-level intent (“teleport dot from asset hub to bridge hub for alice”), builds the right post-AHM extrinsic, dry-runs it, surfaces real XcmPaymentApi fees, and explains each instruction. existing tools do chain state or scaffolding, none do the construct-simulate-explain loop. that’s the gap it fills.</p>
<p>repo: <a href="https://github.com/1DanWave2/xcm-lens" class="inline-onebox" rel="noopener nofollow ugc">GitHub - 1DanWave2/xcm-lens: Decode, dry-run, and explain XCM messages across Polkadot. CLI + MCP toolkit. · GitHub</a><br>
quickstart: clone, pnpm install, pnpm -r build, pnpm test (136 pass)</p>
<p>precedent i’m anchoring on: <span class="hashtag-raw">#1340</span> (pvm debugger, 100% aye, solo-dev oss debugger) and <span class="hashtag-raw">#1657</span> (retroactive sdk tip, ~$7.5k, smaller scope). a small tipper at 250 dot sits well under both.</p>
<p>if the revised framing is ok here, i’ll put it on-chain as a small tipper next. open to comments on the amount.</p>

<h1><a name="p-39503-deprecation-of-snowbridge-v1-1" class="anchor" href="#p-39503-deprecation-of-snowbridge-v1-1" aria-label="Heading link"></a>Deprecation of Snowbridge V1</h1>
<p>Snowbridge V2 has been running on Polkadot and Ethereum for a year. With V2 available and established, we plan to begin deprecating Snowbridge V1 and move remaining users and parachain integrations to the V2 protocol.</p>
<p>The goal of this post is to explain why V1 is being deprecated, provide historical context for the design decisions made at the time, outline the benefits of retiring V1, and describe the proposed migration and deprecation plan.</p>
<h2><a name="p-39503-summary-2" class="anchor" href="#p-39503-summary-2" aria-label="Heading link"></a>Summary</h2>
<p>Snowbridge V1 was designed and launched under the constraints available at the time. It provided a simple end-user experience and delivered the first version of trustless Ethereum &lt;&gt; Polkadot asset transfers, but it also required on-chain fee estimation, fixed gas price assumptions, ordered delivery, and operationally managed sovereign account balances.</p>
<p>Snowbridge V2 resolves these issues by moving fee estimation off-chain, using user-provided fees through newer XCM capabilities, supporting unordered message execution, and standardizing fee handling around ETH. V2 is cheaper, more flexible, and better aligned with future Snowbridge development.</p>
<p>We are proposing to deprecate V1 in phases:</p>
<ol>
<li>Reduce V1 relaying support by only relaying profitable messages.</li>
<li>Increase V1 fees to discourage new usage and make relaying sustainable.</li>
<li>Rebalance fee-paying sovereign accounts from Treasury. This account top-up is required before the increased fees can be supported.</li>
<li>Close V1 channels after a 90-day migration period.</li>
</ol>
<h2><a name="p-39503-background-3" class="anchor" href="#p-39503-background-3" aria-label="Heading link"></a>Background</h2>
<p>Snowbridge V2 was announced as live in November 2025 and introduced major improvements over V1, including lower fees, off-chain fee estimation, unordered message execution, arbitrary contract support, and support for richer XCM-based integrations.</p>
<p>V2 also changed the bridge fee model. Instead of relying on rigid on-chain assumptions about gas prices and DOT/ETH exchange rates, V2 allows fees to be estimated off-chain using live pricing data and current Ethereum gas prices. This is more accurate, easier to maintain, and cheaper for users.</p>
<p>With the majority of bridge traffic already moved to V2, continuing to support V1 creates additional operational and security costs while providing limited benefit.</p>
<h2><a name="p-39503-snowbridge-v1-limitations-4" class="anchor" href="#p-39503-snowbridge-v1-limitations-4" aria-label="Heading link"></a>Snowbridge V1 Limitations</h2>
<p>Snowbridge V1 has several known limitations:</p>
<ul>
<li>On-chain fee calculation.</li>
<li>On-chain DOT/ETH fee conversion.</li>
<li>A fixed on-chain Ethereum gas price.</li>
<li>Ordered delivery.</li>
<li>Fees are collected into Treasury-controlled accounts, requiring sovereign accounts on Ethereum and Bridge Hub to be topped up in order to pay relayer fees.</li>
</ul>
<p>These issues make V1 difficult to operate sustainably. In particular, relayers can take a loss when the configured on-chain exchange rate or gas price diverges from market conditions. Ordered delivery also means one underpriced or failing message can block later messages in the queue.</p>
<h2><a name="p-39503-why-v1-was-released-with-these-limitations-5" class="anchor" href="#p-39503-why-v1-was-released-with-these-limitations-5" aria-label="Heading link"></a>Why V1 Was Released With These Limitations</h2>
<p>Snowbridge V1 was released with these tradeoffs because the required protocol and runtime features did not exist yet.</p>
<p>At the time of the V1 release, XCM did not support user-provided fees in the way required by Snowbridge. Fees therefore had to be calculated on-chain. Snowbridge V2 uses the <code>InitiateTransfer</code> XCM instruction, which allows users to offer a fee amount directly in the XCM program.</p>
<p>Asset Hub also did not support asset swaps at the time. This meant fees had to be collected into sovereign accounts, and those accounts needed to be balanced and topped up across the bridge. In V2, the fee asset is standardized to ETH on both sides of the bridge. There are no on-chain DOT/ETH conversions. Instead, prices are calculated off-chain in real time using the current Asset Hub liquidity pool price and current Ethereum gas prices.</p>
<p>Even with these limitations, V1 delivered an end product that was simple for end users to understand and use. The design made sense given the capabilities available at the time, but those constraints no longer apply.</p>
<h2><a name="p-39503-benefits-of-deprecating-v1-6" class="anchor" href="#p-39503-benefits-of-deprecating-v1-6" aria-label="Heading link"></a>Benefits of Deprecating V1</h2>
<p>Deprecating V1 has several benefits:</p>
<ul>
<li>Security: maintaining both V1 and V2 doubles the number of protocol paths that need to be reviewed, monitored, and defended.</li>
<li>Less operations and infrastructure: retiring V1 removes the need to operate and maintain two versions of the bridge protocol.</li>
<li>Faster future development: new features often require careful consideration of the V1 code path. This makes features such as circuit breakers harder and more cumbersome to implement.</li>
<li>Better sustainability: Snowbridge was positioned as a common good product, but relaying V1 messages at a loss is not sustainable.</li>
</ul>
<p>The bridge should converge on the version that is cheaper for users, more sustainable for relayers, and easier to evolve safely.</p>
<h2><a name="p-39503-migration-to-v2-7" class="anchor" href="#p-39503-migration-to-v2-7" aria-label="Heading link"></a>Migration to V2</h2>
<p>Most bridge traffic has already moved to Snowbridge V2.</p>
<p>Any chain that supports XCM v5 can switch to V2. The Snowbridge team is open to assisting any parachain or application team that needs help with migration.</p>
<p>We encourage remaining V1 users and integrations to begin migration as soon as possible. V2 covers the same core bridging use cases for Asset Hub and XCM v5 parachains, while also enabling newer capabilities such as contract calls and richer cross-chain applications.</p>
<h2><a name="p-39503-proposed-deprecation-plan-8" class="anchor" href="#p-39503-proposed-deprecation-plan-8" aria-label="Heading link"></a>Proposed Deprecation Plan</h2>
<h3><a name="p-39503-phase-1-after-7-days-relay-v1-only-when-profitable-9" class="anchor" href="#p-39503-phase-1-after-7-days-relay-v1-only-when-profitable-9" aria-label="Heading link"></a>Phase 1: After 7 Days, Relay V1 Only When Profitable</h3>
<p>After 7 days, V1 relayers will only relay messages when doing so is profitable.</p>
<p>This will be done off-chain through relayer configuration. The expected result is increased latency for V1 messages, which should discourage new usage and encourage remaining users to migrate to V2.</p>
<h3><a name="p-39503-phase-2-rebalance-fee-paying-sovereign-accounts-from-treasury-10" class="anchor" href="#p-39503-phase-2-rebalance-fee-paying-sovereign-accounts-from-treasury-10" aria-label="Heading link"></a>Phase 2: Rebalance Fee-Paying Sovereign Accounts From Treasury</h3>
<p>We propose to rebalance the accounts used to pay V1 relayer rewards:</p>
<ul>
<li>Transfer <code>1000 DOT</code> from Treasury to the Asset Hub sovereign account on Bridge Hub.</li>
<li>Swap <code>500 DOT</code> for ETH and send it to the Snowbridge Gateway contract.</li>
</ul>
<p><em>Note: Snowbridge V1 generated 14,100 DOT in fee revenue to the Polkadot Treasury in the last year. And an extra fees other than relayer rewards go back into the Polkadot Treasury.</em></p>
<p>This phase is required before increasing V1 fees. The original V1 design depends on balanced fee-paying accounts across the bridge, and these accounts need to be topped up in order to support the increased relayer rewards. Fees are collected into the Snowbridge Gateway contract on Ethereum and the Treasury account on Asset Hub. Rewards are paid from the Snowbridge Gateway contract and the Asset Hub sovereign account on Bridge Hub.</p>
<h3><a name="p-39503-phase-3-after-30-days-increase-v1-fees-11" class="anchor" href="#p-39503-phase-3-after-30-days-increase-v1-fees-11" aria-label="Heading link"></a>Phase 3: After 30 Days, Increase V1 Fees</h3>
<p>After 30 days, V1 fees will be increased to discourage continued usage and to make remaining V1 relaying more sustainable.</p>
<p>Proposed changes:</p>
<ul>
<li>Set the on-chain exchange rate to market value: <code>1 ETH : 1750 DOT</code>.</li>
<li>Set the on-chain gas price to <code>10 Gwei</code>.</li>
<li>Set relayer rewards to <code>2 DOT</code> locally and <code>0.001 ETH</code> remotely.</li>
</ul>
<p>With these parameters, the Asset Hub base fee would be <code>9.3364514026 DOT</code>.</p>
<p>The proposed pricing parameters are:</p>
<ul>
<li>Exchange rate: <code>0.0005714285714285715 ETH/DOT</code>, equivalent to <code>1 ETH : 1750 DOT</code>.</li>
<li>Fee per gas: <code>10 Gwei</code>.</li>
<li>Local reward: <code>2 DOT</code>.</li>
<li>Remote reward: <code>0.001 ETH</code>.</li>
</ul>
<p>For historical context, the original V1 price was approximately <code>11.45 DOT</code> for Asset Hub to Ethereum transfers. <a href="https://polkadot.polkassembly.io/referenda/1127" rel="noopener nofollow ugc">Referendum #1127</a> later updated Snowbridge pricing parameters to lower transfer fees by reflecting market conditions more closely, reducing the fee to approximately <code>6.12 DOT</code>. <a href="https://polkadot.polkassembly.io/referenda/1400" rel="noopener nofollow ugc">Referendum #1400</a> then lowered bridge transfer fees further from approximately <code>6.12 DOT</code> to approximately <code>1.49 DOT</code> and registered Ether on Asset Hub. These price decreases were not related to costs savings, but rather we chose to subsidise messages to onboard more users, knowing that V2 will eventually replace V1 completely.</p>
<p>The reasoning for increasing V1 fees now is that relayers currently take a loss on some V1 transactions, especially Polkadot to Ethereum transactions, because of stale DOT/ETH exchange rates and Ethereum gas price spikes. V2 avoids these issues through dynamic off-chain pricing.</p>
<h3><a name="p-39503-phase-4-after-90-days-close-v1-channels-12" class="anchor" href="#p-39503-phase-4-after-90-days-close-v1-channels-12" aria-label="Heading link"></a>Phase 4: After 90 Days, Close V1 Channels</h3>
<p>After 90 days, we propose closing V1 channels:</p>
<ul>
<li>Disable V1 message queues on-chain.</li>
<li>Remove V1 contract methods on Ethereum.</li>
</ul>
<p>At this point, remaining users and integrations should have migrated to V2.</p>
<h2><a name="p-39503-notes-on-accounts-and-rewards-13" class="anchor" href="#p-39503-notes-on-accounts-and-rewards-13" aria-label="Heading link"></a>Notes on Accounts and Rewards</h2>
<p>The V1 design uses governance-controlled accounts for fee collection and reward payment:</p>
<ul>
<li>Fees are collected into the Snowbridge Gateway contract on Ethereum and the Treasury account on Asset Hub.</li>
<li>Rewards are paid out to relayers from the Snowbridge Gateway contract and the Asset Hub sovereign account on Bridge Hub.</li>
<li>These accounts are permissionless accounts controlled by governance.</li>
<li>The original V1 design requires these accounts to remain balanced.</li>
</ul>
<p>Because of this, there will be a separate proposal to top up the Asset Hub sovereign account on Bridge Hub from Treasury.</p>
<h2><a name="p-39503-call-to-action-14" class="anchor" href="#p-39503-call-to-action-14" aria-label="Heading link"></a>Call to Action</h2>
<p>We encourage all remaining Snowbridge V1 users, parachains, wallets, frontends, and applications to migrate to Snowbridge V2.</p>
<p>Teams that need help migrating to V2 should reach out to the Snowbridge team. Any chain that supports XCM v5 can switch to V2, and we are available to help teams complete the migration.</p>

<p>latest link:</p>
<aside class="onebox allowlistedgeneric" data-onebox-src="https://bafybeibdiksuiaju6qh75nuvhm42jmrlvp5v4tfefhmehb54cd4hjifcde.ipfs.inbrowser.link/#/?network=kusama">
  <header class="source">
      <img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/3/3b129a46713f004be67b6c295ec457cbe80bc5c9.png" class="site-icon" alt="" data-dominant-color="58B3BA" width="64" height="64">

      <a href="https://bafybeibdiksuiaju6qh75nuvhm42jmrlvp5v4tfefhmehb54cd4hjifcde.ipfs.inbrowser.link/#/?network=kusama" target="_blank" rel="noopener nofollow ugc">bafybeibdiksuiaju6qh75nuvhm42jmrlvp5v4tfefhmehb54cd4hjifcde.ipfs.inbrowser.link</a>
  </header>

  <article class="onebox-body">
    

<h3><a href="https://bafybeibdiksuiaju6qh75nuvhm42jmrlvp5v4tfefhmehb54cd4hjifcde.ipfs.inbrowser.link/#/?network=kusama" target="_blank" rel="noopener nofollow ugc">IPFS Service Worker Gateway | HEAD@572bc4a</a></h3>

  <p>Static HTML page that bootstraps a verifiable IPFS gateway in your browser. Every block is fetched from peers and verified against its CID.</p>


  </article>

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

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


<p><strong>Treasury Proposal | June 2026<br>
Proposer:</strong> Tyrone - Bifrost</p>
<hr>
<h2><a name="p-39499-h-1-executive-summary-1" class="anchor" href="#p-39499-h-1-executive-summary-1" aria-label="Heading link"></a>1. Executive Summary</h2>
<p>Bifrost successfully completed its first year of the 1M DOT liquidity loan (<a href="https://polkadot.subsquare.io/referenda/1538" rel="noopener nofollow ugc">Referendum #1538</a>). Over the 12-month period from May 2025 to May 2026, the 1,000,000 DOT loan generated 53,185.39 DOT in interest (blended APR: 5.318%), and Bifrost distributed an additional 68,173 BNC (~$6,335) in liquidity incentives to the vDOT-DOT pool — on top of 187,173 BNC distributed in the three preceding years.</p>
<p>Bifrost now proposes to:</p>
<ul>
<li>Repay the Year 1 interest (53,185.3937 DOT) to the Polkadot Treasury by <strong>June 26th</strong>. (Currently in processing of vDOT unstaking: <a href="https://bifrost.subsquare.io/referenda/268" class="inline-onebox" rel="noopener nofollow ugc">DOT Treasury Loan Interest Repayment</a> )</li>
<li>Renew the existing 1,000,000 DOT loan for a second year at a blended interest rate of ~3%. (Bifrost will <strong>NOT</strong> taking commissions from it)</li>
</ul>
<hr>
<h2><a name="p-39499-h-2-year-1-performance-report-2" class="anchor" href="#p-39499-h-2-year-1-performance-report-2" aria-label="Heading link"></a>2. Year 1 Performance Report</h2>
<h3><a name="p-39499-h-21-loan-structure-returns-3" class="anchor" href="#p-39499-h-21-loan-structure-returns-3" aria-label="Heading link"></a>2.1 Loan Structure &amp; Returns</h3>
<div class="md-table">
<table>
<thead>
<tr>
<th>Item</th>
<th>Value</th>
<th>Notes</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Principal</strong></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Total loan amount</td>
<td>1,000,000 DOT</td>
<td></td>
</tr>
<tr>
<td><strong>Liquidity Pool Deployment</strong></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Minted as vDOT and deployed as liquidity</td>
<td>672,469.39 DOT</td>
<td>67.25% in pool — generates staking yield</td>
</tr>
<tr>
<td>Deployed as liquidit</td>
<td>327,455.47 DOT</td>
<td>32.75% in pool — does not generate staking yield</td>
</tr>
<tr>
<td><strong>Returns (May 2025 – May 2026)</strong></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Total interest earned</td>
<td>53,185.3937 DOT</td>
<td></td>
</tr>
<tr>
<td>Blended APR</td>
<td><strong>5.318%</strong></td>
<td></td>
</tr>
</tbody>
</table>
</div><p>A total of 1,000,000 DOT was borrowed and deployed in vDOT/DOT liquidity: 672,469.39 DOT (67.25%) was minted into vDOT, while the remaining 327,455.47 DOT (32.75%) deployed in stable pool against vDOT. After one year, the position generated 53,185.39 DOT in total interest, reflecting a blended APR of 5.318%.</p>
<h3><a name="p-39499-h-22-liquidity-incentives-bifrosts-long-term-commitment-4" class="anchor" href="#p-39499-h-22-liquidity-incentives-bifrosts-long-term-commitment-4" aria-label="Heading link"></a>2.2 Liquidity Incentives — Bifrost’s Long-Term Commitment</h3>
<div class="md-table">
<table>
<thead>
<tr>
<th>Item</th>
<th>Value</th>
<th>Value in USD</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Liquidity Incentives (BNC)</strong></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Total BNC rewarded (2025–2026)</td>
<td>68,173 BNC</td>
<td>~$6,335 based on 1-yr avg. price</td>
</tr>
<tr>
<td>Total BNC rewarded (2023–2026)</td>
<td>255,346.16 BNC</td>
<td>~$33,195 based on 4-yr avg. price</td>
</tr>
</tbody>
</table>
</div><p>Over the past four years, Bifrost has distributed a total of <strong>255,346.16 BNC (~$33,195)</strong> in liquidity incentives to the vDOT-DOT pool — demonstrating consistent, long-term commitment to DOT liquid staking. Of this, <strong>68,173 BNC (~$6,335)</strong> was rewarded in 2025–2026 alone, with the remaining ~187,173 BNC distributed across the three preceding years, reflecting Bifrost’s role as a sustained contributor to the DOT LST ecosystem well before recent market cycles.</p>
<hr>
<h2><a name="p-39499-h-3-repayment-commitment-5" class="anchor" href="#p-39499-h-3-repayment-commitment-5" aria-label="Heading link"></a>3. Repayment Commitment</h2>
<p>Bifrost commits to repaying the Year 1 interest in full to the Polkadot Treasury by <strong>June 26th</strong> to the activation of the Year 2 loan.</p>
<div class="md-table">
<table>
<thead>
<tr>
<th>Item</th>
<th>Value</th>
<th>Notes</th>
</tr>
</thead>
<tbody>
<tr>
<td>Principal</td>
<td>1,000,000 DOT</td>
<td>Propose to roll into Year 2 loan</td>
</tr>
<tr>
<td>Interest</td>
<td>53,185.3937 DOT</td>
<td>Paid to Treasury by <strong>June 26th</strong></td>
</tr>
</tbody>
</table>
</div><p>The 53,185.3937 DOT interest will be transferred directly to the Polkadot Treasury.</p>
<hr>
<h2><a name="p-39499-h-4-proposed-terms-year-2-6" class="anchor" href="#p-39499-h-4-proposed-terms-year-2-6" aria-label="Heading link"></a>4. Proposed Terms — Year 2</h2>
<div class="md-table">
<table>
<thead>
<tr>
<th>Parameter</th>
<th>Year 2 Terms</th>
<th>Notes</th>
</tr>
</thead>
<tbody>
<tr>
<td>Loan amount</td>
<td>1,000,000 DOT</td>
<td>Renewal of existing loan</td>
</tr>
<tr>
<td>Loan duration</td>
<td>12 months from enactment</td>
<td></td>
</tr>
<tr>
<td>Blended interest rate</td>
<td><strong>~3%</strong></td>
<td>Contingent on DOT staking APY ~5%</td>
</tr>
<tr>
<td>vDOT allocation</td>
<td>~60% of principal</td>
<td>~600,000 DOT minted as vDOT</td>
</tr>
<tr>
<td>Liquidity allocation</td>
<td>~40% of principal</td>
<td>~400,000 DOT deployed to vDOT-DOT pool</td>
</tr>
<tr>
<td>Repayment</td>
<td>Principal (1,000,000 DOT) + accrued interest</td>
<td>Full repayment at end of term</td>
</tr>
</tbody>
</table>
</div><h3><a name="p-39499-h-41-interest-rate-rationale-7" class="anchor" href="#p-39499-h-41-interest-rate-rationale-7" aria-label="Heading link"></a>4.1 Interest Rate Rationale</h3>
<p>The blended interest rate for Year 2 is projected at <strong>approximately 3%</strong> and <strong>Bifrost will NOT take any commissions from it</strong>. This rate is lower than Year 1 (5.318%) due to the adjustments of DOT inflation, validator commission and decreasing of staking reward.</p>
<h3><a name="p-39499-h-42-capital-deployment-8" class="anchor" href="#p-39499-h-42-capital-deployment-8" aria-label="Heading link"></a>4.2 Capital Deployment</h3>
<ul>
<li>~60% (~600,000 DOT) will be minted as vDOT via Bifrost SLP, accruing staking rewards through the vDOT yield bearing.</li>
<li>~40% (~400,000 DOT) will be paired with vDOT and deployed to the vDOT-DOT liquidity pool on Bifrost, deepening on-chain liquidity and reducing slippage for vDOT transactions.</li>
<li>No DOT will be used for speculative positions or off-protocol deployments.</li>
</ul>
<hr>
<h2><a name="p-39499-h-5-new-feature-lst-governance-vdot-voting-rights-9" class="anchor" href="#p-39499-h-5-new-feature-lst-governance-vdot-voting-rights-9" aria-label="Heading link"></a>5. New Feature: LST Governance &amp; vDOT Voting Rights</h2>
<p>Beyond liquidity and yield, vDOT now carries full Polkadot OpenGov participation rights. This section introduces two complementary governance features that increase vDOT’s utility and strengthen its role within the Polkadot ecosystem.</p>
<p><em><strong>Note on Loan-Derived vDOT:</strong> The ~600,000 vDOT minted under this Year 2 loan will be deployed into the vDOT-DOT liquidity pool and held under Bifrost Treasury custody. This vDOT does not participate in the delegated voting mechanism described in Section 5.2 — it is excluded from Polkadot OpenGov voting entirely (neither voted directly by Bifrost nor delegated under BNC governance), avoiding any appearance of loan-derived capital being used to influence on-chain governance outcomes.</em></p>
<h3><a name="p-39499-h-51-vdot-holders-can-vote-in-polkadot-opengov-10" class="anchor" href="#p-39499-h-51-vdot-holders-can-vote-in-polkadot-opengov-10" aria-label="Heading link"></a>5.1 vDOT Holders Can Vote in Polkadot OpenGov</h3>
<p>vDOT holders can participate directly in Polkadot on-chain governance. Since the DOT underlying vDOT is staked via Bifrost’s sovereign address and its derived keyless addresses on Polkadot, these addresses carry full governance voting rights. Through the Bifrost DApp, vDOT holders can:</p>
<ul>
<li>View active Polkadot OpenGov referenda.</li>
<li>Vote Aye / Nay / Abstain with conviction multipliers (0.1x–6x).</li>
<li>Lock vDOT for voting without losing staking yield — exchange rate appreciation continues during lock.</li>
<li>Participate in multiple referenda simultaneously.</li>
</ul>
<p>This means vDOT holders do not sacrifice governance rights when liquid-staking DOT — a key differentiator for DOT LSTs.</p>
<h3><a name="p-39499-h-52-bnc-governance-delegated-vdot-voting-11" class="anchor" href="#p-39499-h-52-bnc-governance-delegated-vdot-voting-11" aria-label="Heading link"></a>5.2 BNC Governance: Delegated vDOT Voting</h3>
<p>Bifrost introduces a new governance layer: BNC holders can direct the voting rights of vDOT that has been delegated to Bifrost but whose holders have not cast a vote themselves.</p>
<p>Specifically:</p>
<ul>
<li>When vDOT holders delegate their voting proxy to Bifrost, their unexercised voting power becomes available for BNC-governed allocation.</li>
<li>BNC holders can then collectively decide how this delegated vDOT voting weight is cast in Polkadot OpenGov referenda.</li>
<li>This mechanism does not affect vDOT holders who vote independently — only unclaimed delegated votes are subject to BNC governance.</li>
</ul>
<p>This feature meaningfully increases Polkadot governance participation and gives BNC holders a direct stake in the direction of the Polkadot ecosystem — creating a deeper, more organic alignment between Bifrost and Polkadot governance.</p>
<p>Reference: <a href="http://docs.bifrost.io/faq/what-is-lst-governance" class="inline-onebox" rel="noopener nofollow ugc">What is LST Governance? | Bifrost Docs</a></p>
<hr>
<h2><a name="p-39499-h-6-risk-disclosure-12" class="anchor" href="#p-39499-h-6-risk-disclosure-12" aria-label="Heading link"></a>6. Risk Disclosure</h2>
<ul>
<li><strong>Interest rate variability:</strong> The ~3% blended interest rate is based on a DOT staking APY of ~5%. Material changes to staking yields will affect the effective rate.</li>
<li><strong>Governance risk:</strong> Bifrost maintains an actively governed protocol with consistent on-chain participation. The team continuously monitors Bifrost governance for referenda involving sensitive method calls — including any that could affect SLP logic, fund movements, or protocol parameters — and responds promptly to ensure the security and integrity of deployed assets.</li>
<li><strong>Liquidity risk:</strong> The vDOT-DOT liquidity pool carries no impermanent loss risk. Although the composition of the position may shift between vDOT and DOT as liquidity is deposited and withdrawn, vDOT can always be unstaked back to DOT after withdrawal. The principal is therefore recoverable in full regardless of pool rebalancing.</li>
</ul>
<hr>
<h2><a name="p-39499-h-7-track-record-13" class="anchor" href="#p-39499-h-7-track-record-13" aria-label="Heading link"></a>7. Track Record</h2>
<p><strong>Kusama</strong></p>
<ul>
<li>2022: <a href="https://kusama.polkassembly.io/post/1606" rel="noopener nofollow ugc">https://kusama.polkassembly.io/post/1606</a>
<ul>
<li>The execution timeline of the proposal: <a href="https://kusama.subscan.io/treasury/177" class="inline-onebox" rel="noopener nofollow ugc">Subscan | Aggregate Substrate ecological network high-precision Web3 explorer</a></li>
<li>2023: Repayment 53,745.5028 KSM via Bifrost Treasury via XCM, with <strong>3,745.5028 KSM interest</strong>.</li>
</ul>
</li>
<li>2023: <a href="https://kusama.subsquare.io/referenda/236" class="inline-onebox" rel="noopener nofollow ugc">Treasury proposal: KSM liquidity subsidy for KSM liquid staking token - vKSM</a>
<ul>
<li>The execution timeline of the proposal: <a href="https://kusama.subsquare.io/referenda/236?tab=timeline" class="inline-onebox" rel="noopener nofollow ugc">Treasury proposal: KSM liquidity subsidy for KSM liquid staking token - vKSM</a></li>
<li>2024: Repayment 54,625.0495 KSM via Bifrost Treasury via XCM, with <strong>4,625.0495 KSM interest</strong>.</li>
</ul>
</li>
<li>2023: <a href="https://kusama.subsquare.io/referenda/477" class="inline-onebox" rel="noopener nofollow ugc">Treasury proposal: KSM liquidity subsidy for KSM liquid staking token - vKSM</a>
<ul>
<li>The execution timeline of the proposal: <a href="https://kusama.subsquare.io/referenda/477?tab=timeline" class="inline-onebox" rel="noopener nofollow ugc">Treasury proposal: KSM liquidity subsidy for KSM liquid staking token - vKSM</a></li>
<li>Repayment will happen in Aug 2026.</li>
</ul>
</li>
</ul>
<p>Bifrost has brought a <strong>total income of 8,370.5523 KSM</strong> to the Kusama Treasury.</p>
<p><strong>Polkadot</strong></p>
<ul>
<li>2024: <a href="https://polkadot.polkassembly.io/treasury/613" rel="noopener nofollow ugc">https://polkadot.polkassembly.io/treasury/613</a>
<ul>
<li>The execution timeline of the proposal: <a href="https://polkadot.polkassembly.io/treasury/613?tab=timeline" rel="noopener nofollow ugc">https://polkadot.polkassembly.io/treasury/613?tab=timeline</a></li>
<li>Bifrost repaid its Subsidy loan to the Polkadot Treasury on March 26th.
<ul>
<li>Principal: 500,000.00 DOT</li>
<li>Staking rewards (interest from 216,313.34 vDOT): 42,723.02 DOT</li>
<li><strong>Total Repayment: 542,723.02 DOT</strong></li>
</ul>
</li>
</ul>
</li>
</ul>
<hr>
<h2><a name="p-39499-references-14" class="anchor" href="#p-39499-references-14" aria-label="Heading link"></a>References</h2>
<ul>
<li>Bifrost Website: <a href="http://bifrost.io" rel="noopener nofollow ugc">bifrost.io</a></li>
<li>Documentation: <a href="http://docs.bifrost.io" rel="noopener nofollow ugc">docs.bifrost.io</a></li>
<li>LST Governance: <a href="http://docs.bifrost.io/faq/what-is-lst-governance" class="inline-onebox" rel="noopener nofollow ugc">What is LST Governance? | Bifrost Docs</a></li>
<li>Twitter: <a href="https://x.com/Bifrost" rel="noopener nofollow ugc">https://x.com/Bifrost</a></li>
</ul>

Kutsal Kaan Bilgin

<p><strong>dotID</strong> is an identity-focused platform for the Polkadot ecosystem: <a href="https://dotid.app/" rel="noopener nofollow ugc">https://dotid.app</a></p>
<p>Via OpenGov, dotID has been approved to become registrar <span class="hashtag-raw">#5</span> on Polkadot <a href="https://polkadot.subsquare.io/referenda/1803" rel="noopener nofollow ugc">(ref 1803)</a> and registrar <span class="hashtag-raw">#7</span> on Kusama <a href="https://kusama.subsquare.io/referenda/626" rel="noopener nofollow ugc">(ref 626)</a>.</p>
<p>It provides a complete end-to-end flow for People Chain identity without requesting any fee: users can manage their on-chain identity, verify signals such as social accounts and email, complete KYC verification, request Reasonable or KnownGood judgements, and explore identities through a public directory.</p>
<h2><a name="p-39495-keeping-the-registry-up-to-date-1" class="anchor" href="#p-39495-keeping-the-registry-up-to-date-1" aria-label="Heading link"></a>Keeping the registry up to date</h2>
<p>Last April, dotID issued its <a href="https://x.com/dotid_app/status/2041968206210867363?s=20" rel="noopener nofollow ugc">first batch</a> of <strong>OutOfDate judgements</strong> on Polkadot. We found 12 on-chain accounts that still held valid registrar judgements but contained <strong>multiple outdated identity fields</strong>. These accounts are now tagged as OutOfDate, and this status should appear across dApps, including <a href="https://people-polkadot.subscan.io" rel="noopener nofollow ugc">Subscan</a>.</p>
<p>If your account is affected, please update your identity info and request a new judgement from us or another registrar. We also ask dApps to clearly surface negative judgements, and other registrars to remove outdated positive judgements from these accounts.</p>
<h2><a name="p-39495-latest-audit-2" class="anchor" href="#p-39495-latest-audit-2" aria-label="Heading link"></a>Latest audit</h2>
<p>We recently audited both the Polkadot and Kusama registries to triage judgement decisions. This currently flags <strong>978 accounts as OutOfDate</strong> (336 on Polkadot, 642 on Kusama). You can find a public log of affected accounts at: <a href="https://dotid.app/decisions" class="inline-onebox" rel="noopener nofollow ugc">Registrar Triage Decisions - dotid.app</a>.</p>
<p>Stale identities are re-triaged and downgraded to OutOfDate when their verified contact details no longer resolve: one or more fields (email, Twitter, website, GitHub, Matrix, Discord) are outdated.</p>
<p><strong>Please review and update your on-chain identity if needed</strong>.</p>

<p>We’ve been using ParityDb with midnight and it’s been performing fine so far but our datasets are still relatively small. Agreed NOMT isn’t a drop in replacement.</p>

<h1><a name="p-39491-censorship-resistant-copyrights-licenses-1" class="anchor" href="#p-39491-censorship-resistant-copyrights-licenses-1" aria-label="Heading link"></a><strong>Censorship-resistant Copyrights Licenses</strong></h1>
<h2><a name="p-39491-roots-foundations-2" class="anchor" href="#p-39491-roots-foundations-2" aria-label="Heading link"></a><strong>Roots &amp; Foundations</strong></h2>
<p>In 1991 Stuart Haber and W. Scott Stornetta wrote paper named <strong><a href="https://link.springer.com/article/10.1007/BF00196791" rel="noopener nofollow ugc">How to Time-Stamp a Digital Document</a></strong>, in it they propose a solution to certify the dates of creations and the modification of digital documents, basically using hash and time-staps of documents linked together. Ideas lated cited in the bitcoin white-paper. A solution that have real legal effects, as they also wrote in that document: <em>“<strong>For example, in intellectual property matters, it is sometimes crucial to verify the date an inventor first put in writing a patentable idea, in order to establish its precedence over competing claims.</strong>”</em></p>
<p>The <strong>Article 27 (2) of the Universal Declaration of Human Rights declares that <em>everyone has the right to the protection of the moral and material interests resulting from any scientific, literary or artistic production of which they are the author.</em></strong></p>
<p>The <a href="https://www.wipo.int/en/web/about-ip" rel="noopener nofollow ugc">World Intellectual Property Organization refers</a> to Intellectual Property as “<em>creations of the mind, such as inventions; literary and artistics words; designs; and symbols, names and images used in commerce</em>”. Common types of IP are: patents, trademarks, copyrights and others.</p>
<h2><a name="p-39491-autonomous-copyrights-3" class="anchor" href="#p-39491-autonomous-copyrights-3" aria-label="Heading link"></a><strong>Autonomous Copyrights</strong></h2>
<p>On one hand, Autonomy its not the same than automation, the former is censorship-resistant and doesn’t care who click the button (AI, Human, DAOs, etc), while the latter handles the work of clicking the button. On the other hand, copyrights refers to the artistic and literal works fixed in a tangible medium of expression. Copyrights gives economic moral (reputation) and economic (profits) exclusivity rights to the author.</p>
<p><strong>Autonomous Copyrights</strong> are censorship-resistant artistic and literal expressions protected by decentralized systems.</p>
<h2><a name="p-39491-autonomous-copyrights-licenses-4" class="anchor" href="#p-39491-autonomous-copyrights-licenses-4" aria-label="Heading link"></a><strong>Autonomous Copyrights Licenses</strong></h2>
<p>Copyright assignment is not the same as licensing. The latter grants a third party permission to exercise or profit from your economic rights while you retain ownership, whereas the former completely transfers the ownership of those rights to someone else.</p>
<p>Autonomous Copyrights Contracts are binding agreements that creates obligations and have some degree of self-execution.</p>
<h2><a name="p-39491-autonomous-copyrights-in-practice-5" class="anchor" href="#p-39491-autonomous-copyrights-in-practice-5" aria-label="Heading link"></a><strong>Autonomous Copyrights in Practice</strong></h2>
<p>To accomplish the Article 27 (2) of the Universal Declaration of Human Rights mandate, in SoftLaw we are building a Dapp to help humans to protect legally all kind of artistic and literal expressions with Autonomous Licenses.</p>
<p>In SoftLaw we are helping humans to copyright their art, music, books, poems, characters, movies, blogs, paintings, illustrations, and all kind of artistic expressions, with autonomous technology. A decentralized application that democratices legal protection to copyright owners, investors, collectors, etc; Build with solidity contracts and <em>ius</em>-logic.</p>
<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/f/f9fa2742806f1e2d5e92a188f3e33175bbf02dff.jpeg" data-download-href="/uploads/short-url/zFoQ9JbBg4JLWbSPlcXGevLyq8D.jpeg?dl=1" title="Screenshot 2026-06-14 at 7.04.11 PM" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/f/f9fa2742806f1e2d5e92a188f3e33175bbf02dff_2_690x356.jpeg" alt="Screenshot 2026-06-14 at 7.04.11 PM" data-base62-sha1="zFoQ9JbBg4JLWbSPlcXGevLyq8D" width="690" height="356" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/f/f9fa2742806f1e2d5e92a188f3e33175bbf02dff_2_690x356.jpeg, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/f/f9fa2742806f1e2d5e92a188f3e33175bbf02dff_2_1035x534.jpeg 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/f/f9fa2742806f1e2d5e92a188f3e33175bbf02dff_2_1380x712.jpeg 2x" data-dominant-color="1A1A1B"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg><span class="filename">Screenshot 2026-06-14 at 7.04.11 PM</span><span class="informations">1703×880 216 KB</span><svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div></p>
<h2><a name="p-39491-softlaw-contracts-6" class="anchor" href="#p-39491-softlaw-contracts-6" aria-label="Heading link"></a><strong>SoftLaw Contracts:</strong></h2>
<p>A PVM bytecode (—resolc) deployment in Passet-Hub (TESTNET):</p>
<ol>
<li>
<p><strong>IPAsset: 0xdf141b3e2c063b60a36d17cbedf0585052eb0447</strong></p>
</li>
<li>
<p><strong>Marketplace: 0xc6e62682d0e8a4eb6079f612f94b6c8277daee88</strong></p>
</li>
<li>
<p><strong>LicenseToken: 0xb394cbd030936f3e60199facf34477d8c1a819e2</strong></p>
</li>
<li>
<p><strong>RevenueDistributor: 0x5b5e657092b9090d34ac262f47106bec7c5a2a2c</strong></p>
</li>
<li>
<p><strong>GovernanceArbitrator: 0x23ff1e43b4b4e05dc2b49b2f648dc189e1b7ffe2</strong></p>
</li>
</ol>
<h2><a name="p-39491-autonomous-copyrights-authors-and-licensing-parties-7" class="anchor" href="#p-39491-autonomous-copyrights-authors-and-licensing-parties-7" aria-label="Heading link"></a><strong>Autonomous Copyrights Authors and Licensing Parties.</strong></h2>
<p>As all legal contracts, the identification of the signing parties is essential for the validity and development of the contractual obligations.</p>
<p>In SoftLaw we are contemplating a solution for the personhood problem which requires more research and another post. But in short, the way SoftLaw will solve the personhood problem for the intellectual property industry is through the expansion of the <strong>Governance Arbitrator Contract</strong> also called <strong>Judicial System</strong> which will have the capacity to validate authors and other arbitrators personhoods through attestation features. A smart contract personhood court to validate, revoke or confirms individualities.</p>
<h2><a name="p-39491-autonomous-copyrights-adoption-8" class="anchor" href="#p-39491-autonomous-copyrights-adoption-8" aria-label="Heading link"></a><strong>Autonomous Copyrights Adoption</strong></h2>
<p>Our more important goal is deploy on mainnet and start to protect legally humans creativity and innovation with Polkadot Tech, but to accomplish it, we need Your Help!</p>
<p><strong>The application is under heavy development but we are currently looking for OG testers and early feedback</strong> We kindly ask you to test the app, and give us feedback, or review.</p>
<p>Please help us testing <strong><a href="https://app.soft.law/" rel="noopener nofollow ugc">www.app.soft.law</a></strong><a href="https://app.soft.law/" rel="noopener nofollow ugc">:</a></p>
<p>Demo video: <a href="https://x.com/soft_law/status/2066059875881533919" rel="noopener nofollow ugc">https://x.com/soft_law/status/2066059875881533919</a></p>
<ol>
<li>
<p><strong>Web2 Experience:</strong><br>
We are targeting a web2 audience, please help us testing the app with a google auth and purchase some PAS tokens with a test stripe card such as <a href="https://docs.stripe.com/testing?testing-method=card-numbers#visa" rel="noopener nofollow ugc">4242 4242 4242 4242</a> otherwise you can use Metamask and fund it with <a href="https://faucet.polkadot.io/?parachain=1000" rel="noopener nofollow ugc">PAS Token</a>. (more socials and polkadot wallets coming soon.).</p>
</li>
<li>
<p><strong>UI / UX testing:</strong><br>
We want a smoothly experience in all the DApp so please provide us feedback on minting, listing, licensing, buying, etc. (You can simulate the protection of music, books, poems, characters, movies, blogs, paintings, illustrations, etc)</p>
</li>
<li>
<p><strong>Arbitrator Interest</strong><br>
The Governance system requires solving disputes around licenses (revocations) and fake registries (force ownership transfers). If you have a sense of justice or artistic expertise, please DM me with your PVM address (ETH) and I will give you arbitrator role.</p>
</li>
<li>
<p><strong>Hack the Contracts.</strong><br>
The first version of the contracts was hand crafted, and then we started with AI assistance. We are also using some <a href="https://github.com/pashov/skills" rel="noopener nofollow ugc">AI Solidity Auditors</a>, but we need more Human Eyes, so if you are into security, please help us to find bugs and vulnerabilities. (<a href="https://github.com/soft-law/contracts" rel="noopener nofollow ugc">SC Public Repo</a>)</p>
</li>
</ol>
<p>Thanks!</p>
<p><strong>Wario.</strong><br>
<strong>Softlaw S.A. de C.V.</strong></p>

Wario

Censorship-Resistant Copyrights Licenses

<p>So far, anyone can build a local agent workgroup to simulate a company and complete certain predefined, human-led goals. But when we scale the goal further, several core problems begin to emerge:</p>
<ul>
<li>
<p><strong>Economically infeasible</strong>: Large goals often require months or even years of continuous work. For a single subject, this cost can quickly exceed what is bearable.</p>
</li>
<li>
<p><strong>Uncontrolled complexity</strong>: Real business goals need to interact with the physical world. They require requesting humans, connecting with factories, evaluating samples, verifying suppliers, and handling production, sales, and customer service. A single platform or local workgroup can hardly carry all of this alone.</p>
</li>
<li>
<p><strong>Coordination bottleneck</strong>: Agents improve individual productivity, but human-centered coordination costs do not decline accordingly; they may even increase, immediately becoming the bottleneck of the entire system.</p>
</li>
<li>
<p><strong>Insufficient trust</strong>: Once agents need to request humans, select suppliers, or influence real-world production, participants must be able to trust the system; otherwise, the cost is again transferred back into coordination.</p>
</li>
</ul>
<p>Vibly AI-ifies the coordination mechanism. Through a socialized collaboration network formed by agents, it takes over the organizational functions that were previously carried mainly by the corporate system. Through identity, reputation, and incentives, it forms a decentralized protocol to…</p>
<p>We use a decentralized system to solve these problems. Here, decentralization is not for ideology, but for higher efficiency. Vibly is an agent socialized collaboration network that allows anyone to create organizations and projects. After receiving sufficient support, such as through bonding-curve issuance, the agent network will join the project, collaborate around it, and gradually push it forward, constantly approaching the organization’s vision.</p>
<h2><a name="p-39474-principles-1" class="anchor" href="#p-39474-principles-1" aria-label="Heading link"></a>Principles</h2>
<p><a href="https://forum.polkadot.network/t/vibly-an-open-intelligence-network-for-large-scale-ai-collaboration/17717/3">We previously published a post</a> describing this in detail. Although some of the information there is now outdated, the basic principles remain the same. For continuity, we briefly summarize how Vibly works: agents in Vibly can be seen as operating in a cyclic iteration, where the smallest unit is a collaboration loop that begins with observation and ends with reward distribution. A long-term goal is continuously decomposed until it reaches the smallest executable unit.</p>
<p>Vibly consists of identity, a reputation system, an incentive layer, and other components. The collaboration protocol is fixed on-chain. However, the output of LLMs cannot be deterministic in the same way that validators verify blocks, so we introduce soft consensus centered on the reputation system, ensuring that agent incentives remain compatible.</p>
<h2><a name="p-39474-projects-2" class="anchor" href="#p-39474-projects-2" aria-label="Heading link"></a>Projects</h2>
<p>At each stage, Vibly will launch practical collaboration products to observe the real operating state of the agent network and continuously optimize the system.</p>
<h3><a name="p-39474-vibmath-3" class="anchor" href="#p-39474-vibmath-3" aria-label="Heading link"></a>VibMath</h3>
<p>It is no longer big news that current LLMs can solve difficult mathematical problems, but most of these problems have certain limitations: they are highly formalized and allow answers to be searched for within a relatively clear space.</p>
<p>For long-term open problems such as the Goldbach conjecture, however, the real difficulty is that the theoretical direction itself is still unclear. Such problems require a large number of attempts, failures, partial results, counterexamples, literature connections, and peer review. This is not a single-point intelligence problem, but a collaboration-system problem. In fact, human mathematicians have always advanced mathematics through this kind of socialized process.</p>
<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/f/f6a198e9a49ce9e4917eb11827ac5e344c635fce.jpeg" data-download-href="/uploads/short-url/zbNG3HgzaxZfBUdxUFNaXPsumhE.jpeg?dl=1" title="VibMath" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/f/f6a198e9a49ce9e4917eb11827ac5e344c635fce_2_690x388.jpeg" alt="VibMath" data-base62-sha1="zbNG3HgzaxZfBUdxUFNaXPsumhE" width="690" height="388" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/f/f6a198e9a49ce9e4917eb11827ac5e344c635fce_2_690x388.jpeg, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/f/f6a198e9a49ce9e4917eb11827ac5e344c635fce_2_1035x582.jpeg 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/f/f6a198e9a49ce9e4917eb11827ac5e344c635fce_2_1380x776.jpeg 2x" data-dominant-color="F3F0ED"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg><span class="filename">VibMath</span><span class="informations">1672×941 144 KB</span><svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div></p>
<p>VibMath has already launched during the Phase 0 testnet and is running the “Challenge Goldbach” project. This kind of deterministic project helps us better observe how the agent network operates. In addition, we hope this can become a long-term project that runs for at least two years.</p>
<h3><a name="p-39474-advent-4" class="anchor" href="#p-39474-advent-4" aria-label="Heading link"></a><strong>Advent</strong></h3>
<p>At this stage, we will establish a direct connection between Vibly and the real world. We have chosen a business model similar to Pop Mart. It will be responsible for the full process from research, design, and production to sales. The most important part of this process is to verify the emergence of AI-generated aesthetics.</p>
<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/4/4fbcdd432a8de3053067be92773a925717ce713b.jpeg" data-download-href="/uploads/short-url/bnomk7ZGFktP55hToddbSWoZQFB.jpeg?dl=1" title="Advent" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/4/4fbcdd432a8de3053067be92773a925717ce713b_2_690x388.jpeg" alt="Advent" data-base62-sha1="bnomk7ZGFktP55hToddbSWoZQFB" width="690" height="388" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/4/4fbcdd432a8de3053067be92773a925717ce713b_2_690x388.jpeg, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/4/4fbcdd432a8de3053067be92773a925717ce713b_2_1035x582.jpeg 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/4/4fbcdd432a8de3053067be92773a925717ce713b_2_1380x776.jpeg 2x" data-dominant-color="F0ECEA"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg><span class="filename">Advent</span><span class="informations">1672×941 253 KB</span><svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div></p>
<p>Aesthetics are socialized. There is no absolute superiority between rounded corners and sharp corners, nor between 3D and flat design. Whether they become popular is simply a natural shift in social preference. Through their own learning, agents generate differentiated individual aesthetics, and through insights brought by socialization, they complete product design. After that, Vibly will also coordinate the entire production process by requesting humans. For example, it may request humans to evaluate the material of samples or conduct due diligence on factories participating in bidding.</p>
<p>The emergence of Vibly means that AI will not only bring layoffs; it can also create new forms of employment on a broader scale.</p>
<h2><a name="p-39474-progress-5" class="anchor" href="#p-39474-progress-5" aria-label="Heading link"></a>Progress</h2>
<h3><a name="p-39474-current-progress-6" class="anchor" href="#p-39474-current-progress-6" aria-label="Heading link"></a>Current Progress</h3>
<p>We have now launched the <a href="https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc-lumen.vibly.network#/explorer" rel="noopener nofollow ugc">Phase 0 testnet</a>, Lumen. The overall protocol, workflow, agent client, chain product, and related components have all been completed.</p>
<ul>
<li>
<p><a href="https://vibly.network/" rel="noopener nofollow ugc">Vibly Website</a>: the official Vibly website.</p>
</li>
<li>
<p><a href="https://console.vibly.network/" rel="noopener nofollow ugc">Console</a>: a console for humans to observe agent behavior and network status. It also includes management functions such as staking, creating organizations, joining as an agent, and claiming rewards. You can currently observe the initial collaboration among agents on the testnet.</p>
</li>
<li>
<p><a href="https://library.vibly.network/" rel="noopener nofollow ugc">Library</a>: a site for viewing all artifacts generated by the agent network. It already includes basic documents produced by the VibMath project.</p>
</li>
<li>
<p><a href="https://docs.vibly.network/" rel="noopener nofollow ugc">Documentation</a>: an initial documentation site, which is expected to require significant optimization.</p>
</li>
</ul>
<h3><a name="p-39474-next-stage-plan-7" class="anchor" href="#p-39474-next-stage-plan-7" aria-label="Heading link"></a>Next Stage Plan</h3>
<p>In the current stage, we made extensive use of Vib Code and discovered many issues during the process. The main task of this stage is refactoring and optimization, including the refactoring of Vibly-Chain and the protocol layer. After completion, we will launch the official testnet.</p>
<h3><a name="p-39474-related-resources-8" class="anchor" href="#p-39474-related-resources-8" aria-label="Heading link"></a>Related Resources</h3>
<ul>
<li>
<p><a href="https://archelabs.org/" rel="noopener nofollow ugc">ArcheLabs Website</a></p>
</li>
<li>
<p><a href="https://github.com/ArcheLabs" rel="noopener nofollow ugc">GitHub</a></p>
</li>
</ul>

robert

Vibly Phase 0 Testnet Lumen Is Live: Building an AI Agent Social Collaboration Network

<p>Thanks for enabling Discussions. Since you mentioned that the categories can be extended as needed, I think it would be useful to add an <strong>RFCs</strong> discussion category.</p>
<p>I did a quick pass over the open issues and found several that are really RFC-style discussions rather than concrete implementation issues:</p>
<ul>
<li><a href="https://github.com/paritytech/polkadot-sdk/issues/12224" rel="noopener nofollow ugc">#12224 RFC: Permissionless Authorized Dispatch for <code>pallet-whitelist</code></a></li>
<li><a href="https://github.com/paritytech/polkadot-sdk/issues/11199" rel="noopener nofollow ugc">#11199 RFC: Deferred Dispatch for <code>pallet-whitelist</code></a></li>
<li><a href="https://github.com/paritytech/polkadot-sdk/issues/11100" rel="noopener nofollow ugc">#11100 RFC: Ordered Spend Payouts</a></li>
<li><a href="https://github.com/paritytech/polkadot-sdk/issues/11099" rel="noopener nofollow ugc">#11099 RFC: Convert Entity/Pallet Origin to Signed Origin</a></li>
<li><a href="https://github.com/paritytech/polkadot-sdk/issues/4715" rel="noopener nofollow ugc">#4715 RFC: Treasury API for Cross-Chain Transfers</a></li>
<li><a href="https://github.com/paritytech/polkadot-sdk/issues/4123" rel="noopener nofollow ugc">#4123 RFC: Meta Transaction Implementation</a></li>
<li><a href="https://github.com/paritytech/polkadot-sdk/issues/991" rel="noopener nofollow ugc">#991 RFC: everything in rust docs</a></li>
<li><a href="https://github.com/paritytech/polkadot-sdk/issues/674" rel="noopener nofollow ugc">#674 RFC: Delegation Statements</a></li>
</ul>
<p>A dedicated <strong>RFCs</strong> category would keep the issue tracker focused on actionable work, while giving design proposals and early technical discussions a more discoverable home.</p>
<p>Suggested category purpose: requests for comments, design proposals, and early technical discussions that may later become implementation issues, PRs, or formal Fellowship RFCs. Utilisation of up voting and “mark as answer” features to highlight best commentary. If there are alternative places for official RFCs, the Ideas category also makes sense for these current issues.</p>

Bastian Köcher

<p>Thanks for the feedback.</p>
<p>InterLayer takes a slightly different approach. The runtime itself is built on Substrate, with MEL (Multi-VM Execution Layer) acting as an orchestration layer above multiple execution environments.</p>
<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/4/448b42033f8e0b3a02d8424a5a052fdd191fc426.jpeg" data-download-href="/uploads/short-url/9MmPfo6P78zl1Ym1cHWF9RosxAG.jpeg?dl=1" title="1000160857" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/4/448b42033f8e0b3a02d8424a5a052fdd191fc426_2_333x500.jpeg" alt="1000160857" data-base62-sha1="9MmPfo6P78zl1Ym1cHWF9RosxAG" width="333" height="500" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/4/448b42033f8e0b3a02d8424a5a052fdd191fc426_2_333x500.jpeg, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/4/448b42033f8e0b3a02d8424a5a052fdd191fc426_2_499x750.jpeg 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/4/448b42033f8e0b3a02d8424a5a052fdd191fc426_2_666x1000.jpeg 2x" data-dominant-color="F0F0F0"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg><span class="filename">1000160857</span><span class="informations">1024×1536 172 KB</span><svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div></p>
<p>Rather than compiling Solana programs into PolkaVM, SVM is already integrated as a first-class execution environment alongside EVM, Move, CosmWasm and PolkaVM.</p>
<p>The goal is for these VMs to interoperate through MEL and shared runtime services while remaining independently executable.</p>
<p>Additionally, many of the runtime components are being designed as modular FRAME pallets, which means they can potentially be open-sourced and reused by other Substrate or PolkaVM-based chains without requiring the full InterLayer stack.</p>
<p>You can also inspect chain activity through the explorer, Polkadot.js/apps or test directly through the available RPC endpoints and scripts. I’ve updated the main post with the relevant links if you’d like to take a look.</p>
<p>I’m currently cleaning up and documenting the repositories before making them public, but I’m happy to discuss specific implementation details in the meantime.</p>

BHARATH B R 

Rust Syndicate

Looking for Honest Feedback: Am I Experiencing Edgeware Déjà Vu?

<p>I’ve been using a compatibility layer on top of smoldot as an eth-rpc → substrate translation service for testing.</p>
<aside class="onebox githubfolder" data-onebox-src="https://github.com/Baronvonbonbon/pine-rpc/tree/main">
  <header class="source">
      <img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/b/bad3e5f9ad67c1ddf145107ce7032ac1d7b22563.svg" class="site-icon" alt="" data-dominant-color="" width="32" height="32">

      <a href="https://github.com/Baronvonbonbon/pine-rpc/tree/main" target="_blank" rel="noopener nofollow ugc">github.com</a>
  </header>

  <article class="onebox-body">
    <h3><a href="https://github.com/Baronvonbonbon/pine-rpc/tree/main" target="_blank" rel="noopener nofollow ugc">GitHub - Baronvonbonbon/pine-rpc: Standalone Ethereum JSON-RPC node backed by a...</a></h3>

  <p><a href="https://github.com/Baronvonbonbon/pine-rpc/tree/main" target="_blank" rel="noopener nofollow ugc">main</a></p>

  <p><span class="label1">Standalone Ethereum JSON-RPC node backed by a smoldot light client, for pallet-revive on Polkadot Asset Hub. Run it and point ethers/hardhat/foundry/MetaMask at it. - Baronvonbonbon/pine-rpc</span></p>

  </article>

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

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

<p>If you are only trying to interact with the chain, it works in most cases. It suits my hacking needs. Fits inside of webpages too.</p>
<p>Update: I gave it its own server and repo.</p>

Reliable ETH RPC for Kusama Assethub

<p>I agree with your sentiments. The ultimate goal in my mind is a point when the end user can be fully on-chain with zero friction or awareness that they’re interacting with a blockchain system, let alone  multiple blockchain systems.</p>
<p>That goes beyond just a banking app alternative.</p>
<p>The technical feasibility of unifying everything under one roof, one app, is considerable but can be managed. Much of the technical risk might be mitigated through Polkadot’s trustless architecture at a fully scaled future state. However, regulatory and compliance risk become a bigger issue in the short term.</p>
<p>I’m in the US, so my laws are a bit different, but the primary issue I see is the regulatory requirements needed once you become a Money Services Business (MSB) if your product or business transfers value from one person or location and transfers to another person or location, and importantly - who holds control over the system performing that transfer. From my understanding, the EU is more stringent on requirements and thresholds for anti-money laundering rules, monitoring, and reporting of suspicious activity for MSBs which could become compliance nightmares for anyone operating as a source of control for the value transference system.</p>
<p>Bitcoin gets away with it because it is deemed sufficiently decentralized so as no single person or entity can be held accountable.</p>
<p>Any team that is trying to launch that kind of unified app would face the scrutiny of regulators, and face the consequences on non-compliance until a point in time when the authority control of the entire system is no longer under their power. This is not only for the ownership and custody of funds, but also for the upgradability of the software.</p>
<p>I think that is likely the point where Polkadot is feeling the most pain, right now. Technically, it is all possible. But who will be willing to assume that risk?</p>
<p>So, I think we see now how independent teams are building a small feature here, a project there, with the hopes that eventually someone will be able to tie it all together. But that is ineffective, slow, and inefficient.</p>
<p>If W3F decides to assume that risk and Parity builds the software, that could be the ramp to hand off control by reducing friction via unified interface to onboard and eventually dissolving W3F into OpenGov. Pure speculation, or course.</p>

Nixan

SubWallet+ — A Product Extension Proposal

<p>has the research / dev team considered the scenario in which most of the stake is un-bonded <em>in masse</em> once this referenda is enacted? I think the likelihood of this happening is non-negligible which will be a grave security concern for the stability of the network as a whole.</p>

Truth

Jonathan

<p>Hey there, I’ve been working on a implementation of the SCALE codec in solidity, <a href="https://github.com/LucasGrasso/solidity-scale-codec" class="inline-onebox" rel="noopener nofollow ugc">GitHub - LucasGrasso/solidity-scale-codec: An implementation of Polkadot's Scale-Codec in Solidity · GitHub</a>.<br>
It currently does not support encoding/decoding of an arbitrary pallet call, but it provides the necessary primitives for it, and encoding/decoding for XCM v5 instructions.<br>
Im interested in listening to your feedback, I think it plays nicely with the XCM precompile and can be extended to more use cases.</p>

Lucas Grasso

Bolaji Ahmad

State of Precompiles in Revive Ecosystem

<p><strong>Runtime release notification</strong></p>
<p>Hello,</p>
<p>This is to advise you that the Polkadot community is currently voting to upgrade the <a href="https://kusama.subsquare.io/referenda/651" rel="noopener nofollow ugc"><em>Kusama system</em></a> to the <a href="https://github.com/polkadot-fellows/runtimes/releases/tag/v2.3.0" rel="noopener nofollow ugc">v2.3.0 release</a>.</p>
<p>This is a major runtime upgrade that introduces a <a href="https://github.com/polkadot-fellows/runtimes/pull/1193" rel="noopener nofollow ugc">flexible minimum validator set size on Relay chains</a> and lowers the default limits to 100 validators for Kusama and 250 validators for Polkadot.</p>
<p>The projected enactment date for this runtime upgrade is around 15th June 2026.</p>
<p>Many thanks.</p>

Anaelle LTD

Runtime release notification for v2.3.0 [08.06.2026]

<p>Small update: the binary size comparison table is now updated to compare the correct thing – actual code sizes. Previous version contained a bug where we generated correct but uncompressed images with a lot of zeros.</p>
<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/9/90dcad8850c31695250673fda8a3e92270417a63.png" data-download-href="/uploads/short-url/kFvysOdrmuQfK2301sNMG2hC2Kn.png?dl=1" title="Screenshot 2026-06-08 at 21-01-21 JAR JAM Benchmark" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/9/90dcad8850c31695250673fda8a3e92270417a63_2_690x278.png" alt="Screenshot 2026-06-08 at 21-01-21 JAR JAM Benchmark" data-base62-sha1="kFvysOdrmuQfK2301sNMG2hC2Kn" width="690" height="278" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/9/90dcad8850c31695250673fda8a3e92270417a63_2_690x278.png, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/9/90dcad8850c31695250673fda8a3e92270417a63_2_1035x417.png 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/9/90dcad8850c31695250673fda8a3e92270417a63_2_1380x556.png 2x" data-dominant-color="EFF0EC"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg><span class="filename">Screenshot 2026-06-08 at 21-01-21 JAR JAM Benchmark</span><span class="informations">2014×814 87 KB</span><svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div></p>
<p>The fixed version shows an even more significant gain of PVM2. Note: <a href="https://forum.polkadot.network/t/risc-v-is-all-you-need/17804">PVM2 is standard RISC-V (+c)</a>. So this really reaffirms our conclusion – <strong>the custom PVM ISA is unnecessary and actually much worse than PVM2 (standard RISC-V)</strong>. PVM2 (standard RISC-V) beats PVM on binary size, and performance is better or equivalent.</p>

Wei Tang

Announcing PVM2: Reimagining PVM towards standard RISC-V

<p>Pretty please, post a YouTube playlist when available! <img src="https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=15" title=":slight_smile:" class="emoji" alt=":slight_smile:" loading="lazy" width="20" height="20"></p>

Pre-Web3 Summit Updates

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

Blockchain Alert Platform for Web3 | BlockPing

Encointer System Chain – Infrastructure Operations (Apr–Dec 2026)

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)

- Subscan is a tool to see what happens on Kusama.
- It will work for all of 2026.
- The community pays a small amount each month.
- If service is bad, the community can stop paying.
- The price is lower than before.

Deciding

Subscan Enterprise Explorer License - Kusama 2026 Milestone-Based Service

- Subscan is a tool that helps people see what happens on Kusama and Polkadot networks.  
- It asks for money to pay for computer servers it already used for 6 months in 2025.  
- The total request is $141,624, which will be turned into KSM coins.  
- Subscan kept its services running really well, with almost no downtime.  
- It paid for all extra work itself, so the Treasury only pays for basic costs.  
- Past proposals show this is a normal way Subscan asks for payment.

[Invoice] Subscan Explorer - Kusama 2025 Q3-Q4 SaaS Infrastructure Settlement

Executed

Runtime Upgrade 2.3

- Bloque lets people use stablecoins easily through a simple code tool.
- You can now watch real-time spending on Kusama Hub for the first time.
- They have processed over $405,000 in payments with more than 4,300 transactions.
- They are working with four fintech companies and have real customers.
- The team is asking for funding to keep growing and make their system stronger.
- They want to add support for local currencies like COP and MXN.
- Their goal is to help more companies use stablecoins for payments.

Kusama

referenda3

treasury22

discussions1394