UN
Uniswap
Mechanism map
- Deflationary token
- Delegated Governance
Upon passing of the corresponding proposal, 16.7% of all newly generated fees (for 0.3% and 1% fee levels; 25% for 0.01% and 0.05% fee levels instead) are going into protocol fees instead of LP fees. Protocol fees will finance buybacks of UNI tokens, which are then burnt in order to generate a deflationary appreciation.
Value drivers
represents the deflationary appreciation from the buyback-and-burn scheme
Should the Uniswap proposal 25881 be accepted, a portion of swap fees that are presently accorded to LPs (namely, 16.7% of LP fees) will instead be accorded to the protocol; these protocol fees will be used to buy and burn UNI tokens, engendering an indirect cash flow for all UNI holders in the form of continuous deflation.
[2] = ƒ(token_minted, token_extant, token_burnt)
Represents value derived from directly or indirectly influencing the decision-making in the Uniswap DAO by delegating the voting power (without UNI alienation) to a suitable representative or voting manually instead.
Value drivers
represents the necessity of delegation of UNI tokens to self or other voter in order for them to enter the Uniswap governance process
In order to delegate votes, users invoke the delegate function of the Uniswap token contract. Delegations are total and therefore do not restrict token mobility.
Uniswap proposals go through a multi-stage procedure, with proposing being gated behind a 1e6 delegated UNI threshold (note that the first two steps do not constitute publishing a proposal). First, an RFC (request for comment) proposal is submitted to the Uniswap governance forum to be discussed over a period at least a week long. Thereafter, a temp check voting is held on the Uniswap snapshot with a 1e7 vote quorum requirement and a simple majority resolution. The voting period for the temp check is five days long. Finally, a governance proposal is formally submitted to the appropriate portal, and a simple-majority voting with 4e7 UNI quorum. Once a proposal is created, it undergoes a two-day review (for example, to check custom calldata of a technically complicated proposal), a seven-day voting period, and a two-day timelock before the calldata is executed.
All voting is done off-chain.
In order for UNI tokens to be usable for voting, they must be delegated by the holder; they may either be self-delegated or be delegated to a different voter that the holder feels would best represent their interests in the governance process. It must be noted that delegation must be carried out before the start of the voting period for it to count in the corresponding proposal.
Also note that delegation does not restrict the mobility of UNI tokens.
[81] = binary
represents governance value that originates from indirectly influencing the outcome of Uniswap governance decisions through voting power delegation
Delegation of voting power to a voter other than self does in itself constitute a governance action through implicit casting of votes (or, equivalently, explicit boosting of a given voting bloc, which a delegate represents).
[31] = ƒ([81], delegate_vote_allocation, user_strategy_representation)
Represents participation in protocol governance (voting) to acquire governance value
Should the user self-delegate, realisation of governance value ceases being automatic and must instead proceed through manual voting.
[82] = binary
represents governance value that originates from influencing the outcome of Uniswap governance decisions through direct voting
Represents governance value originating from influencing protocol-wise decisions. The decisions are broad in scope and pertain to both distribution of the community treasury and application of protocol-wide upgrades.
[32] = ƒ([82], delegate_vote_allocation, user_strategy_representation)