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
Just to make it a little easier for people to read them?
---------
Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
When doing #80 I got confused and updated the wrong action (which uses
the same dependency).
This one updates the RFC action for the cron job
---
When a RFC closes after the last run, it will comment on the open PR (if
it is still open) that the RFC has been closed and how to trigger the
bot to merge the PR.
If it is succesfull, we can automate it to simply close the PRs without
human input.
### Miscellaneous changes
- Also, updated cron job to run at mid day and at end of the day so we
can capture new RFCs more often.
- `v0.1.1` also has a fix for a problem with LFS files not being
downloaded by the GitHub Actions that was discovered and fixed in
paritytech/rfc-action#37 by @rzadp.
This includes https://github.com/paritytech/rfc-action/pull/34 which
takes into consideration successful RFCs.
When a RFC closed after the last run, it will comment on the open PR (if
it is still open) that the RFC has been closed and how to trigger the
bot to merge the PR.
If it is succesfull, we can automate it to simply close the PRs without
human input.
Also, updated actions/create-github-app-token to latest (version
`1.8.1`)
Changed the time to run **every day at 12:00** (UTC)
Updated the version to 0.0.8 which fixes the bug with the referenda url
comment being wrongly formatted
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.
Added RFC Cron job which will iterate over existing referendas and post
a link to them in the open Pull Requests.
This resolvespolkadot-fellows/RFCs#57
Every time it iterates, it looks for referendas that have been submitted
_after_ the time of the last run, to stop itself from posting duplicated
comments.
It is set to run every day at 12, and it can also be triggered manually.
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.
polka.dom
