{"componentChunkName":"component---src-pages-sips-sip-markdown-remark-frontmatter-sip-tsx","path":"/sips/sip-168/","result":{"data":{"markdownRemark":{"fileAbsolutePath":"/vercel/path0/content/sips/sip-168.md","frontmatter":{"sip":168,"sccp":null,"title":"Governance Participation Program","network":"Ethereum","author":"Andy T CF (@andytcf), MiLLiΞ (@Milli3E)","type":"Governance","proposal":null,"implementor":null,"release":null,"created":"2021-07-19T00:00:00.000Z","updated":null,"status":"Implemented"},"html":"

Implementor

\n

Andy T CF (@andytcf)

\n

Simple Summary

\n\n

This proposal aims to encourage governance participation from the Synthetix community and ecosystem abroad. Token holders that have values aligned with that of the Ambassadors will now be rewarded with SNX for delegating their votes for the duration of an Epoch (initially set at 28 days), to the Ambassador Multi-sig.

\n

The rewards will be sponsored by the sDAO, which will be 32,000 SNX for the epoch.

\n

Abstract

\n\n

If this proposal passes, the following will be implemented

\n\n

Motivation

\n\n

According to the ambassadorDAO mandate, one of their main responsibilities is partaking in ecosystem-wide governance systems on behalf of the Synthetix community. As of writing this SIP, we have seen major voter apathy in terms of delegating to the ambassadorDAO multisig in all the protocols, except for AAVE.

\n

This Governance Participation Program would reward community members who wish to express their preferences with an ecosystem proposal, but are discouraged by the concentration of token-votes that some top delegates have and the high quorum thresholds for proposals. The participation program encourages these community members to express their votes through their like-minded Synthetix Ambassadors, and in doing so would be eligible to receive SNX, which in turn may be used for further coordination and governance participation in the various Synthetix DAOs.

\n

In order to fulfil the main responsibility of the ambassadorDAO, the aDAO requires a substantial amount of delegated voting power as made apparent in protocols such as Uniswap (which requires 2.5M - 10M tokens to create a proposal).

\n

The goal of this SIP is to:

\n\n

Specification

\n\n

Overview

\n\n

On the approval of this SIP, the program start and end dates will be specified by the Synthetix Ambassadors.

\n

During the program epoch, users will be encouraged to delegate their Uniswap (UNI) tokens to the Synthetix Ambassador's Multisig via the ambassadors dApp (ambassadors.synthetix.io).

\n

After this epoch ends, a script will be run in order to analysis all the delegation activity that happened with the program epoch and assign pro-rata rewards to users who have successfully participated in the program.

\n

(If a user was to withdraw their delegation before the end of an epoch, they will not be eligible for any rewards within that epoch)

\n

Users will then be able to claim their allocated SNX rewards from the Merkle Distributor contract.

\n

Rationale

\n\n

Currently users can delegate their tokens to the ambassadorDAO by calling the delegate() function on the Uniswap ERC20 but considering the high threshold of tokens needed for creating a proposal on the Uniswap Governance system and the high concentration of UNI among top delegates, there is a lack of voter expression in critical ecosystem proposals.

\n

This was the catalyst to consider providing incentives to delegates in order to gather more voting power for the ambassadorDAO multisig in order to participate in governance proposals that are critical to the Synthetix ecosystem.

\n

Originally, we had discussed the usage of a vault, whereby users must transfer their ownership into the vault which will then delegate to the ambassadorDAO.

\n

After some feasibility research, this method was not ideal as it:

\n\n

Instead, the use of a script to analyse block-chain events was considered to be the solution that was least frictional as it does not require users to send their funds out of their wallets and the events are already being emitted by the UNI ERC20 contracts.

\n

By using a merkle distributor, both the uploading of the claim-data and also claiming process are highly efficient and require minimal gas usage benefitting both the protocolDAO and also the users who participate in the program.

\n

Technical Specification

\n\n

Script

\n

There will be a script written that takes advantage of ether.js events API to map through all the DelegateChanged events emitted by the UNI ERC20, the events are then analysed to map out the:

\n\n

From the resulting data gathered from the script, we generate a merkle root containing their pro-rata rewards to upload to our merkle distributor contract

\n

Merkle Distributor

\n

The Merkle Distributor is a highly efficient data structure that is able to store the reward data generated from the script above via a merkle root. The total SNX rewards will be deposited in the contract and users will be able to interact with the contract using their wallet address to see if their wallet is eligible to claim rewards and how many they can claim.

\n

They will then be able to send a transaction to the contract which will then release the allocated SNX rewards to them.

\n

Pro-rata rewards

\n

The rewards allocated to the program participants will be affected by:

\n\n

Test Cases

\n
Starting Conditions
\n
    \n
  1. startBlock = 0;
    2. \n
  2. endBlock = 193_710;
    3. \n
  3. startingBalance = 1_000_000
    4. \n
  4. participants = 4
    5. \n
  5. delegatorOne (A) = 50_000 UNI
    6. \n
  6. delegatorTwo (B) = 2_500 UNI
    7. \n
  7. delegatorThree (C) = 10_000 UNI
    8. \n
  8. delegatorFour (D) = 2_000_000 UNI
    9. \n
  9. totalRewards = 32000
    10. \n
  10. rewardsPerBlock (RPB) = 32000/193710 (totalRewards/blocksLeft)
    11. \n
\n
Sequences of events
\n
    \n
  1. A delegates their entire balance at Block 100
    2. \n
  2. B delegates their entire balance at Block 1000
    3. \n
  3. A un-delegates their entire balance at Block 20_000
    4. \n
  4. C delegates their entire balance at Block 32_000
    5. \n
  5. B undelegates their entire balance at Block 100_000
    6. \n
  6. A delegates their entire balance at Block 140_000
    7. \n
  7. D delegates their entire balance at Block 165_000
    8. \n
\n
Calculations
\n

On the first event

\n

A is the only one in the pool, they receive the 100% (50000/50000) of the RPB for 900 blocks (1000 - 100)

\n

On the second event

\n

A owns 50000/52500 of the RPB for 19_000 blocks

\n

B owns 2500/52500 of the RPB for 19_000 blocks

\n

On the third event

\n

A is slashed and their accumulated rewards are added back to the remainingRewards

\n

B is the only one in the pool, they receive the 100% (2500/2500) of the RPB for 12_000 blocks (32_000 - 20_000)

\n

On the fourth event

\n

B owns 2500/12500 of the RPB for 68_000 blocks

\n

C owns 10000/12500 of the RPB for 68_000 blocks

\n

On the fifth event

\n

B is slashed and their accumulated rewards are added back to the remainingRewards

\n

C is the only one in the pool, they receive 100% (10000/10000) of the RPB for 40_000 blocks

\n

On the sixth event

\n

C owns 10000/60000 of the RPB for 25_000 blocks\nA owns 50000/60000 of the RPB for 25_000 blocks

\n

On the seventh event

\n

C owns 10000/2060000 of the RPB for 28_710 blocks\nA owns 50000/2060000 of the RPB for 28_710 blocks\nD owns 2000000/2060000 of the RPB for 28_710 blocks

\n

Configurable Values (Via SCCP)

\n\n

N/A

\n

Copyright

\n

Copyright and related rights waived via CC0.

"}},"pageContext":{"id":"51bb51af-ec3d-574a-9e8f-1bbf09868841","frontmatter__sip":168,"__params":{"frontmatter__sip":"168"}}},"staticQueryHashes":[]}