This SIP proposes a new system for facilitating on-chain elections.
\nThis system allows users to nominate candidates, cast votes based on participation in multiple Synthetix deployments, and distribute NFTs to the winners across an arbitrary number of EVM-compatible blockchains.
\nThe proposed system builds on learnings from Synthetix’s existing elections system, implements the latest smart contract architecture developed by Synthetix’s Core Contributors, and integrates with cutting-edge decentralized technology for reading and writing data across multiple chains. This proposal strives for simplicity and extensibility, such that voting power calculations can be easily adapted based on future governance decisions around Synthetix’s collateralization and cross-chain expansion.
\nThis system consists of a single codebase that can be deployed as a mothership or a satellite. Election results are calculated on the mothership, which transfers NFTs to the winners and sends a cross-chain message to the satellite deployments, triggering the transfer of their NFTs as well.
\nThe mothership could be deployed on OP Mainnet (to maintain parity with the current elections system), Ethereum mainnet (for maximum security), a Synthetix-specific appchain, or any other EVM-compatible blockchain.
\nThe representation of election winners as NFTs allows for direct integrations with deployments of the Synthetix protocol—as the owner of a deployment or as a configurer, which can only execute SCCPs—via a Safe Module. This module could also require approval from a Risk Council and/or implement a timelock/veto pattern. Other protocols, including existing ecosystem projects, are able to integrate with these NFTs to grant the holders special permissions or incentives as well.
\nThis system is always in one of two states:
\nAdministration Period - At the beginning of this period, anyone can call the resolve function on the mothership. NFTs are distributed to the elected nominees which have received the most votes in the previous cycle. Wormhole Queries is used to gather all of the votes cast across any satellite deployments. A cross-chain message is sent via Wormhole Messages such that the NFTs controlled by the satellite deployments are redistributed as well. Throughout the administration period, addresses can be nominated for the following election period.
Election Period - At the beginning of this period, anyone can call the commence function on the mothership. This finalizes the list of candidates, sending them to the satellites via a cross-chain message. Throughout the election period, users on any chain with a mothership or satellite deployment can cast their votes, distributing their voting power across an array of candidates.
This system allows a single codebase to be maintained for deployment across multiple chains with separate instances for each council, all managed in Synthetix V3’s deployments repository.
\nThis system could also be owned by a Safe with a custom Safe Module that includes special requirements for modifying election system configurations (i.e. “meta-governance”) like the list of registered snapshot/checkpoint contracts or period durations. A Safe Module which owns another aspect of the Synthetix protocol should enforce similar requirements for the nominateOwner functions.
The use of cross-chain messaging maximizes interoperability and resilience against cross-chain infrastructure failure. For example, an alternative architecture could involve the election winners only being recorded on the mothership, requiring a cross-chain query for any integration on another chain. This would mean integrations on other chains would fail if the cross-chain queries were unsuccessful. Instead, under this model, temporary cross-chain query downtime would only prevent voting during the outage. Also, with the proposed architecture, a failure in cross-chain message delivery could be resolved by simply calling the resolve function again.
This system is designed to be fully permissionless. There is no need for specific addresses to have elevated permissions or the creation of merkle trees off-chain. Bots will be incentivized to call createCheckpoint with ETH. Election winners will be motivated to call the resolve function as soon as possible, such that they receive NFTs. Thecommence function can be triggered automatically when the first vote is cast in the election period, if necessary. The implementation will allow for an owner address to execute upgrades specified by SIPs, though ownership of the system can be revoked in the future.
An earlier draft of this proposal involved votes only being cast on the mothership deployment, relying on Wormhole Queries to determine voting power for addresses across all chains. A major advantage to this approach would be the ability to remove snapshot/checkpoint functionality. This approach has been abandoned because the integration with Queries cannot currently rely on the availability of archive nodes to retrieve arbitrarily old state. Also, because smart accounts with the same address can have different owners across chains, it is necessary to have users cast votes on satellites.
\nOn initialization, the system can distribute the NFTs to a list of provided addresses, which also determines the total number of NFTs for the system. The configuration consists of the duration of the administration period and the election period, a list of chain IDs/addresses for all of the deployments, an array of chain IDs/addresses of the ERC-20 compliant contracts to use for calculating voting power, and whether voting power should be calculated on a linear or quadratic scale.
\nThis proposal entails the mothership being deployed on OP Mainnet and all councils using a quadratic scale, except for the Treasury Council and the Spartan Council. It is the responsibility of the snapshot/checkpoint contracts to normalize voting power (e.g. between v2 and v3 participants). For Synthetix V2X, this contract would reference the debt shares contract. For V3, this contract would reference a simple rewards distributor contract designed for this purpose.
\nAll of the following functions are only available on the mothership, unless otherwise noted:
\nnominate - During either period, any address can nominate themselves to run in the following election period. The sends a cross-chain message to syncronize this list across all deployments.withdraw - During the administration period, any nominee can remove themselves as a candidate for the following election period.createCheckpoint - During the administration period, anyone can call this function to generate a checkpoint on all of the voting power contracts. This also triggers a cross-chain message to do the same on each of the satellites. This can be called a maximum of once per week. If the system holds sufficient ETH, it pays the address calling the function a configurable amount.commence - After the duration of the administration period has expired, this function can be called by anyone to initialize a new election period. This uses Pyth’s Entropy to randomly select a timestamp from the previous administration period that will be used on the getPastVotes function. This is sent to the satellite deployments.cast - During the election period, a user can call this function with a mapping of candidates to weights (pertaining to the voting power they’d like to assign to those candidates) on a mothership or a satellite deployment. This is recorded on the chain where the vote is cast.resolve - After the duration of the election period has expired, anyone can call this function to initialize the next administration period. Wormhole Queries is used to read the total votes cast across all deployments and determine the winners. The mothership re-assigns the owners of the NFTs to the winners of the election of the system and calls Wormhole Messaging to transfer the NFTs on the satellite deployments. (Note that the NFTs cannot be transfered by their owners; only the election system may transfer them.)configure - This allows the system owner to update the configuration settings, listed below. This can also be called on satellite deployments.Relevant tests will be developed during implementation.
\nsize - The number of NFTs distributed by a particular system, only relevant on the mothership deployment.administrationDuration - The duration (in seconds) before a new election period can be initialized after resolve is called.electionDuration - The duration (in seconds) before a new administration period can be initialized after commence is called.mothership - This is the chain ID and address for the mothership deployment.satellites - This is an array of chain ID and address pairs for each satellite, only relevant on the mothership deployment.votingPowerContracts - This is an of array of addresses for ERC20Votes-compliant contracts.checkpointReward - An amount of ETH to send to the caller of createCheckpoint.Copyright and related rights waived via CC0.
"}},"pageContext":{"id":"1c41c580-ef33-5b50-8fed-08d6a87b6b38","frontmatter__sip":360,"__params":{"frontmatter__sip":"360"}}},"staticQueryHashes":[]}