Uniswap
Mechanism map
- Deflationary token
- Delegated Governance
Token functions
Deflationary token
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
Cashflow
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)
Delegated Governance
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
Conditional Action
represents the necessity of delegation of UNI tokens to self or other voter in order for them to enter the Uniswap governance process
Value capture investment profile
Governance
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.