shelbyd
commented
2 years ago As I'm implementing this, I'm seeing another drawback. The main way I can see to implement this (without transaction hooks from Substrate), is to snapshot all balances at important intervals. The problem is that users could send balances in between snapshots and this code would be none the wiser.
As this is yet another in the world of problems with the approach of on-chain holder rewards, I think it's time to move to opt-in staking, despite the cost of making an additional UI in the wallet.
@nikoladimitroff We may want to treat this as a larger effort now, since it will have some UI and optional features that we may want to incrementally implement. One example is showing an estimated ROI when staking to help inform the user of if it's worth it for them. I'll still start implementing the on-chain parts under this issue.
nikoladimitroff
Summary of a video call discussion:
There is concern about the performance implications of distributing tokens regularly on-chain to all users holding. The process to distribute tokens would take somewhere around 30s-60s with the current number of addresses we have. The necessary hooks do not exist to make a highly-performant version of this feature.
An alternative is opt-in staking. That would require additional UI and similar on-chain code.
A final alternative is not doing this. The main concern there is we have no mechanism to counter sell pressure when the bridge opens.
The conclusion is that I will explore options to implement the simple holder rewards on-chain with less performance problems than a naive implementation would have. If I can come up with something performant enough, then we'll go with that, otherwise, we'll continue the conversation.