Governance
Last updated
Last updated
Integral to achieving this mission is a decentralized governance protocol, whereby Creators and Users are individually and collectively enfranchised in decision making about protocol changes and upgrades. In the spirit of creating a community-owned and operated streaming protocol, these key actors should be empowered to shape, mend and modify underlying parameters of the Frak protocol including but not limited to:
Features and Product Evolution
Data sharing
Royalty Fees
Fee Pool Allocation
Tokenomics
Staking Rewards
Everything in Frak is governable, and all $SYBL tokens staked in the protocol automatically receives governance weight as described in section 9.2. Governance will look to present both technical and nontechnical proposals, giving all users the ability to properly voice their beliefs without needing to have a deep technical under- standing of the FRak tech stack.
By creating a framework for Users to adjust the direction of the protocol in line with their shared beliefs, Frak will curate governance to the most value-added actors, possibly tying in incentives to those who are most active.
There is a bypass process that allows both 1) proposals to be passed without broader vote if urgency requires, e.g. during active exploitation of a vulnerability in the protocol, and 2) proposals to be vetoed if they are not consistent with the philosophies outlined in this paper. This bypass capability will be controlled by a community multisig with an initial set of signers. Additional signers can be voted into place via the open community governance process. The community, at any time, can vote to remove the ability to bypass governance if they choose, and the controllers of the bypass multisig have committed to not veto said proposal when the time comes to relinquish control. The project team added this functionality to the governance process with the intention for it to be removed— it is up to the community to decide when it makes sense to take off the training wheels or whether it makes sense to have this functionality at all.
By locking the staked $FRK, Creators and Users will get higher voting power:
Locking Period | |
---|---|
coming soon
1 month
1
3 months
4
6 months
8
1 year
16
2 years
32
3 years
34