# Overview ### What Is VeVote? **VeVote** is VeChain’s official decentralized governance system. It allows **Validators** and holders of eligible **Stargate NFTs** (both owned or delegated) to vote on proposals that shape the ecosystem’s future. From protocol upgrades to community initiatives, VeVote ensures decision-making is **transparent**, **fair**, and **decentralised**. *** ### Who Can Vote? You’re eligible to vote if: * ✅ You **own** or **manage** one or many Stargate NFT * ✅ You **endorse** a VeChainThor Validator * ✅ Any **combination** of the above Supported Stargate NFT levels include **MjolnirX**, **ThunderX**, **StrengthX**, **VeThorX**, **Mjolnir**, **Thunder**, **Strength**, **Flash**, **Lightning**, and **Dawn**. > **Delegation**: Stargate NFT holders can assign their voting rights to another wallet—enabling trusted representatives to participate in governance. See [here](https://docs.stargate.vechain.org/overview/nft-management) for more info. > VeChain Node holders must migrate their legacy nodes to the Stargate NFT contract to be eligible for voting. See [here](https://docs.stargate.vechain.org/overview/nft-management) for migration info. > Authority Master Nodes must transition from PoA to PoS to be eligible to vote after Hayabusa. See [here](https://docs.stargate.vechain.org/overview/nft-management) for migration info. *** ### How Voting Works VeVote uses **standard voting** with the following options: * **FOR** * **AGAINST** * **ABSTAIN** Your total voting power is applied entirely to the option you select. {% hint style="warning" %} #### 🚨 **One Vote Per Proposal**: Each wallet can only vote **once** per proposal. You **cannot change or re-submit** your vote once it has been cast. {% endhint %} *** ### Summary VeVote enables: * On-chain governance with off-chain execution * Upgradeable and modular smart contract architecture It’s a flexible governance tool purpose-built for the VeChain ecosystem. # Voting Power ## How Stargate NFTs and Validator Endorsement affect Voting Power VeVote uses a **weighted voting system** based on your Stargate NFT level or if you endorse a VeChainThor Validator. Larger, higher-level NFTs grant **more influence**. Voting power is calculated using **Voting Units**, determined by any combination of: 1. The tier and VET stake of your Stargate NFT 2. Your endorsement of a VeChainThor Validator > For simplicity, throughout the rest of this documentation, we will refer to all eligible voting power sources (Stargate NFT tiers or Validator endorsement) collectively as *"Nodes."* #### Step 1: Base Voting Power Every node is compared to the minimum staked VET requirement of the lowest Stargate NFT tier -**Dawn (10,000 VET)** - which equals **1 voting unit**: ``` Base Voting Power = Required Staked VET to hold your Node ÷ 10,000 ``` Example: Thunder X (5,600,000 VET) ``` 5,600,000 ÷ 10,000 = 560 base units ``` #### Step 2: Apply the Multiplier Each node has a multiplier. Thunder X uses **1.5x**: ``` Final Voting Power = Base Units × Multiplier = 560 × 1.5 = 840 voting units ``` > Dev Note: In the smart contract, multipliers are stored as whole numbers scaled by 100 (e.g. 150 = 1.5). ### Holding Multiple Nodes If you hold—or are delegated—more than one Node, your **total voting power** is the sum of all their voting units. For example: * Thunder X = 840 units * Strength X = 240 units Total = **1,080 voting units** > When you vote, your combined power is automatically calculated from all eligible Nodes—both owned and delegated—based on the snapshot. You can only vote once, and VeVote determines which Nodes are available to you and applies their combined voting power behind the scenes. ## Voting Power Table | Node Type | VET Required | Multiplier | Voting Units | | ----------- | ------------ | ---------- | ------------ | | Validator | 25,000,000 | 2.0× | 5,000 | | Mjolnir X | 15,600,000 | 1.5× | 2,340 | | Thunder X | 5,600,000 | 1.5× | 840 | | Strength X | 1,600,000 | 1.5× | 240 | | VeThor X | 600,000 | 1.5× | 90 | | Mjolnir | 15,000,000 | 1.0× | 1,500 | | Thunder | 5,000,000 | 1.0× | 500 | | Strength | 1,000,000 | 1.0× | 100 | | Flash\* | 200,000 | 1.0× | 20 | | Lightning\* | 50,000 | 1.0× | 5 | | Dawn\* | 10,000 | 1.0× | 1 | > Note: the voting units in the smart contract are scaled by 100 to avoid underflow when determining total vote weight. ## When Is Voting Power Counted? Voting power is calculated at the **moment you cast your vote**, not at the proposal’s start. Although a startBlock snapshot defines when voting begins, your voting power depends on your live status during the voting period. This includes: * Stargate NFTs you currently hold * Stargate NFTs currently delegated to you * Whether your address is listed as an Authority Master Node endorser > **Important Notes**: > > * NFTs minted after voting begins can **not** be used to vote. > * NFTs burned, transferred, or undelegated before voting will not count. > * Eligibility and voting strength are assessed in real time when you vote — not at startBlock. ## Voting Power Delegation via NFT Management VeVote supports **on-chain delegation** of voting rights using Stargate NFT **node management**. This feature allows an NFT owner to assign another wallet—called a **Node Manager**—to vote **on their behalf** in governance proposals. See [Stargate](https://stargate.vechain.org/) for more info. ### Delegated Governance When a **Node Manager** is assigned, they gain full **voting power** for the NFT(s) they manage. This means they can: * Cast votes in active VeVote proposals * Use the voting units associated with the NFT (based on its level and multiplier) * Participate in governance as if they were the NFT owner > Delegated voting power is applied **immediately** once a manager is set. > Only the NFT owner can assign or revoke a manager. The manager does not need to accept the role. # Proposal Lifecycle Each proposal moves through the following stages: ### Support phase * An improvement gets suggested by any user in Discourse * Gets community endorsement * May end up in a VIP ### Proposal creation * The proposal gets created through a user with the `WHITELISTED_ROLE` * Includes: title, IPFS description, and general vote details ### Promotion phase * The proposal is in pending state, is registered but not live yet * Delayed start gives time for spreading awareness about the proposal, and to get more voting power or add managers ### Approval phase #### 1. Start * Voting begins at the specified `startBlock` * Snapshot taken for voter eligibility and power * Each Node can vote once #### 2. **End** * Voting ends after `voteDuration` * No more votes can be accepted, results become locked #### 3. **Evaluation** * Results tallied * If quorum is met and and **`FOR`** votes are more than **`AGAINST`** votes → **SUCCEEDED** (Approved) * Otherwise → **DEFEATED** (Rejected) ### Execution phase * Passed proposals may be manually implemented by VeChain Foundation or others * Selected accounts can mark the proposal as Executed after the decision has become effective {% hint style="warning" %} ### **Cancellation** * Creator or other users with the `WHITELISTED_ROLE` may cancel proposals before they start * Admins may cancel proposals before they complete {% endhint %} # Quorum In VeVote, **quorum** represents the minimum level of participation required for a proposal to be considered valid. It ensures that decisions are made with sufficient involvement from the governance community. #### Current Configuration * **Quorum Threshold:** `5%` of total eligible vote weight * **Status:** Dynamically configurable via Smart Contracts #### How Quorum Works * Quorum is defined as a **percentage of the total potential vote weight**, including both: * Eligible Stargate NFT holders. * Active Authority Master Nodes. * The quorum percentage is evaluated **at the time of proposal snapshot**, not live or retroactively. #### Evaluation Time * Quorum is **evaluated at proposal end**, after the voting period closes. #### Outcome * **If quorum is reached:**\ The proposal proceeds to tally and may pass or fail based on votes. * **If quorum is not reached:**\ The proposal is automatically marked as **`DEFEATED`**, regardless of the actual votes cast. {% hint style="info" %} Status names of the platform might be different, the tags are referring to the ones available in the Smart Contracts. {% endhint %} # Proposal Creation Only users with the `WHITELISTED_ROLE` can submit proposals on-chain. To suggest a proposal: 👉 Open a thread on [Discourse](https://vechain.discourse.group/latest). You can use the same channel to get some help to: * Review your proposal * Get some endorsement * Format it correctly * Funnel it to a whitelisted member (`WHITELISTED_ROLE`) ### Create a proposal in VeVote {% hint style="info" %} The option is only available for whitelisted members. {% endhint %} To create a new proposal head to [https://vevote.vechain.org](https://vevote.vechain.org/) and connect your wallet.
If it's the first time you login, or if you do it from another browser, you will be requested to accept the platform policies (terms of use, privacy policy and cookie policy).
If you are allowed to create new proposals, you will see the **Create Proposal** button above the list of all proposals, on the right.
### Proposal creation form The proposal creation is a 2-step process: #### Step 1 Filling the following information: * Title * Description * Discourse topic * Start and end date (and time) * A header image (optional, not used at the moment)
{% hint style="info" %} Other information like **quorum** that are inherited from the platform, and not specific for the proposal. {% endhint %} #### Step 2 Preview and publish the proposal.
### Fill the Description You will find a template in the **Description** providing some sections that will act as guidelines to make the content of all proposal consistent and easier to read. Make sure to replace the content of each section with yours. Select and start typing, or use right click and select "**Paste and Match Style**" if you have something ready. This step is to make sure the format is consistent with throughout the platform.
You can proceed with the other sections in the same way.\ Once you are done, you can make the final adjustments like (i.e.) removing *Italics* if you like. {% hint style="warning" %} There are some rules the platform will check to help you avoid forgetting to fill in all the information. {% endhint %}
{% hint style="info" %} For your proposal, some sections may seem redundant. It's up to the creator to decide what to keep or change on a case-by-case. {% endhint %} #### :bulb: Delete or replace a section The platform will check the template, and may seem impossible to change it at first glance. But the creator can actually remove whole sections or create new ones. To avoid being blocked, make sure you delete content between *\[...]* (brackets included).

