This RFC proposes a change to the extrinsic format to incorporate a new transaction type, the "general" transaction.
-"General" transactions, a new type of transaction that this RFC aims to support, are transactions which obey the runtime's extensions and have according extension data yet do not have hard-coded signatures. They are first described in Extrinsic Horizon and supported in 3685. They enable users to authorize origins in new, more flexible ways (e.g. ZK proofs, mutations over pre-authenticated origins). As of now, all transactions are limited to the account signing model for origin authorization and any additional origin changes happen in extrinsic logic, which cannot leverage the validation process of extensions.
An example of a use case for such an extension would be sponsoring the transaction fee for some other user. A new extension would be put in place to verify that a part of the initial payload was signed by the author under who the extrinsic should run and change the origin, but the payment for the whole transaction should be handled under a sponsor's account. A POC for this can be found in 3712.
The new "general" transaction type would coexist with both current transaction types for a while and, therefore, the current number of supported transaction types, capped at 2, is insufficient. A new extrinsic type must be introduced alongside the current signed and unsigned types. Currently, an encoded extrinsic's first byte indicate the type of extrinsic using the most significant bit - 0 for unsigned, 1 for signed - and the 7 following bits indicate the extrinsic format version, which has been equal to 4 for a long time.
By taking one bit from the extrinsic format version encoding, we can support 2 additional extrinsic types while also having a minimal impact on our capability to extend and change the extrinsic format in the future.
-
- Runtime users
- Runtime devs
@@ -5492,14 +5435,14 @@ nodes: [[[2, 3], [4, 5]], [0, 1]]
| Authors | Alex Gheorghe (alexggh) |
-
+
Extend the DHT authority discovery records with a signed creation time, so that nodes can determine which record is newer and always decide to prefer the newer records to the old ones.
-
+
Currently, we use the Kademlia DHT for storing records regarding the p2p address of an authority discovery key, the problem is that if the nodes decide to change its PeerId/Network key it will publish a new record, however because of the distributed and replicated nature of the DHT there is no way to tell which record is newer so both old PeerId and the new PeerId will live in the network until the old one expires(36h), that creates all sort of problem and leads to the node changing its address not being properly connected for up to 36h.
After this RFC, nodes are extended to decide to keep the new record and propagate the new record to nodes that have the old record stored, so in the end all the nodes will converge faster to the new record(in the order of minutes, not 36h)
Implementation of the rfc: https://github.com/paritytech/polkadot-sdk/pull/3786.
Current issue without this enhacement: https://github.com/paritytech/polkadot-sdk/issues/3673
-
+
Polkadot node developers.
This RFC heavily relies on the functionalities of the Kademlia DHT already in use by Polkadot.
@@ -5597,19 +5540,19 @@ in order to speed up the time until all nodes have the newest record, nodes can
| Authors | Jonas Gehrlein & Alistair Stewart |
-
+
This RFC proposes a flexible unbonding mechanism for tokens that are locked from staking on the Relay Chain (DOT/KSM), aiming to enhance user convenience without compromising system security.
Locking tokens for staking ensures that Polkadot is able to slash tokens backing misbehaving validators. With changing the locking period, we still need to make sure that Polkadot can slash enough tokens to deter misbehaviour. This means that not all tokens can be unbonded immediately, however we can still allow some tokens to be unbonded quickly.
The new mechanism leads to a signficantly reduced unbonding time on average, by queuing up new unbonding requests and scaling their unbonding duration relative to the size of the queue. New requests are executed with a minimum of 2 days, when the queue is comparatively empty, to the conventional 28 days, if the sum of requests (in terms of stake) exceed some threshold. In scenarios between these two bounds, the unbonding duration scales proportionately. The new mechanism will never be worse than the current fixed 28 days.
In this document we also present an empirical analysis by retrospectively fitting the proposed mechanism to the historic unbonding timeline and show that the average unbonding duration would drastically reduce, while still being sensitive to large unbonding events. Additionally, we discuss implications for UI, UX, and conviction voting.
Note: Our proposition solely focuses on the locks imposed from staking. Other locks, such as governance, remain unchanged. Also, this mechanism should not be confused with the already existing feature of FastUnstake, which lets users unstake tokens immediately that have not received rewards for 28 days or longer.
As an initial step to gauge its effectiveness and stability, it is recommended to implement and test this model on Kusama before considering its integration into Polkadot, with appropriate adjustments to the parameters. In the following, however, we limit our discussion to Polkadot.
-
+
Polkadot has one of the longest unbonding periods among all Proof-of-Stake protocols, because security is the most important goal. Staking on Polkadot is still attractive compared to other protocols because of its above-average staking APY. However the long unbonding period harms usability and deters potential participants that want to contribute to the security of the network.
The current length of the unbonding period imposes significant costs for any entity that even wants to perform basic tasks such as a reorganization / consolidation of their stashes, or updating their private key infrastructure. It also limits participation of users that have a large preference for liquidity.
The combination of long unbonding periods and high returns has lead to the proliferation of liquid staking, where parachains or centralised exchanges offer users their staked tokens before the 28 days unbonding period is over either in original DOT/KSM form or derivative tokens. Liquid staking is harmless if few tokens are involved but it could result in many validators being selected by a few entities if a large fraction of DOTs were involved. This may lead to centralization (see here for more discussion on threats of liquid staking) and an opportunity for attacks.
The new mechanism greatly increases the competitiveness of Polkadot, while maintaining sufficient security.
-
+
- Every DOT/KSM token holder
@@ -5724,14 +5667,14 @@ The analysis can be reproduced or changed to other parameters using
+
This RFC proposes a change to the extrinsic format to include a transaction extension version.
-
+
The extrinsic format supports to be extended with transaction extensions. These transaction extensions are runtime specific and can be different per chain. Each transaction extension can add data to the extrinsic itself or extend the signed payload.
This means that adding a transaction extension is breaking the chain specific extrinsic format. A recent example was the introduction of the CheckMetadatHash to Polkadot and all its system chains.
As the extension was adding one byte to the extrinsic, it broke a lot of tooling. By introducing an extra version for the transaction extensions it will be possible to introduce changes to these transaction extensions while still being backwards compatible.
Based on the version of the transaction extensions, each chain runtime could decode the extrinsic correctly and also create the correct signed payload.
-
+
- Runtime users
- Runtime devs
@@ -5808,14 +5751,14 @@ old extrinsic format and decoded by the runtime.
| Authors | Adrian Catangiu |
-
+
This RFC proposes a new instruction that provides a way to initiate on remote chains, asset transfers which
transfer multiple types (teleports, local-reserve, destination-reserve) of assets, using XCM alone.
The currently existing instructions are too opinionated and force each XCM asset transfer to a single
transfer type (teleport, local-reserve, destination-reserve). This results in inability to combine different
types of transfers in single transfer which results in overall poor UX when trying to move assets across
chains.
-
+
XCM is the de-facto cross-chain messaging protocol within the Polkadot ecosystem, and cross-chain
assets transfers is one of its main use-cases. Unfortunately, in its current spec, it does not support
initiating on a remote chain, one or more transfers that combine assets with different transfer types.
@@ -5837,7 +5780,7 @@ For example, allows single XCM program execution to transfer multiple assets fro
Kusama Asset Hub, over the bridge through Polkadot Asset Hub with final destination ParaP on Polkadot.
With current XCM, we are limited to doing multiple independent transfers for each individual hop in order to
move both "interesting" assets, but also "supporting" assets (used to pay fees).
-
+
- Runtime users
- Runtime devs
@@ -6098,10 +6041,10 @@ Such conversion attempts will explicitly fail.
| Authors | Adrian Catangiu |
-
+
The Transact XCM instruction currently forces the user to set a specific maximum weight allowed to the inner call and then also pay for that much weight regardless of how much the call actually needs in practice.
This RFC proposes improving the usability of Transact by removing that parameter and instead get and charge the actual weight of the inner call from its dispatch info on the remote chain.
-
+
The UX of using Transact is poor because of having to guess/estimate the require_weight_at_most weight used by the inner call on the target.
We've seen multiple Transact on-chain failures caused by guessing wrong values for this require_weight_at_most even though the rest of the XCM program would have worked.
In practice, this parameter only adds UX overhead with no real practical value. Use cases fall in one of two categories:
@@ -6114,7 +6057,7 @@ weight limit parameter.
We've had multiple OpenGov root/whitelisted_caller proposals initiated by core-devs completely or partially fail
because of incorrect configuration of require_weight_at_most parameter. This is a strong indication that the
instruction is hard to use.
-
+
- Runtime Users,
- Runtime Devs,
@@ -6191,13 +6134,13 @@ both this new version and the old. In both cases, an "attacker" can do
| Authors | Andrei Sandu |
-
+
Elastic scaling is not resilient against griefing attacks without a way for a PoV (Proof of Validity)
to commit to the particular core index it was intended for. This RFC proposes a way to include
core index information in the candidate commitments and the CandidateDescriptor data structure
in a backward compatible way. Additionally, it proposes the addition of a SessionIndex field in
the CandidateDescriptor to make dispute resolution more secure and robust.
-
+
This RFC proposes a way to solve two different problems:
- For Elastic Scaling, it prevents anyone who has acquired a valid collation to DoS the parachain
@@ -6212,7 +6155,7 @@ dispute. The dispute may concern a relay chain block not yet imported by a
validator. In this case, validators can safely assume the session index refers to the session
the candidate has appeared in, otherwise, the chain would have rejected the candidate.
-
+
- Polkadot core developers.
- Cumulus node developers.
@@ -6458,7 +6401,7 @@ by using the version field of the descriptor introduced in this RFC
| Authors | Francisco Aguirre |
-
+
XCM already handles execution fees in an effective and efficient manner using the BuyExecution instruction.
However, other types of fees are not handled as effectively -- for example, delivery fees.
Fees exist that can't be measured using Weight -- as execution fees can -- so a new method should be thought up for those cases.
@@ -6467,7 +6410,7 @@ This RFC proposes making the fee handling system simpler and more general, by do
- Adding a
fees register
- Deprecating
BuyExecution and adding a new instruction PayFees with new semantics to ultimately replace it.
-
+
Execution fees are handled correctly by XCM right now.
However, the addition of extra fees, like for message delivery, result in awkward ways of integrating them into the XCVM implementation.
This is because these types of fees are not included in the language.
@@ -6475,7 +6418,7 @@ The standard should have a way to correctly deal with these implementation speci
The new instruction moves the specified amount of fees from the holding register to a dedicated fees register that the XCVM can use in flexible ways depending on its implementation.
The XCVM implementation is free to use these fees to pay for execution fees, transport fees, or any other type of fee that might be necessary.
This moves the specifics of fees further away from the XCM standard, and more into the actual underlying XCVM implementation, which is a good thing.
-
+
- Runtime Users
- Runtime Devs
@@ -6569,12 +6512,12 @@ In practice, the deprecated BuyExecution needs to be slowly rolled
| Authors | Francisco Aguirre |
-
+
A previous XCM RFC (https://github.com/polkadot-fellows/xcm-format/pull/37) introduced a SetAssetClaimer instruction.
This idea of instructing the XCVM to change some implementation-specific behavior is useful.
In order to generalize this mechanism, this RFC introduces a new instruction SetHints
and makes the SetAssetClaimer be just one of many possible execution hints.
-
+
There is a need for specifying how certain implementation-specific things should behave.
Things like who can claim the assets or what can be done instead of trapping assets.
Another idea for a hint:
@@ -6582,7 +6525,7 @@ Another idea for a hint:
AssetForFees: to signify to the executor what asset the user prefers to use for fees.LeftoverAssetsDestination: for depositing leftover assets to a destination instead of trapping them
-
+
- Runtime devs
- Wallets
@@ -6662,13 +6605,13 @@ You only need to specify the hints you want in one single instruction at the top
| Authors | |
-
+
This RFC aims to remove the NetworkIds of Westend and Rococo, arguing that testnets shouldn't go in the language.
-
+
We've already seen the plans to phase out Rococo and Paseo has appeared.
Instead of constantly changing the testnets included in the language, we should favor specifying them via their genesis hash,
using NetworkId::ByGenesis.
-
+
- Runtime devs
- Wallets
@@ -6730,11 +6673,11 @@ using NetworkId::ByGenesis.
| Authors | Adrian Catangiu |
-
+
XCM programs generated by the InitiateAssetTransfer instruction shall have the option to carry over the original origin all the way to the final destination. They shall do so by internally making use of AliasOrigin or ClearOrigin depending on given parameters.
This allows asset transfers to retain their original origin even across multiple hops.
Ecosystem chains would have to change their trusted aliasing rules to effectively make use of this feature.
-
+
Currently, all XCM asset transfer instructions ultimately clear the origin in the remote XCM message by use of the ClearOrigin instruction. This is done for security considerations to ensure that subsequent (user-controlled) instructions cannot command the authority of the sending chain.
The problem with this approach is that it limits what can be achieved on remote chains through XCM. Most XCM operations require having an origin, and following any asset transfer the origin is lost, meaning not much can be done other than depositing the transferred assets to some local account or transferring them onward to another chain.
For example, we cannot transfer some funds for buying execution, then do a Transact (all in the same XCM message).
@@ -6742,7 +6685,7 @@ using NetworkId::ByGenesis.
Transact XCM programs today require a two step process:
And we want to be able to do it using a single XCM program.
-
+
Runtime Users, Runtime Devs, wallets, cross-chain dApps.
In the case of XCM programs going from source-chain directly to dest-chain without an intermediary hop, we can enable scenarios such as above by using the AliasOrigin instruction instead of the ClearOrigin instruction.
@@ -6853,13 +6796,13 @@ Following the same logic, the existing DepositReserveAsset, I
| Authors | Bastian Köcher |
-
+
The code of a runtime is stored in its own state, and when performing a runtime upgrade, this code is replaced. The new runtime can contain runtime migrations that adapt the state to the state layout as defined by the runtime code. This runtime migration is executed when building the first block with the new runtime code. Anything that interacts with the runtime state uses the state layout as defined by the runtime code. So, when trying to load something from the state in the block that applied the runtime upgrade, it will use the new state layout but will decode the data from the non-migrated state. In the worst case, the data is incorrectly decoded, which may lead to crashes or halting of the chain.
This RFC proposes to store the new runtime code under a different storage key when applying a runtime upgrade. This way, all the off-chain logic can still load the old runtime code under the default storage key and decode the state correctly. The block producer is then required to use this new runtime code to build the next block. While building the next block, the runtime is executing the migrations and moves the new runtime code to the default runtime code location. So, the runtime code found under the default location is always the correct one to decode the state from which the runtime code was loaded.
-
+
While the issue of having undecodable state only exists for the one block in which the runtime upgrade was applied, it still impacts anything that reads state data, like block explorers, UIs, nodes, etc. For block explorers, the issue mainly results in indexing invalid data and UIs may show invalid data to the user. For nodes, reading incorrect data may lead to a performance degradation of the network. There are also ways to prevent certain decoding issues from happening, but it requires that developers are aware of this issue and also requires introducing extra code, which could introduce further bugs down the line.
So, this RFC tries to solve these issues by fixing the underlying problem of having temporary undecodable state.
-
+
- Relay chain/Parachain node developers
- Relay chain/Parachain node operators
@@ -6924,9 +6867,9 @@ For Polkadot/Kusama this means that also the parachain nodes need to be running
| Authors | Daniel Shiposha |
-
+
This RFC proposes a metadata format for XCM-identifiable assets (i.e., for fungible/non-fungible collections and non-fungible tokens) and a set of instructions to communicate it across chains.
-
+
Currently, there is no way to communicate metadata of an asset (or an asset instance) via XCM.
The ability to query and modify the metadata is useful for two kinds of entities:
@@ -6946,7 +6889,7 @@ For Polkadot/Kusama this means that also the parachain nodes need to be running
Besides metadata modification, the ability to read it is also valuable. On-chain logic can interpret the NFT metadata, i.e., the metadata could have not only the media meaning but also a utility function within a consensus system. Currently, such a way of using NFT metadata is possible only within one consensus system. This RFC proposes making it possible between different systems via XCM so different chains can fetch and analyze the asset metadata from other chains.
-
+
Runtime users, Runtime devs, Cross-chain dApps, Wallets.
The Asset Metadata is information bound to an asset class (fungible or NFT collection) or an asset instance (an NFT).
@@ -7154,9 +7097,9 @@ This RFC proposes to use the Undefined variant of a collection iden
| Authors | Bryan Chen, Jiyuan Zheng |
-
+
This proposal introduces PVQ (PolkaVM Query), a unified query interface that bridges different chain runtime implementations and client tools/UIs. PVQ provides an extension-based system where runtime developers can expose chain-specific functionality through standardized interfaces, while allowing client-side developers to perform custom computations on the data through PolkaVM programs. By abstracting away concrete implementations across chains and supporting both off-chain and cross-chain scenarios, PVQ aims to reduce code duplication and development complexity while maintaining flexibility for custom use cases.
-
+
In Substrate, runtime APIs facilitate off-chain clients in reading the state of the consensus system.
However, the APIs defined and implemented by individual chains often fall short of meeting the diverse requirements of client-side developers.
For example, client-side developers may want some aggregated data from multiple pallets, or apply various custom transformations on the raw data.
@@ -7191,7 +7134,7 @@ As a result, client-side developers frequently resort to directly accessing stor
-
+
- Runtime Developers
- Tools/UI Developers
@@ -7563,12 +7506,12 @@ PVQ does not conflict with them, and it can take advantage of these Pallet View
| Authors | s0me0ne-unkn0wn (13WGadgNgqSjiGQvfhimw9pX26mvGdYQ6XgrjPANSEDRoGMt) |
-
+
This RFC proposes a change that makes it possible to identify types of compressed blobs stored on-chain, as well as used off-chain, without the need for decompression.
-
+
Currently, a compressed blob does not give any idea of what's inside because the only thing that can be inside, according to the spec, is Wasm. In reality, other blob types are already being used, and more are to come. Apart from being error-prone by itself, the current approach does not allow to properly route the blob through the execution paths before its decompression, which will result in suboptimal implementations when more blob types are used. Thus, it is necessary to introduce a mechanism allowing to identify the blob type without decompressing it.
This proposal is intended to support future work enabling Polkadot to execute PolkaVM and, more generally, other-than-Wasm parachain runtimes, and allow developers to introduce arbitrary compression methods seamlessly in the future.
-
+
Node developers are the main stakeholders for this proposal. It also creates a foundation on which parachain runtime developers will build.
@@ -7650,9 +7593,9 @@ PVQ does not conflict with them, and it can take advantage of these Pallet View
| Authors | ordian |
-
+
This RFC proposes changes to the erasure coding algorithm and the method for computing the erasure root on Polkadot to improve performance of both processes.
-
+
The Data Availability (DA) Layer in Polkadot provides a foundation for
shared security, enabling Approval Checkers and Collators to download
Proofs-of-Validity (PoV) for security and liveness purposes respectively.
@@ -7669,7 +7612,7 @@ The proposed change is orthogonal to RFC-47 and can be used in conjunction with
collator nodes), we propose bundling another performance-enhancing breaking
change that addresses the CPU bottleneck in the erasure coding process, but using
a separate node feature (NodeFeatures part of HostConfiguration) for its activation.
-
+
- Infrastructure providers (operators of validator/collator nodes)
will need to upgrade their client version in a timely manner
@@ -7731,6 +7674,63 @@ faster deployment for most parachains but would add complexity.
- Using ZK proofs to eliminate the need for re-encoding data to verify correct encoding
- Removing the requirement for collators to compute the erasure root for the collator protocol
+(source)
+Table of Contents
+
+
+ | |
|---|
+| Start Date | 20th May 2025 |
+| Description | This RFC proposes burning 80% of transaction fees on the Relay Chain and all its system parachains, adding to the existing deflationary capacity. |
+| Authors | Jonas Gehrlein |
+
+
This RFC proposes burning 80% of transaction fees accrued on Polkadot’s Relay Chain and, more significantly, on all its system parachains. The remaining 20% would continue to incentivize Validators (on the Relay Chain) and Collators (on system parachains) for including transactions. The 80:20 split is motivated by preserving the incentives for Validators, which are crucial for the security of the network, while establishing a consistent fee policy across the Relay Chain and all system parachains.
+
+-
+
On the Relay Chain, the change simply redirects the share that currently goes to the Treasury toward burning. Given the move toward a minimal Relay ratified by RFC0032, a change to the fee policy will likely be symbolic for the future, but contributes to overall coherence.
+
+-
+
On system parachains, the Collator share would be reduced from 100% to 20%, with 80% burned. Since the rewards of Collators do not significantly contribute to the shared security model, this adjustment should not negatively affect the network's integrity.
+
+
+This proposal extends the system's deflationary direction and is enabling direct value capture for DOT holders of an overall increased activity on the network.
+
+Historically, transaction fees on both the Relay Chain and the system parachains (with a few exceptions) have been relatively low. This is by design—Polkadot is built to scale and offer low-cost transactions. While this principle remains unchanged, growing network activity could still result in a meaningful accumulation of fees over time.
+Implementing this RFC ensures that potentially increasing activity manifesting in more fees is captured for all token holders. It further aligns the way that the network is handling fees (such as from transactions or for coretime usage) is handled. The arguments in support of this are close to those outlined in RFC0010. Specifically, burning transaction fees has the following benefits:
+
+System parachains do not participate in open-market bidding for coretime. Instead, they are granted a special status through governance, allowing them to consume network resources without explicitly paying for them. Burning transaction fees serves as a simple and effective way to compensate for the revenue that would otherwise have been generated on the open market.
+
+By burning the transaction fees, the system effectively reduces the token supply and thereby increase the scarcity of the native token. This deflationary pressure can increase the token's long-term value and ensures that the value captured is translated equally to all existing token holders.
+This proposal requires only minimal code changes, making it inexpensive to implement, yet it introduces a consistent policy for handling transaction fees across the network. Crucially, it positions Polkadot for a future where fee burning could serve as a counterweight to an otherwise inflationary token model, ensuring that value generated by network usage is returned to all DOT holders.
+
+
+-
+
All DOT Token Holders: Benefit from reduced supply and direct value capture as network usage increases.
+
+-
+
System Parachain Collators: This proposal effectively reduces the income currently earned by system parachain Collators. However, the impact on the status-quo is negligible, as fees earned by Collators have been minimal (around $1,300 monthly across all system parachains with data between November 2024 and April 2025). The vast majority of their compensation comes from Treasury reimbursements handled through bounties. As such, we do not expect this change to have any meaningful effect on Collator incentives or behavior.
+
+-
+
Validators: Remain unaffected, as their rewards stay unchanged.
+
+
+
+Some system parachains may accept other assets deemed sufficient for transaction fees. This has no implication for this proposal as the asset conversion pallet ensures that DOT is ultimately used to pay for the fees, which can be burned.
(source)
Table of Contents
diff --git a/proposed/0000-pre-elves_soft.html b/proposed/0000-pre-elves_soft.html
index 70cb4ae..42d5dd7 100644
--- a/proposed/0000-pre-elves_soft.html
+++ b/proposed/0000-pre-elves_soft.html
@@ -90,7 +90,7 @@
diff --git a/proposed/0000-rewards.html b/proposed/0000-rewards.html
index e3817fb..90c5794 100644
--- a/proposed/0000-rewards.html
+++ b/proposed/0000-rewards.html
@@ -90,7 +90,7 @@
diff --git a/proposed/0017-coretime-market-redesign.html b/proposed/0017-coretime-market-redesign.html
index a7a983f..c801778 100644
--- a/proposed/0017-coretime-market-redesign.html
+++ b/proposed/0017-coretime-market-redesign.html
@@ -90,7 +90,7 @@
diff --git a/proposed/0145-remove-unnecessary-allocator-usage.html b/proposed/0145-remove-unnecessary-allocator-usage.html
index 4425e2e..3686a9b 100644
--- a/proposed/0145-remove-unnecessary-allocator-usage.html
+++ b/proposed/0145-remove-unnecessary-allocator-usage.html
@@ -90,7 +90,7 @@
@@ -463,7 +463,7 @@ The ext_crypto_ed25519_public_key_version_1 function writes the pub
-
+
@@ -477,7 +477,7 @@ The ext_crypto_ed25519_public_key_version_1 function writes the pub
-
+