-
Notifications
You must be signed in to change notification settings - Fork 0
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
Feat/on chain accounting #40
Conversation
3666a2e
to
82e7693
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First pass - looks good to me and actually brings a lot less additional logic in than expected.
A bunch of nitpicks to disregard, but conceptually this sounds very sane.
The only thing that may not be a nitpick is we may want to leverage emitting events more, but at the end of the day we'd still need to go through historical blocks so this may be fluff?
I think we now have two ways to do off-chain accounting.
Combining both of these allows us to double check our work and flexibility for different scenarios. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM ser, only nitpicks and observations.
Add on-chain accounting for "rewards" a generic unit of account that we can use to reconcile off chain for RUNE distribution. Essentially, they act like points.
Also adds some paranoia with a non-reentrant modifier...
Only last question is should we add the ability to set the REWARD_RATE so that if we end up using these as points, and we have multiple pools as is being discussed with DFC, we can modify the REWARD_RATE to be meaningful.