Governance
Last updated
Was this helpful?
Last updated
Was this helpful?
The Nexus DAO is a decentralised collective of ZBU token holders and contributors who work together to shape the future of the protocol through a structured governance process. This community-driven model enables participants to propose, discuss, and vote on critical changes, guiding the evolution of the protocol and aligning with the collective goals of its members.
Nexus' governance process is structured so that the protocol remains decentralised, secure, and adaptable. The lifecycle of a proposal is carefully designed to allow community members to present ideas, vote on them, and execute approved changes through a transparent and structured process.
Governance Forum The proposal process begins with an idea introduced to the Nexus Governance Forum. This is where initial discussions take place and feedback is gathered. The community helps refine the proposal before moving to the next stage.
Temp Check (Snapshot Voting) After discussion, the proposal proceeds to a TEMP CHECK via the Nexus Snapshot Space. This informal vote gauges community sentiment. TEMP CHECK votes are non-binding but help determine if there is sufficient interest in moving forward. Proposals in this stage do not require detailed technical specifics.
RFC (Request for Final Comments) If the TEMP CHECK passes, the proposal moves to the RFC stage, where it undergoes more formal scrutiny. Service providers and community members contribute detailed feedback on how the proposal would impact the protocol, preparing it for the IP stage. RFC voting also occurs on the Nexus Snapshot Space.
IP (Improvement Proposal) The IP stage is where the proposal becomes a formal, onchain submission. It includes two parts: metadata (stored on IPFS) and the contract payload. These are submitted through Nexus' governance contracts, primarily on the Ethereum Mainnet.
Voting Once submitted, the IP enters a PENDING status before becoming ACTIVE for voting. Voting is conducted onchain through Nexus governance contracts. A proposal succeeds if it meets quorum and vote differential requirements. If these thresholds aren’t met, the proposal fails.
Execution A successful proposal moves to the execution phase, where it is enacted via Nexus' governance infrastructure. Depending on the type of proposal, a timelock delay (either one day or 7 days) is imposed before the changes are implemented.
Off-chain votes are used to measure community sentiment during the early stages of proposal development (Temp Checks and RFCs). These non-binding votes take place on Snapshot and last for three days, allowing token holders to participate without transaction fees.
Once a proposal reaches the IP stage, onchain voting is required. Token holders, delegates, or delegators vote on proposals using their ZBU tokens. The process is secured through various governance interfaces.
Since voting can occur on multiple networks, this can create limitations for smart contract wallets that only exist on one network. To accommodate this, governance interfaces can be used to setup voting representatives, which allows a separate voting address to be designated for each network.
Nexus has predefined frameworks for common types of proposals, simplifying the governance process:
Asset Onboarding Framework: Standardized lifecycle for onboarding new assets to the protocol, providing a structured process for risk assessments, and community discussions.
New Chain Deployment Framework: Guidelines for deploying Nexus Market on new blockchains, covering security audits, liquidity considerations, and governance approval to support safe and effective multi-chain expansion.
Emission Manager Framework: Simplified process for adding emission admins to reserves, improving the management of liquidity incentives.
Caps Update Framework: Direct-to-IP process for adjusting caps or freezing reserves, allowing quicker governance actions to respond to market risks while maintaining protocol stability and liquidity constraints.
Direct to IP Framework: Similar to the Caps Update Framework, but broader in scope, allows certain governance actions to bypass TEMP CHECK & RFC stages, requiring only an RFC forum post before AIP creation.
These frameworks streamline governance and allow the community to focus on more complex issues while maintaining the protocol's security and adaptability.
Delegates are entrusted with voting power by other community members or through self-delegation. They actively participate in governance by voting on proposals on behalf of those who have delegated their voting rights. Some delegates are compensated through the Orbit program for their contributions.
Delegators are community members who hold ZBU tokens but choose to delegate their voting power to another individual or entity. This allows them to have their interests represented in governance without directly participating in every vote.
Contributors dedicate time and resources to the Nexus DAO by engaging in working groups, completing bounties, building on the protocol, or working through grants. These efforts help maintain and improve the Nexus ecosystem.
Service providers offer essential services to the protocol, such as risk management, financial oversight, security, and development.
The Nexus Community Guardians are a group of community-elected signers authorized to execute limited emergency protections.
The Aave Guardians have responsibilities divided between two multi-signature wallets, with roles and signers listed below.
Protocol Emergency Guardian
The Protocol Emergency Guardian is a 5 of 9 multi-signature wallet consisting of the following community-elected signers:
Chaos Labs (risk service provider)
Llamarisk (risk service provider)
Karpatkey (finance service provider)
Certora (security service provider)
Tokenlogic (finance service provider)
BGD Labs (development service provider)
ACI (growth and business development service provider)
Ezr3al (Aave DAO delegate)
Stable Labs (Aave DAO delegate)
Governance Emergency Guardian
The Governance Emergency Guardian is tasked to protect the Aave Protocol against potential governance takeovers by having the ability to “veto” an onchain payload if it is deemed malicious.
The Governance Emergency Guardian is a 5 of 9 multi-signature wallet consisting of the following community-elected signers:
Seb (Zapper)
Mounir (Paraswap)
Gavi Galloway (Standard Crypto)
Nenad (Defi Saver)
Fernando (Balancer)
Roger (Chainlink community)
Mariano Conti (DeFi OG)
Marin (Lido)
Certora (security service provider)
The Protocol Emergency Guardian is the holder of the role for Aave protocol markets and failsafe emergency actor for cross-chain messaging in Emergency Mode.
Stewards have delegated responsibility over specific protocol parameters, allowing the DAO to quickly respond to market changes. Stewards manage areas such as the GHO stablecoin and liquidity parameters. This system streamlines governance by reducing the need for frequent votes on minor adjustments, promoting efficiency. The source code for GHO Steward contracts can be found on .