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

Use sovereign accounts of sending chains to pay relayer rewards #2585

Open
svyatonik opened this issue Sep 28, 2023 · 7 comments
Open

Use sovereign accounts of sending chains to pay relayer rewards #2585

svyatonik opened this issue Sep 28, 2023 · 7 comments
Assignees

Comments

@svyatonik
Copy link
Contributor

In bridges-v1 we are using into_account_truncating on RewardsAccountParams structure to compute AccountId that will be used to pay relayer rewards.

This is not XCM-friendly. Also it means that the sending chain (e.g. asset hub) needs to maintain two accounts at bridge hub - one for paying XCM fees and another to pay relayer rewards. Let's remove RewardsAccountParams and use SA of sending chain for both purposes.

@bkontur
Copy link
Contributor

bkontur commented Sep 28, 2023

@svyatonik
Can I take it or are you working on that?
I've just added claim rewards stuff to Ro/Wo demo scripts :) paritytech/polkadot-sdk@559b954

@svyatonik
Copy link
Contributor Author

@bkontur No, I'm not working on that now - please take it if you want :)

@bkontur
Copy link
Contributor

bkontur commented Sep 28, 2023

xcm fees will be also paid from SA of asset hub on BridgeHub,
so it is ok to use the same SA account for claiming rewards?

@svyatonik
Copy link
Contributor Author

I think - it is fine. That's the point of this issue. But if you have some concerns - please share. I may be wrong here

@bkontur
Copy link
Contributor

bkontur commented Sep 28, 2023

no concerns, it simplify stuff, and it also make sense that SA of AssetHub manages rewards.
just wonder if it is ok from security-audit point of view.

@svyatonik
Copy link
Contributor Author

just wonder if it is ok from security-audit point of view.

I'm not the right person to answer that :) We may impl-then-ask or ask-then-impl. But from my PoV, I see no problems with that.

@acatangiu
Copy link
Collaborator

@bkontur let's prioritize this post initial launch and get it in a subsequent patch release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants