Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unify components for Polkadot bridges #7274

Open
6 tasks
bkontur opened this issue Jan 21, 2025 · 0 comments
Open
6 tasks

Unify components for Polkadot bridges #7274

bkontur opened this issue Jan 21, 2025 · 0 comments

Comments

@bkontur
Copy link
Contributor

bkontur commented Jan 21, 2025

Description

At least P/K and Snowbridge shares some commonalities (xcm routing, congestion, dynamic fees, collecting rewards, ...) which are unnecessary implemented twice.

Trait changes:

  • ExporterFor change Option<Asset> to Assets or Option<Assets to support more fees and be aligned with SendXcm trait
  • ExportXcm - remove channel and change the order or params:
    fn validate(
     	universal_source: &mut Option<InteriorLocation>,
     	network: NetworkId,
     	destination: &mut Option<InteriorLocation>,
     	message: &mut Option<Xcm<()>>,
    ) -> SendResult<Self::Ticket>;
    
@bkontur bkontur converted this from a draft issue Jan 21, 2025
@acatangiu acatangiu changed the title Simplify/unify bridges Unify components for Polkadot bridges Jan 21, 2025
github-merge-queue bot pushed a commit that referenced this issue Feb 19, 2025
Closes: #7272
Relates to: #6578
Relates to: #7274

## Description

The PR enhances the `pallet-bridge-rewards` by making it generic over
the `RewardKind` type (previously hardcoded as `RewardsAccountParams`).
This modification allows the pallet to support multiple reward types
(e.g., P/K bridge, Snowbridge), increasing its flexibility and
applicability across various bridge scenarios.

Other pallets can register rewards using `bp_relayers::RewardLedger`,
which is implemented by the rewards pallet. The runtime can then be
configured with different mechanisms for paying/claiming rewards via
`bp_relayers::PaymentProcedure` (e.g., see the `pub struct
BridgeRewardPayer;` implementation for BridgeHubWestend).

## Follow-up  
The removed balances/rewards statistics from the complex relay (no
longer used) will eventually be reintroduced or fixed in the standalone
relayers via
paritytech/parity-bridges-common#3004 (comment).

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
Co-authored-by: Serban Iorga <serban@parity.io>
bkontur added a commit that referenced this issue Mar 3, 2025
Closes: #7272
Relates to: #6578
Relates to: #7274

The PR enhances the `pallet-bridge-rewards` by making it generic over
the `RewardKind` type (previously hardcoded as `RewardsAccountParams`).
This modification allows the pallet to support multiple reward types
(e.g., P/K bridge, Snowbridge), increasing its flexibility and
applicability across various bridge scenarios.

Other pallets can register rewards using `bp_relayers::RewardLedger`,
which is implemented by the rewards pallet. The runtime can then be
configured with different mechanisms for paying/claiming rewards via
`bp_relayers::PaymentProcedure` (e.g., see the `pub struct
BridgeRewardPayer;` implementation for BridgeHubWestend).

The removed balances/rewards statistics from the complex relay (no
longer used) will eventually be reintroduced or fixed in the standalone
relayers via
paritytech/parity-bridges-common#3004 (comment).

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
Co-authored-by: Serban Iorga <serban@parity.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

1 participant