Each project deployed in the Ubiquity ecosystem will have three distinct phases. Durations are case-by-case, but we anticipate one month, three months, and then perpetual for the following phases, respectively:
- Rapid prototyping period - the very beginning of each product. During this phase, the Ubiquity team will have full access to deploy changes and hotfixes to the product as needed. Furthermore, the core development team will have mint access to uAR tokens to finance these changes. These tokens are redeemable for dollars only when uAD price is above 1.00, serving as a proxy for ecosystem health. The team will only be able to realize their compensation when the ecosystem is functional.
- Cool off period - during this period, changes to the product would still exclusively be deployed by the Ubiquity team. However, all changes would be discussed and vetted by the community via a discussion on the project’s forums.
- Fully decentralized governance - the process described below
Proposal suggestion and implementation flow
Voting during this phase will be done based on voting power. Voting power is determined by:
- UBQ is the number of governance tokens staked in the governance module
- D is a duration multiplier, based on how long the tokens are staked for
The staking duration multiplier is defined by the following curve, with the minimum staking duration being 1 week and the maximum 208 weeks.
The process for suggesting and implementing a proposal will closely follow UniSwap’s governance process, with tweaked parameters and an additional Tender step.
Phase 1: Temperature Check
The purpose of the Temperature Check is to determine if there is sufficient will to make changes to the status quo.
To create a Temperature Check:
- Community member (A) asks a general, non-biased question to the community forum about a potential change (example: “Should uAD rewards for coupon holders be increased by 10%?”).
- Voters vote on-chain to indicate their interest in bringing it forward to the next stage. Voting lasts 5 days, or until 5% of the voting pool backs the proposal.
If the proposal gains 5% of the pool backing, then it moves to the next stage - consensus check.
Phase 2: Consensus Check
The purpose of the Consensus Check is to establish formal discussion around a potential proposal.
To create a Consensus Check:
Community member (A) uses feedback from the Temperature Check post and creates a new poll that covers the options which have gained support. This poll can either be binary or multiple-choice but should include the option “Make no change” or its equivalent.
Community member (A) creates a new topic in the forum titled “Consensus Check — [Your Title Here].” This will alert the community that this topic has already passed Temperature Check. Any topics beginning with Consensus Check that have not passed Temperature Check should be immediately removed by community moderators. Community member (A) makes sure that the discussion thread links to the:
- Original Temperature check thread
- Original Temperature check poll
- The new poll for the Consensus check
Community member (A):
- Reaches out to their network to build support for the proposal.
- Discusses the proposal and solicit delegates to vote on it.
- Responds to questions on the Consensus Check topic.
- Shares their viewpoint, although tries to remain as impartial as possible.
The proposal should also include an implementation standard for the suggestion:
- What companies/individuals are eligible for the implementation process
- Is a POC required
- Is the POC partially or fully funded by the treasury?
- What is the maximum budget for the implementation?
- What are the deadlines?
- For submitting a tender proposal
- For the final deliverables
- What is the penalty for not delivering the project:
- Within the deadlines
- With a sufficiently good scope
Voting lasts 5 days. Whichever option has the majority of votes wins, and can be included in a Tender for Stage 3. A 67% pool quorum of the voting pool is required for the vote to be considered valid.
If the option “Make no change” wins, the Consensus Check topic should be closed by community moderators.
Phase 3: Tender
Each passed Consensus Check will be subject to a public tender for implementation. The tender begins after the Consensus check, and applicants can submit their proposals for implementation. Those parameters include (but are not limited to):
- Bit for the implementation
- Success criteria
- Request for penalty amount subsidy
- Request for audit subsidy
This process as long as defined in the Consensus check and at the end of the period, a vote is initiated. The vote lasts for 5 days:
- Any proposal which collects more than 25% of the votes is subject to financial compensation for the PoC / application (if such was explicitly specified in the consensus check parameters).
- The proposals are selected and randed in order of votes collected. The top proposal is the winner and becomes the “Implementation party”.
The implementation party has 2 days to stake any penalty deposits as defined in the Consensus check. If the implementation party cannot provide this amount on their own, it can be delegated to them (penalty amount subsidy), by everyone who voted for their application (taken in proportional amounts to the vote).
If the implementation party does not satisfy the above conditions, within the time period, the contract is awarded to the second runner up. This process continues until one of the applicants satisfies the above conditions. If none of the applicants satisfies the condition, then step 3 repeats all over. If step 3 fails a second time, the whole process reverts to phase 2, where Community member (A) should suggest new proposal parameters.
Phase 4: Governance Proposal
Phase 4 — Governance Proposal — is the final step of the governance process. The proposal should be based on the winning outcome from the Consensus Check and the winner of the Tender and can consist of one or multiple actions, up to a maximum of 10 actions per proposal.
To create a Governance Proposal:
The implementation party writes the code for the proposal. All proposed code should be audited by a professional auditor. This auditing process could be paid or reimbursed by the community treasury (audit subsidy)
Once the proposal is active, a 5 day voting period is started. Ongoing discussions can take place in the community forum. If the proposal passes successfully, a two-day timelock will follow before the proposed code is executed. If the proposal does not pass, one of two things happen:
- The community can vote on a time extension in order for the implementation party to re-calibrate its proposal
- The community rejects the proposal, any penalties defined are slashed from the implementation party’s deposit and the Tender process begins anew
Governance token: An ERC-20 token that designates the weight of a user’s voting rights. The more Governance tokens a user has in their wallet, the more weight their delegation or vote on a proposal holds.
Delegation: Governance tokens holders cannot vote or create proposals until they delegate their voting rights to an address. Delegation can be given to one address at a time, including the holder’s own address. Note that delegation does not lock tokens; it simply adds votes to the chosen delegation address.
Governance Proposal: A proposal is a contract that is executed by the governance contract through timelock. Proposals are stored in the “proposals” mapping of the Governor smart contract. All proposals are subject to a 5-day voting period. If the proposer does not maintain their vote weight balance throughout the voting period, the proposal may be canceled by anyone.
Quorum: For a vote to pass, at least 67% of all delegated tokens must vote in the affirmative. The purpose of this quorum is to ensure that the only measures that pass have adequate voter participation.
Voting: Users can vote for or against single proposals once they have voting rights delegated to their address. Votes can be cast while a proposal is in the “Active” state. If the majority of voters vote for a proposal, the proposal may be queued in the Timelock.
Timelock: All governance actions are delayed for a minimum of 2 days by the timelock contract before they can be executed.