Monetising governance has, so far, been a road to hell paved with good intentions. However, not recognising the productive role of POKT within the Pocket ecosystem has resulted in some of the community’s most thoughtful, pragmatic and invested contributors being excluded from governance.
Impact drives progress, so representing those deploying POKT to drive the core utility of the demand, supply, and now, liquidity sides of the network is not merely justifiable; it is necessary if we want to have a truly representative system.
Using this frame of what is impactful to Pocket, we believe we can sustainably integrate both financial and non-financial contributions into one holistic governance system for the first time. The guiding principle we hold is that governance must be earned, not bought.
By representing contributions of this type, the governance system becomes more representative of our ecosystem and perhaps counterintuitively makes the system more resistant to governance capture than before. We are excited to open the door to many old and respected faces across the community who will be recognised for the impact their deployed POKT has on the network.
Technical requirements
We propose a first iteration that recognises three productive uses of POKT with governance power within a single Staker House:
Supply-side path: a node runner or a validator staking POKT to serve relays or secure the network, represented by 40% of the power in the Staker House
Demand-side path: a Gateway transferring POKT to the DAO - via the Gateway Operator Fee (burn) - to pay for access to the POKT Network protocol on behalf of its end-user developer customer base, represented by 30% of the power in the Staker House
Liquidity provider path: a liquidity provider staking wPOKT/ETH (and/or future approved pools) to provide liquidity for the network, represented by 30% of the power in the Staker House
The total voting power of all Stakers can never be more or less than 45% of the total voting power of the DAO. To be explicit, this 45% power is distributed across Supply Stakers (40% of 45%), Demand Stakers (30% of 45%) and Liquidity Stakers (30% of 45%)
Technical specification
SUPPLY-SIDE POKT STAKER
This credential provides voting power to node runners or a validator staking POKT to serve relays or secure the network.
The requirements for the Supply-Side Stakers are:
- Valid Stake: Defined as POKT Staked > 60 Days and NOT Jailed, Paused or Unstaking
- Weight: A weighting (impact score) of the the square root of Token-weighted voting power for POKT tokens staked in the network
- Automated: YES (Credentials are issued or weights adjusted daily to reflect the Valid Stake and Weight of each node/address/wallet)
Note:
Due to the nature of the Morse protocol design, with people sometimes running 100s of nodes, the most user-friendly option is to allocate governance power based on who owns the output for the nodes to which such address relates. This means that those staking their POKT non-custodially can claim governance power for all of the nodes/validators connected to each of their output addresses. For those staking on a custodial basis, only the relevant owner of the service domain to which the custodial output address is related can claim governance power for all of the nodes/validators connected to such custodial output address.
DEMAND-SIDE POKT BURNER
This credential provides voting power to Gateways representing the Gateway Operator Fee (burn) paid for access to the POKT Network protocol on behalf of its end-user/customer base
The requirements for the Demand-Side Stakers are:
- Valid Address: We will whitelist a POKT Address from which POKT is sent to the DAO for burning
- Weight: A weighting (impact score) of the square root of aggregate fees (POKT tokens) sent to the DAO for burning in the last 30 Days
- Automated: YES (POKT only needs to be sent from the valid address for burning)
LIQUIDITY PROVIDER STAKER
This credential provides token-weighted voting power to Uniswap LP tokens representing liquidity staked in the Uniswap wPOKT/ETH liquidity pool.
The requirements for the Liquidity-Side Stakers are:
- Valid Stake: Holding wPOKT/ETH LP tokens from Uniswap
- Weight: A weighting (impact score) of the the square root of Token-weighted voting power of the Uniswap LP tokens
- Automated: YES (we can verify the number of Uniswap LP tokens staked in the wPOKT staking contract from the voter’s wallet address)
Implementation Specification
Issuance of credentials to Liquidity Providers and Demand-Side (Gateway) Stakers will be automated and captured at the voting strategy level.
The implementation and automation of the governance issuance process for Supply-Side Stakers is as follows:
- Stakers register themselves in mygateway.xyz to receive a Gateway-ID
- Stakers will visit our Issuance site (a minimal client frontend) to CLAIM their staking credential. They then go to the issuer website (The client site is a minimal frontend for the validators to claim their credential, from now on, I refer to it as the issuer site)
- Depending on your staking approach you will:
- Custodial
- Copy your Gateway ID
- Add to the DNS records:
POKT_GATEWAY_ID=copied-id
- Return to the issuer site
- Input the SERVICE-DOMAIN name and request for check
- The system checks the service domain for the Gateway ID, and calculates power of all wallets/addresses under the service domain based on POKTscan, and issues the PDA with the relevant WEIGHT
- Non-custodial
- Users connect their related POKT wallets to their Gateway ID in mygateway.xyz dashboard
- They return to the issuer site and input their Gateway ID
- The system checks for the wallets/addresses and issues a credential based on the correct WEIGHT
- Custodial
Implementation considerations
In light of the inherent complexity in the Morse protocol design, as well as the number of paths within the staker class, and the implementation requirements attaching to what is a valid stake and what voting power ultimately accrues to each stake via the automations, safety of the overall governance design is of paramount importance.
Consequently, we will not launch any path until we have reached a sufficiently high level of confidence that the testing process is producing the intended results and that all edge cases are satisfactorily covered off. This may result in a launching each of the 3 paths individually, sequentially or concurrently to ensure the resilience of each path as well as the staker house as a whole. We will provide further updates on the specific implementation specification for the first iteration, along with the Metagovernance specification at the beginning of January.
FAQ
Are token holders not staking in the network via these three paths represented? No. No governance power is provided to speculative HODLers. Only those deploying productive capital via the staking paths are represented.
How is my total weight/stake captured? Each wallet address is connected to a Gateway ID, which combines your governance power across wallets/stake as per the specific implementation details above. Once wallets are connected to your Gateway ID all weight/stake is captured automatically.
How does this avoid POKT becoming a plutocracy? Stake, or token weighted voting, only has 45% of the total governance power in the DAO. By definition, it is a minority power in the DAO. The Metagovernance specification will further define the limits of this power, to be shared in January.
We look forward to everyone’s input in helping us refine and implement this new Staker class successfully. Please do share your questions and feedback here for consideration and discussion.