In this RFC, I aim to present several suggestions for fostering a closer
integration of the different Coretime markets and for enabling a more
systematic alignment with market forces.
---------
Co-authored-by: Dónal Murray <donalm@seadanda.dev>
Looking for feedback.
## Summary
This proposal introduces PVQ (PolkaVM Query), which aims to serve as an
intermediary layer between different chain runtime implementations and
tools/UIs, to provide a unified interface for cross-chain queries.
## Related Discussions
https://forum.polkadot.network/t/wasm-view-functions/1045
## PoC implementations
https://github.com/open-web3-stack/XCQ
This is a refined version of the XCM Asset Metadata RFC.
This PR supersedes the
[PR](https://github.com/polkadot-fellows/xcm-format/pull/50) opened in
the xcm-format repository following the migration of XCM RFCs to the
Fellowship RFCs.
## Summary
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.
---------
Co-authored-by: Adrian Catangiu <adrian@parity.io>
Moved from https://github.com/polkadot-fellows/xcm-format/pull/53.
The idea is to extend the current XCM fee mechanism to support in
principle delivery fees, but potentially other types of fees as well.
This is accomplished by having two additions:
- `PayFees` instruction
- A `fees` register, where fees go and stay there until the end of
execution. Crucially, separate from the `holding` register
---------
Co-authored-by: Adrian Catangiu <adrian@parity.io>
Moved from https://github.com/polkadot-fellows/xcm-format/pull/59.
This RFC proposes a framework for specifying "execution hints", much
like [window hints in
GLFW](https://www.glfw.org/docs/3.3/window_guide.html#window_hints).
The first one is `AssetClaimer`, that allows the user to specify who can
claim trapped assets resulting from that program execution. That was an
instruction already approved and targeted at XCMv5. This RFC proposes to
move it to this hints mechanism.
Another potential hint is `LeftoverAssetsDestination`, which, when set,
would send all leftover assets to a particular location instead of
trapping. This additional hint is not covered by the RFC. It could be
proposed in a new one.
This is a continuation of
https://github.com/polkadot-fellows/xcm-format/pull/63 following the
migration of XCM RFCs to this repo.
# Summary
This RFC proposes a new instruction that provides a way to initiate
asset transfers which transfer multiple types (teleports, local-reserve,
destination-reserve) of assets, on remote chains 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.
# Example usage
```rust
// pay remote fees with ROCs
let remote_fees = Some(
AssetTransferFilter::ReserveWithdraw(
AssetFilter::Wild(AllOf { id: rocs_id.into(), fun: WildFungibility::Fungible })
)
);
// XCM to be executed locally
let xcm = Xcm::<penpal_runtime::RuntimeCall>(vec![
// Withdraw both ROCs and PENs from origin account
WithdrawAsset(assets.clone().into()),
// Execute the transfers while paying remote fees with ROCs
InitiateAssetsTransfer {
dest: local_asset_hub,
assets: vec![
// ROCs are reserve-withdrawn on AHR
ReserveWithdraw(rocs.into()),
// PENs are teleported to AHR
Teleport(pens.into()),
],
remote_fees,
remote_xcm: xcm_on_ahr,
},
]);
```
I also have a [proof-of-concept
implementation](https://github.com/acatangiu/polkadot-sdk/blob/1738f8eebd33d87c9c09c7a6bcd7c42fc1a8aa9e/polkadot/xcm/xcm-executor/src/lib.rs#L717C4-L831C6)
and a [proof-of-concept asset transfer
test](https://github.com/acatangiu/polkadot-sdk/blob/1738f8eebd33d87c9c09c7a6bcd7c42fc1a8aa9e/cumulus/parachains/integration-tests/emulated/tests/bridges/bridge-hub-rococo/src/tests/asset_transfers.rs#L484C1-L489C60),
transferring 2 different types of assets across 3 chains.
We are proposing an unbonding queue for Relay Chain tokens to
significantly reduce the expected unbonding time. The queue would still
maintain sufficient stake accountability to mitigate the profitability
of LRAs.
---------
Co-authored-by: Gonçalo Pestana <g6pestana@gmail.com>
Co-authored-by: ordian <write@reusable.software>
This is a continuation of
https://github.com/polkadot-fellows/xcm-format/pull/55 following the
migration of XCM RFCs to this repo.
# Summary
Remove the `require_weight_at_most: Weight` parameter of the Transact
instruction.
# Motivation
The UX of using Transact is not great, and one part of the problem is
guesstimating this require_weight_at_most.
We've seen multiple Transacts on-chain failures caused by the
"incorrect" use or the parameter. In practice, this parameter only adds
UX overhead. Use cases fall in one of two categories:
1. Unpaid execution of Transacts - in these cases the
require_weight_at_most is not really useful, caller doesn't have to pay
for it, and on the call site it either fits the block or not;
2. Paid execution of single Transact - the weight to be spent by the
Transact is already covered by the BuyExecution 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 in its current form is hard to use.
---------
Signed-off-by: Adrian Catangiu <adrian@parity.io>
This RFC proposes to introduce a transaction extensions version. It is
proposed to piggyback on
[RFC84](https://github.com/paritytech/polkadot-sdk/issues/2415) to not
require a new extrinsic format version. With this RFC it will be
possible to change the transaction extensions without breaking the
extrinsic format of a chain and thus, staying backwards compatible.
---------
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
This RFC outlines the core components and procedures of Sassafras
consensus protocol.
---
This RFC does not cover the following topics:
- Implementation details necessary for interoperability: structure of
the on-chain storage, host functions and runtime API.
- Deployment strategies, especially in the context of already existing
blockchain networks
- Parameters required for the zk-SNARK (SRS).
- Networking protocol to deliver tickets to relayers.
These (and probably other) topics are fairly complex and somewhat
independent of the core protocol. They should be the subject of
separate, dedicated RFCs for proper exploration and discussion.
---
[Rendered](https://github.com/davxy/polkadot-fellows-rfcs/blob/sassafras-consensus-rfc/text/0026-sassafras-consensus.md)
Reference implementation tracking issue:
https://github.com/paritytech/polkadot-sdk/issues/41
With this RFC I want to start a discussion whether to burn the revenues
from Coretime sales or to send them to Treasury. I give some arguments
why burning might be favorable.
This RFC proposes adding `system_version` and remove `state_version`
from `RuntimeVersion` object. This makes it possible to use
`StateVersion::V1` for both Storage and Extrinsic root derivations
https://github.com/paritytech/polkadot-sdk/pull/1462 has been open for a
while and is now well-reviewed. Opening an RFC since it introduces a new
host function that is relevant for parachains and light-clients.
The Fellowship Manifesto states that members should receive a monthly
allowance on par with gross income in OECD countries. This RFC proposes
concrete amounts.
This RFC proposes a means for Polkadot stakeholders to ratify a new
collective. The Fellowship should agree to add new collectives to the
Collectives parachain runtime that pass the given process.
* create file
* add body of rfc
* update rfc number
* rename file
* remove old
* make file
* first draft
* tweaks
* pubsub
* migration text tweak
* add discussions on identity, governance, and staking
* nits
* commit more to balances on staking para
* add RFC number
* review changes
* add architecture, resource allocation, and kusama's role
* init new RFC
* first version written
* add more detail
* Update text/0022-adopt-encointer-runtime.md
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Update text/0022-adopt-encointer-runtime.md
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Update text/0022-adopt-encointer-runtime.md
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Update text/0022-adopt-encointer-runtime.md
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Update text/0022-adopt-encointer-runtime.md
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Update text/0022-adopt-encointer-runtime.md
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* add legal entity with author
* More precise stakeholder description for fellowship
* extend description about updates, reviews and audits
* Typo
* crates must be on crates.io
---------
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
polka.dom