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

Native rewards distribution protocol #102

Closed
Tracked by #84
maurolacy opened this issue Jan 6, 2025 · 0 comments · Fixed by #104
Closed
Tracked by #84

Native rewards distribution protocol #102

maurolacy opened this issue Jan 6, 2025 · 0 comments · Fixed by #104
Assignees

Comments

@maurolacy
Copy link
Contributor

maurolacy commented Jan 6, 2025

Alternatively to sending the rewards to Babylon using ICS-020 (#96), we can keep the rewards on the Consumer, for simplicity and a cleaner / simpler user experience.

At the same time, we can still make Babylon to process the distribution table across delegators; for ownership / control, commissions, etc. (Or we can do all the processing on the Consumer).

For this, we can establish a custom IBC message to send the distribution table across FPs to Babylon (instead of sending it on the Memo field of the ICS-020 transfer). And then another custom messages in the opposite direction, to send back the distribution table across delegators to the FPs. (Or send the distribution table and funds to the btc-staking contract, and process / distribute everything locally).

There's WIP for this already in the https://github.com/babylonlabs-io/babylon/tree/f/consumer-reward-distribution branch. Also, the babylon-contract InstantiationMsg has the optional transfer_info field (

pub transfer_info: Option<crate::msg::ibc::IbcTransferInfo>,
) which can be used to disable ICS-020 entirely.

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

Successfully merging a pull request may close this issue.

1 participant