-
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: interface and data structures for Collator Power Pallet #53
Conversation
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.
I'd suggest to revisit this section to rewind the logic and how it matches with logic defined here, in this pr. Plus take a look into the power actor and after that maybe discuss more the approach before the implementation. I think some my comments here should bright some light as well.
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.
There is a need to address general economic question about pledging, staking and slashing.
Then, who and when delegates the storage power should be more easily answered.
@@ -0,0 +1,97 @@ | |||
# Overall Power Pallet Flow | |||
|
|||
## Glossary |
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.
Since we are using mono repo for our work, the glossary could be made in a separate, higher-level document to keep terminology consistent across the project.
This has been descoped because of the #61 |
Description
Take a look at the
DESIGN.md
file, it's all in there.Important points for reviewers
This is first of many PRs of the implementation for #18 .
Here I wanted to give an overall idea, without tests, benchmarks and so on.
Basically DESIGN = ideas + interfaces + data structures.