-
Notifications
You must be signed in to change notification settings - Fork 171
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
FRC for Delegation of Authority for F3 Parameter Setting #1112
base: master
Are you sure you want to change the base?
Conversation
This is the FRC accompanying #1102
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.
Posting verbal comments I got from @Kubuxu on 2025-01-31
Co-authored-by: Masih H. Derkani <m@derkani.org> Co-authored-by: Phi-rjan <orjan.roren@gmail.com>
Thanks @Kubuxu @masih and @rjan90 for the review. I believe I have incorporated all feedback. Feel free to look at the diff from bdb3d15 onwards. At this point, I'll mark this as ready for review and link it to the discussion. Once we have a PR showing Lotus integration, I'll followup with Venus and Forest to make sure they provide their keys and have a tracking item for integrating. |
Please take FRC number 0099.
|
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.
- Key ownership is communicated by each implementation team adding their keys to this FRC via PR in the Implementation section.
How do you want to handle this? Merge the PR and have the teams PR their keys into the text or PR into your PR before merging?
I am thinking to have other teams merge into this PR and we merge it all when all the keys are here and the other TODOs are filled in. |
This is the FRC accompanying #1102
This FRC proposes introducing an on-chain smart contract that can manage F3 parameters dynamically. This contract would be owned/controlled through a multi-signature mechanism requiring consensus from all three major Filecoin implementations (Lotus, Forest, and Venus). The contract would allow for a one-time parameter update based on mainnet passive test results, effectively combining what would have been two network upgrades into one while maintaining security through multiple stakeholder approval, full onchain transparency, and built-in time delays for community review.