Example of template customization.

#### :date: Customizing the voting window One of the most essential parts of a proposal is the moment in which people can start voting, and of course, when the outcome is decided. {% hint style="warning" %} The start time of a proposal will identify the **snapshot** block, the point in time in which voting power for the proposal is considered. Buying or selling nodes after this block won't affect your voting power. {% endhint %} The time window can be customised using the controls under **Voting Calendar**. Rules do apply also for the dates: * dates can't be in the past * time between the creation and the Start time can't be less than 7 days (currently) * time between the Start and End time can't be less than 7 days (currently)
### :pencil2: Draft Proposals if you are not ready to publish, because you want to wait for a specific date or keep open the possibility of editing some details, hitting **Exit** will give you the chance to save the proposal locally as **Draft**.
{% hint style="warning" %} Only Draft proposals are editable. {% endhint %} To edit a Draft proposal, go to the landing page and select it.

Example of a Draft proposal in the landing page.

In the header you will have the choice either to Delete or Edit. Once you hit Edit, you will see again the Proposal creation for of **Step 1**, already filled with all your information.
### The Smart Contract side Proposal Creation Format: | Field | Type | Description | | -------------- | --------- | -------------------------------------- | | `description` | `string` | IPFS CID for full Markdown content | | `startBlock` | `uint256` | Block when voting starts (after delay) | | `voteDuration` | `uint256` | Duration in seconds | The format is taken care by the platform when the proposal is submitted using the portal. # Smart Contracts ## VeVote Smart Contracts Documentation This document provides a technical summary of the smart contracts that make up the VeVote governance system. It explains the architecture, roles, upgrade mechanics, use of libraries, and how contracts interact with external components. *** ### Contract Architecture VeVote is designed as a modular system using the **UUPS proxy pattern**, which separates contract logic from storage. This allows logic to be upgraded while preserving state. #### Core Contracts | Contract | Purpose | | ------------ | -------------------------------------------------------------------------------------------------- | | `VeVote.sol` | VeVote system smart contract, routes proposal and voting calls, handles access control and storage | > This contract define the high-level behavior and state management of the system. All logic is offloaded to libraries. *** ### Libraries in VeVote VeVote.sol uses a set of specialized **library contracts** to keep the logic modular, testable, and upgradable without increasing the size of the main contract. These libraries are stateless and rely on a shared storage layout defined in `VeVoteStorage.sol`. #### Why Libraries? * **Modularity** – Each library focuses on a single area of functionality (e.g. voting, timing) * **Gas Efficiency** – Smaller contract size reduces deployment and interaction costs * **Upgrade Flexibility** – Allows logic updates without touching unrelated modules * **Reusability** – Logic can be reused across governance versions #### Core Logic Libraries | Library Contract | Responsibility | | ------------------------- | ------------------------------------------------------------------------------------ | | `VeVoteVoteLogic.sol` | **Voting logic**: casting, tallying, validation | | `VeVoteProposalLogic.sol` | **Proposal creation**: input validation, role checks, setup | | `VeVoteQuorumLogic.sol` | Quorum calculation and pass/fail logic | | `VeVoteClockLogic.sol` | Time-related logic | | `VeVoteConfigurator.sol` | **Admin-only config updates**: vote durations, multipliers, external contracts, etc. | > 📌 These libraries are called via delegatecall from `VeVote.sol`, and all read/write operations interact with `VeVoteStorage.sol`. *** ### Roles & Access Control VeVote uses OpenZeppelin's `AccessControlUpgradeable` to manage permissions. | Role | Capability | | -------------------------- | -------------------------------------------------------------- | | `DEFAULT_ADMIN_ROLE` | Full control: manage roles and governance parameters | | `UPGRADER_ROLE` | Grants ability to upgrade logic contracts via proxy | | `WHITELISTED_ROLE` | Can submit proposals to the VeVote system | | `SETTINGS_MANAGER_ROLE` | Manages contract configurations | | `EXECUTOR_ROLE` | Can mark proposals as executed, as execution happens off-chain | | `NODE_WEIGHT_MANAGER_ROLE` | Can update parameters of the vote weighting formula | *** ### Upgradeability VeVote supports upgradeability through the **UUPS Proxy Pattern**: * The **proxy contract** holds all persistent data * **Logic contracts (libraries)** are called via delegatecall * **`VeVoteStorage.sol`** defines a stable layout to prevent storage collisions > 🔄 Logic can be upgraded module-by-module without resetting or migrating data. *** ### External Integrations | External Contract | Purpose | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | `StargateNFT.sol` | Core Stargate NFT staking contract. Stores level info, VET stake, and token management information used to calculate voting power. | | `Staker.sol` | VeChain’s Proof of Stake registry. Used to check if a voter is an endorser of an VeChainThor Validator. | *** ### Deployed Addresses This section will list the deployed VeVote contract addresses by network.
ContractAddress
VeVote.sol0x7d812e8e544bb0c7898ea656b70173e7ef426b4c
LibraryAddress
VeVoteVoteLogic.sol0xc1e1c32d98e1e63983dea48b0b4ca4375b5cb582
VeVoteQuorumLogic.sol0xefadb7b6ba6cccf0ae15b54bb3d05e748dee611a
VeVoteProposalLogic.sol0x6fdc53583570a3ef6f8ff647ef4785883998a2e9
VeVoteConfigurator.sol0xb47de033fec4e3ef1f5f5b79a42be469173b6357
VeVoteStateLogic.sol0x716c552490c3e4ddb68fab8b5dd1f1e9d115916f