# StarGate **StarGate** is a pivotal component of the **Hayabusa** phase within the broader **VeChain Renaissance** initiative. It is VeChain’s next-generation staking platform, designed to transform how users participate in the VeChainThor network. It introduces a novel approach by using **NFTs as staking collateral**, creating a dynamic and transparent framework for delegation, reward distribution, and governance. **StarGate app** is available at: ### Key Features * **NFT-Based Staking**: Users stake VET tokens to mint unique NFTs that represent their staking commitment. These NFTs can be delegated to validator nodes, enabling participation in network validation and reward sharing. * **Earn VTHO**: Stakers receive VTHO rewards based on their stake size and the validator they are tied to, aligning incentives across the ecosystem. * **On-Chain Governance**: NFT nodes serve not only as staking representations but also as voting instruments for governance, giving stakers a voice in the evolution of the network.
### Network Integration via Hayabusa Upgrade With the **Hayabusa hard fork**, VeChainThor adopts a **Delegated Proof of Stake (dPoS)** consensus mechanism. This upgrade introduces: * A set of **101 validators** responsible for producing blocks and securing the network. * The ability for any user to participate indirectly by **staking VET through StarGate** and delegating to one of the validators. ***StarGate thus serves as the access point for VET holders to become active contributors to network consensus, without needing to run a full validator node.*** ### Bootstrapping Launch: July 2025 The initial release of **StarGate**, scheduled for **July 1**, will operate independently of the VeChainThor protocol layer. This **pre-Hayabusa phase** serves as a **bootstrapping period** to: * Allow users to explore and familiarize themselves with the new staking platform. * Offer **enhanced staking rewards** as an incentive for early participation. * Provide a migration path for existing **Economic Node** and **X Node** holders to transition their nodes into the new NFT-based system. ### Hayabusa Mainnet Launch: December 2 2025 Following the successful **Hayabusa network upgrade,** scheduled for **December 2**, the bootstrapping period concludes, transitioning users into the primary network operations. In this phase: * **Full protocol-level integration** with validator delegation * **VTHO generation** only available for NFTs that actively delegate * **Dynamic APY** for VTHO rewards based on validators performance and delegator staking position ### **Key Dates for Hayabusa Hardfork:** | Event | Date | Block Height | | ----------------------------- | ----------------- | ------------ | | Testnet release | November 4, 2025 | 23221800​ | | Testnet transition period end | November 11, 2025 | 23282280​ | | Mainnet release | December 2, 2025 | 23414400 | | Mainnet transition period end | December 9, 2025 | 23474880 | {% hint style="info" %} StarGate release for both Hayabusa testnet and mainnet will take place a few hours after the protocol release to ensure a smooth migration process. {% endhint %} *** # VeChain Renaissance The **VeChain Renaissance** is a major protocol upgrade initiative designed to modernize the VeChainThor blockchain across technical, economic, and governance layers. It introduces phased enhancements that align VeChain with leading Web3 standards, improve decentralization, and optimize adoption. ### Objectives * Align with Ethereum standards (EVM, JSON-RPC, dynamic gas). * Introduce sustainable, incentive-driven tokenomics. * Enhance transparency, scalability, and governance. * Foster adoption by developers, enterprises, and community stakeholders. ### Phased Rollout #### Phase 1: Galactica > Focus: Core Protocol Enhancements * Upgrade the EVM version from Paris to Shanghai. * **Clause-level transparency** for contract execution insights. * **Dynamic fee structure** based on Ethereum’s EIP-1559. #### Phase 2: Hayabusa > Focus: Tokenomics & Staking Redesign * Consensus upgrade from PoA to dPoS. * Introduction of **staking NFTs** to represent VET commitment. * Transition to an **active reward model** via validator delegation. #### Phase 3: Interstellar > Focus: Scalability & Permissionless * Add support for JSON-RPC compatibility. * Upgrade the EVM from Shanghai to Cancun. * Several performance and scalability improvements. ### New Tokenomics Model | Feature | Description | | -------------------- | ------------------------------------------------------------ | | Staking NFTs | Stake VET to mint transferable NFTs representing your stake. | | Active Participation | Rewards tied to validator delegation, not passive holding. | | Dynamic Gas Pricing | Network fees adjust based on demand and usage. | | Reduced VTHO Output | Inflation cut to support long-term economic balance. | # Validators Validators are network participants that run the **VeChainThor client** (Thor) to validate transactions, produce blocks, and take part in the consensus process. By maintaining the blockchain’s security and integrity, validators play a **vital role** in the network and **earn block rewards** for their contributions. *** ### Becoming a Validator Anyone can apply to become a validator, provided they **meet both the technical and economic requirements**. A validator setup can be managed by a single individual or divided between two roles: a **node operator**, who runs the validator machine, and an **asset owner**, who locks the required VET and endorses the validator. The process begins by setting up a validator machine and **generating a signing key**. Once the node is synced, the asset owner interacts with Stargate to input the signing key and optionally **define a beneficiary** wallet for rewards. At this stage, they also **choose a validation period** (7, 15, or 30 days) and **stake a minimum of 25 million VET**. By signing the endorsement transaction, the wallet becomes linked to the validator machine, and the validator enters the onboarding process by joining a queue. The queue duration is fixed at 30 minutes before transitioning to active status, provided a slot is available.\ If the validator set is full, the new candidate enters a queue governed by a first-in, first-out (FIFO) logic. *** ### Validator Status Validators move between different statuses depending on their lifecycle: * **Queued**: waiting for a slot to become active, typically after applying or rejoining. * **Active**: participating in block production and consensus. * **Exited**: either voluntarily withdrawn or removed by the protocol. * **Unknown**: a fallback status, triggered by incorrect configuration or protocol errors. Once active, validators are eligible for block proposal and can start receiving delegations. *** ### Staking Periods and Validators Lifecycle Validators must commit to a **validation period**—either 7, 15, or 30 days. This choice affects when they can adjust their stake, request to exit, or process configuration changes. By default, **validators are set to auto-renew**, meaning they automatically roll into a new period unless they actively request to exit. When a validator requests to exit, the **change takes effect at the end of the current period**, followed by a mandatory **24-hour cooldown**. During this time, the validator is no longer eligible for new delegations, and all active delegators are automatically exited. Exiting cannot be reversed once initiated. Validators who fail to produce blocks for seven consecutive days due to technical failures or downtime are **forcibly removed by the protocol**. They cannot re-enter the validator set, but they are allowed to withdraw their staked VET after their exit is finalized, or join the queue again. *** ### Delegations and Selection Probability Delegators play a crucial role in strengthening validators. The **probability** of a validator being selected to produce a block is tied not only to their own staked VET but also to the **total VET delegated to them**. This probability is further **enhanced by reward multipliers** attached to delegators' NFTs. For example, X Node holders apply a 1.5x multiplier to their delegated stake, while other node types receive a 1x multiplier. As a result, validators who attract delegations from high-value NFTs gain a measurable **competitive edge** in block selection. *** ### Validator Rewards Validators receive two forms of income: a **share of block rewards** and 100% of **transaction priority fees** from the blocks they produce. When operating without any delegations, a validator retains the full block reward. However, once they have at least one delegator, the protocol redistributes block rewards such that the **validator keeps 30%**, and 70% is allocated proportionally to the delegators. This structure incentivizes validators to secure delegations while continuing to reward those running infrastructure independently. *** ### Validator Exit Process A validator can initiate a **voluntary exit** at any point during their period. The exit takes effect at the **end of the current staking period**, after which a **24-hour cooldown period** begins. During this time, the validator can no longer receive new delegations, and all existing delegators are also exited from the validator automatically. This ensures synchronization between validator and delegator periods. Once a validator exits, their VET becomes available for withdrawal, and they are permanently removed from the active validator set unless they restart the onboarding process. Validators may also be **forcibly removed** from the network if they fail to produce blocks for **seven consecutive days**. This ensures that underperforming or offline validators do not affect network reliability. Once ejected, they are **ineligible to re-enter** with the same identity and must withdraw their stake. # Staking Lifecycle ### Staking VET to Receive an NFT Staking on Stargate begins when a user chooses to **lock VET** in the protocol by selecting a specific node tier. Each tier requires a fixed amount of VET. The user must provide the **exact amount** of VET needed for that tier; over-staking is not allowed. Once confirmed, the **protocol locks the VET and mints an NFT** that represents the user’s staking position. At this stage, **no rewards are earned yet**. Every staking NFT is subject to a **maturity period**, which is determined by its node tier. During this time, the NFT cannot be delegated to a validator, and it does not accumulate rewards. When the maturity period concludes, the NFT becomes eligible for delegation, allowing the user to start earning VTHO. Users who migrate legacy nodes to the new system bypass the maturity period and can delegate immediately. {% hint style="warning" %} At this point the user **is not accumulating rewards yet**. To earn rewards, user must wait the end of the maturity period and delegate to an active validator. {% endhint %} *** ### Maturity Period and Boost To skip the waiting time of the maturity period, users can opt for the **Boost** **feature**. This functionality enables users to bypass the enforced maturity delay and immediately proceed to delegate their NFT to a validator. The Boost fee is calculated based on the projected rewards that the NFT would have earned during the maturity period—using the bootstrapping phase rewards per tier. The calculation is as follows: **Boost Fee = (VTHO per day + Base Rewards per day) × Days of Maturity × 0.5** This approach anchors the fee to 50% of the total expected rewards during maturity, using the expected rewards simulated during the bootstrapping phase, ensuring fairness while encouraging early participation. The fee must be paid in **VTHO**, and all of it is **burned**. Boost can be used at any time during the maturity period, and is constantly adjusted to the time remaining to maturity end. If used during the staking phase, users can perform a full flow—**stake, boost, and delegate**—in a single transaction, allowing reward accumulation from the validator’s next period.
TypeMaturity (Days)Full Boost Price (VTHO)Boost Price / Block (VTHO)Category
Mjolnir601.034.400,00 1,99537037Eco
Thunder45 206.100,00 0,530092593Eco
Strength3019.680,000,075925926Eco
Flash151.623,000,012523148New Eco
Lightning5124,000,00287037New Eco
Dawn29,320,000539352New Eco
{% hint style="info" %} No new maturity period is applied to migrated Nodes. {% endhint %} *** ### Validator Binding and Auto-Renew **Once the NFT is matured**, the user selects a validator to delegate to. The validator’s **validation period** (7, 15, or 30 days) defines the reward and withdrawal schedule. Delegators are directly tied to the validator's period — they inherit the exact duration of the validator’s active period and follow it through auto-renewal, which is enabled by default. **A delegation becomes active when the validator either starts a new period or, if currently queued, transitions to active status.** Once this happens, the NFT begins to accumulate rewards for every block processed by the validator. These rewards are locked until the period ends and become claimable afterward. Delegators can select validators from the list of 101 active ones or from the queue. Validators that have exited or are in the process of exiting cannot be selected. **If the validator exits, all associated delegations are exited automatically at the end of that period**, and the NFT will stop generating rewards. {% hint style="info" %} Delegated NFTs are transferable. Delegation will remain active and the new owner will own all unclaimed and locked rewards. {% endhint %} *** ### Unstaking VET When the **NFT is not delegated**, the user can **unstake VET at any time** and with no cooldown period.\ To unstake VET when an **NFT is delegated**, the user must first submit a request to **exit delegation**. Once the current validator cycle ends and the NFT is undelegated, the user can proceed to unstake VET. This process **burns** the staking NFT, and returns the locked VET to the user’s wallet. * For X Node holders, burning is irreversible and permanently **reduces supply**. * If rewards have been accumulated but not yet claimed, they will be **automatically claimed** during the unstake operation. * If the NFT is **transferred** before unstaking, any locked and unclaimed rewards are passed to the new owner. While an NFT is still within its **maturity period**, the user **cannot unstake** the associated VET. To proceed with unstaking, they must either **wait for the maturity period to end** or use the **Boost** **feature** to instantly mature the NFT by paying a fee. This matures the NFT and allows immediate unstaking. This ensures continuity and fairness in reward distribution while maintaining protocol integrity. # Delegation Lifecycle **Delegation** is the process by which users **assign their staking NFT to an active or queued validator** on the VeChainThor network. In doing so, they contribute to the validator's total weight and, in return, receive a portion of the **VTHO rewards** generated by the validator's block production. A delegation lifecycle consists of three main states: **pending**, **active**, and **exited**. The delegation process is directly **tied to the selected validator,** including its period length (7, 15, or 30 days) and auto-renewal settings. Delegation auto-renews by default unless explicitly exited by the user or if the validator exits validation. Delegators cannot act independently of their validator's period. They follow the validator's timing and **enter or exit delegation only at the start or end of a validator period.** *** ### Starting a Delegation To delegate, a user must possess a **matured staking NFT**. This can occur in four ways: * **Standard stake flow**: The user stakes VET and waits for the maturity period to complete before selecting a validator. * **Boosted flow**: The user pays a Boost fee in VTHO to skip the maturity period and delegate immediately during staking. * **Migrated flow**: The user migrates an existing legacy node, which is exempt from the maturity period and can delegate right away. * **Bootstrapping phase matured flow**: The use already owns a mature StarGate NFT, previously acquired during the bootstrapping phase, and needs to select a validator and delegate to continue earning rewards. Delegation is only possible if: * The NFT is **matured** or **boosted**. * The validator is either **active** or **queued**. * The validator is **not exiting** or **already exited**. Delegating to queued validators is allowed, but the NFT will remain in a **pending state** until the validator becomes active. *** ### Delegation States **Pending** A delegation enters the **pending state** when the user initiates delegation but the validator’s current period has not yet started or the validator is still in the queue. In this state: * No **rewards** are accumulated * User actions allowed: * **Cancel** delegation * **Change** to a different validator * **Unstake** (burn NFT and recover VET) * Switching validators is instantaneous * Boosted delegations also begin in this state and await validator activation or period start **Active** A delegation **becomes active** at the start of the validator's next period. During this state: * The NFT accumulates **rewards** on every validated block * Rewards are locked and **claimable** only at the **end of the period** * Delegation **auto-renews by default**, matching the validator’s period * The only way to **exit** is to r**equest a delegation exit**, which takes effect at the end of the current period or wait for your selected **validator to exit validation** * The **delegation** remains **active** even if the NFT is **transferred or sold** **Exited** Delegation **exits the active state** in one of the following ways: * The user **requests an exit** * The **validator exits** validation (either voluntarily or forcibly) * The **pending delegation** is **cancelled** Once exited, the NFT: * **Stops** generating rewards * Can be **unstaked** or delegated again *** ### Validator Selection and Timing Users should carefully **choose their validator**, as delegation timings are **bound** to the validator’s activity. Specifically: * A delegator can **only enter** a delegation at the start of the validator’s next period. * A delegator can **only exit** at the end of the current period. * **Auto-renew** is enabled by default, meaning users stay in delegation unless they or the validator choose to exit. If the validator enters an exit phase, the delegator will automatically follow and exit with them. *** ### Reward Mechanics * Rewards begin **accruing** only after delegation becomes **active**. * They are distributed in **VTHO** and locked during each validator period. * Rewards from **completed periods**are **claimable**. * When a user switches validator or unstakes, **any pending claimable rewards are automatically claimed**. * If an NFT is **transferred**, the active **delegation remains in place**, and the new owner gains access to all **unclaimed** and **locked rewards**. *** ### Changing Validator Users can switch their delegation to a different validator at any time: * From pending state: The **change is immediate**, and VET is simply redirected to the new validator * From active state: The user needs to **exit delegation first** then initiate a new one. *** ### Exiting delegation When a user wants to stop delegating, they request a **delegation exit**: * Pending delegation: The exit is **immediate** * Active delegation: The exit is **scheduled** and will complete at the **end of the validator's** **current** **period** * After exit: Users must make an additional transaction to **unstake their VET** and the NFT will be burned It's important to note that **once an exit is declared, it cannot be reversed.** *** ### Important Considerations * **Timing matters:** Delegations don't activate instantly. Users must wait for the validator's next period to begin (typically varies by validator) * **Exit delay**: Exiting an active delegation also requires waiting for the next period * **Automatic reward claims**: When switching validators or unstaking, any pending rewards are automatically claimed * **Validator selection**: Users should carefully choose their validator. **If a validator stops mining or exits the network, reward accumulation stops** * **NFT transfers**: If a user transfers their NFT to another address, the delegation remains active and all lcoked rewards transfers with it
# Rewards Structure The reward system in Stargate is designed to incentivize both participation and long-term engagement in maintaining the VeChain network. Delegators **generate rewards** by staking their NFTs with active validators who participate in block production. Every time a validator mines a block, a portion of the mining rewards is shared with its delegators. *** ### Reward Distribution For every block mined by the validator, the **rewards are allocated** as follows: * **30%** of the rewards are retained by the validator. * **70%** of the rewards are distributed among the delegators **proportionally to their stakes**. A user's rewards are **calculated** based on their share of all delegations to that validator: * **User's contribution** = VET staked \* Reward Multiplier * **User's share** = Their contribution ÷ Total contributions to validator * **User's rewards** = Their share × 70% of validator rewards for the period *** ### What Affects Reward Amounts? Two **main factors** determine how much a user earns: 1. **Amount of VET staked**: More VET means a larger share 2. **NFT Level/Tier**: Higher-tier NFTs have reward multipliers that boost the effective stake 3. Amount of active delegators for that validator: more delegators means more users to share the rewards with Each NFT tier is associated with a r**eward multiplier** that enhances the user's share of rewards. The tiers and their respective multipliers are as follows: | Category | Type | Reward Multiplier | | -------- | ---------- | ----------------- | | X | Mjolnir X | 5 | | X | Thunder X | 4 | | X | Strength X | 3 | | X | VeThor X | 2 | | Eco | Mjolnir | 3.5 | | Eco | Thunder | 2.5 | | Eco | Strength | 1.5 | | Eco | Flash | 1.3 | | Eco | Lightning | 1.15 | | Eco | Dawn | 1 | To calculate the "effective" stake for reward distribution, use the **formula**: $$ \text{Effective Stake} = \text{VETStaked} \times \text{RewardFactor} $$ This calculation ensures that users with higher-tier NFTs receive a **proportionately larger share** of the rewards. **For example,** a premium tier NFT with a 1.5x multiplier means a user's 1,000,000 VET stake counts as 1,500,000 VET when calculating their share of rewards. This means they earn more rewards than someone with the same VET amount but a basic-tier NFT. *** ### Reward Periods Rewards are **distributed at the end of each validator’s period**: * Validator period durations: **7, 15, or 30 days** * During an **active** period: rewards are being generated but remain locked * At the **end of the period**: locked rewards become **claimable** Rewards fall under two categories: * **Locked Rewards**: earned but not yet claimable until the current validator period ends *** ### Claiming Rewards Users can claim their rewards in the following ways: * **Manual Claim**: by interacting with the claim function * **Automatic Claim**: when users unstake or switch validators, claimable rewards are automatically distributed Users can claim rewards accumulated from any **completed** periods, even if many periods have passed. Rewards must be claimed **sequentially**, and claiming out of order will revert. *** ### **Important Considerations** * **Hayabusa mainnet transition period:** From December 2, 2025 to December 9, 2025, **no rewards** will be generated. * **Delegation isn’t instant**: it becomes active only when the validator starts a new period * **Exit isn’t instant**: delegation exits are only processed at the start of the validator's next period * **Validator selection matters**: if a validator doesn’t mine blocks, no rewards are generated * **NFT transfers**: delegation remains active if the NFT is transferred; locked and claimable rewards move with it * **Pending rewards on exit or switch**: all claimable rewards are **automatically claimed** when exiting delegation or unstaking This structure aligns reward eligibility, validator activity, and delegator behavior under one cohesive system, balancing fairness and transparency for all participants. # NFT Lifecycle Management ### NFT Marketplace Interaction Staking NFTs issued through Stargate are fully compatible with **VeChain-based marketplaces**. They can be listed, bought, sold, or transferred while preserving both their staked VET and staking-related attributes. This allows for seamless NFT liquidity while maintaining the staking logic and reward mechanics. {% hint style="info" %} Stargate official secondary marketplace is available at: {% endhint %} *** ### Listing and Selling NFTs Both **delegated** and **undelegated** staking NFTs can be listed for sale at any time: * **Undelegated NFTs** can be freely listed and sold without restrictions. * **Delegated NFTs** can also be listed. While listed, they continue to accumulate *locked* rewards. If the sale occurs during an active delegation, the seller can claim all available rewards up to the moment of sale. Once the NFT is sold, the new owner inherits: * The staked **VET collateral** * All **unclaimed** and **locked** VTHO rewards * The **active delegation**, if any There is no reward loss in the transfer; all rights are transferred in full. {% hint style="warning" %} In all scenarios, after the sale or transfer happens, **the new owner will own all locked and unclaimed rewards.** {% endhint %} *** ### Metadata and NFT Visibility Each staking NFT has **dynamic metadata** that updates in real time to reflect: * **NFT tier/level** * **Delegation** status (delegated or undelegated) * **Maturity** status * Associated **validator** (if delegated) This ensures clear visibility for prospective buyers and simplifies on-chain tracking of the NFT’s utility status. *** ### Inheriting the Staked VET When a buyer acquires a staking NFT, they automatically inherit: * The **exact VET amount** staked behind the NFT * All **locked and unclaimed rewards** * The validator **delegation** (if the NFT is currently delegated) However, some key points apply: * **If not delegated**, the new owner must initiate a delegation to start earning rewards. * **No additional maturity** is required if the NFT has already matured or if Boost was used. * **If delegated**, rewards will continue accumulating and the buyer assumes full rights over them. *** ### Transferring NFTs Between Wallets Staking NFTs can be transferred freely between wallets, outside of marketplace transactions, even if delegated. All marketplace rules also apply to manual transfers: * **Delegation** (if any) remains **intact and active** * **Reward flow** continues uninterrupted * New wallet assumes **ownership of staked VET** and all rights to **claim rewards** This allows for private transfers, vault reorganization, or operational delegation changes without disrupting the staking lifecycle. *** ### Managing Multiple NFTs Users may hold **multiple staking NFTs** in the same wallet. Each NFT functions as an independent staking unit with its own: * Maturity period and countdown * Delegation status and validator binding * Reward period and accumulation * Claim window and boost status To simplify portfolio management, the Stargate dashboard displays a **per-NFT overview**, showing: * Delegation status * Next eligible actions (e.g., claim, exit, unstake) * Reward history and pending claims * Maturity timers and validator links This ensures that users can make informed decisions across multiple staking positions. # Legacy Nodes Migration ### Migrating Existing Nodes to StarGate Users who currently hold nodes from the legacy VeChain system—such as Economic Nodes or X Nodes—can upgrade their positions into the Stargate staking framework. Migration transitions these nodes into the **NFT-based staking model**, unlocking new delegation and reward mechanics, and aligning users with the protocol’s long-term vision. *** ### How Migration Works Migration is a **one-click process** that transforms a legacy node into a Stargate-compliant staking NFT. Here’s how it unfolds: 1. The user logs into Stargate with the wallet holding the legacy node. 2. The system detects eligible nodes and displays a **"Migrate"** CTA. 3. The user must have the required amount of **VET available in the wallet**, as hard staking will replace the legacy soft staking. 4. Once confirmed: * The **legacy NFT is burned** and removed from circulation. * A **new staking NFT**, corresponding to the same tier, is minted. * The VET is **hard staked automatically**, locking the collateral. * The user selects a validator, and **delegation begins** automatically from the validator’s next period. There’s no need to manually restake or initiate delegation after migration—**everything is included in a single seamless operation**. > **No maturity period applies** to migrated nodes. Users begin earning rewards from the validator’s next active period. {% hint style="warning" %} Legacy nodes support on platforms as VeBetter and VeVote will be dropped. All owners of existing nodes are invited to migrate in order to keep benefiting from advantages and perks available in the VeChain ecosystem. {% endhint %} *** ### Migration Preconditions and Restrictions To protect staking integrity, a few important conditions must be met before a legacy node can be migrated: #### Maturity Requirement * Legacy nodes must have **completed their original lock/maturity period**. * If the NFT is still maturing under the legacy model, migration is **blocked** until maturity ends. #### Marketplace and Transfer Restrictions * **Listed for Sale**: Migration is blocked if the legacy NFT is actively listed on a marketplace. Users must delist the NFT first. * **Recently Transferred**: If the NFT was transferred to a new wallet within the last 4 hours, migration is temporarily disabled. This cooldown ensures ownership integrity and prevents abuse. These safeguards ensure a **clean transition** into Stargate and prevent edge cases like double rewards, unverified ownership, or sudden asset flips. *** ### Rationale These restrictions are in place to protect the integrity of the StarGate migration process and prevent edge cases—such as premature reward resets, overlapping ownership states, or marketplace manipulation—from disrupting staking operations. By enforcing these conditions, the system ensures a smooth and secure upgrade path for all legacy node holders. *** ### What Changes after Migration? Once migration is complete, users gain access to the full Stargate feature set: * **NFT-Based Staking**: Your node is now represented by a Stargate staking NFT. * **Hard Staking**: Your VET is locked directly in the staking contract, not soft staked. * **Delegation Integration**: You’re now operating under the validator-delegator model, which includes: * Validator-linked period * Period-based reward generation * Auto-renewal logic * **Claim and Boost Tools**: Access to Stargate's interface for managing delegation, claiming rewards, boosting maturity (if needed for future NFTs), and tracking validator performance. *** ### Impact on Supply For **X Node holders**, if the new NFT is eventually **burned** (e.g., via unstaking), it results in a **permanent reduction** in the total supply of that tier. The same principle that applied in the legacy system continues under Stargate, maintaining X Node scarcity. *** > ⚠️ Node holders are encouraged to migrate to **retain access** to VeChain ecosystem benefits moving forward. # NFT Management Stargate's NFT management feature enables staking NFT owners to assign limited operational privileges to a **secondary wallet address**—called a **Node Manager**—without compromising ownership or control. This is especially useful for automating certain tasks or integrating with external services, while preserving full authority over staked assets. A common use case is when a user wishes to entrust actions like **reward claiming** or **app access** (e.g., VeBetterDAO, Discord gated channels) to another address, while retaining full custody of their NFT. By default, the owner is considered as a manager of its tokens, until another address is set. > 🔁 **Managers are automatically removed** upon any NFT transfer or sale. *** ### Owner Roles and Responsibilities The NFT owner remains the **sole authority** over the asset. They can appoint or revoke a manager at any time using the Stargate interface—no approval is required from the manager. Upon assigning a manager, the following controls remain exclusive to the **owner**: * **Staking or unstaking VET** * **Locking or unlocking** the NFT for delegation * **Delegation selection** and exit * **Transferring, selling, or burning** the NFT * **Participating in governance** This ensures that while day-to-day tasks can be outsourced, **strategic and custodial control always remains with the owner**. *** ### Node Manager Capabilities A Node Manager is assigned unilaterally by the NFT owner—**no transaction is needed** on the manager’s part to accept the role. Managers can: * **Claim staking rewards** on behalf of the owner * All rewards are always sent to the **owner’s wallet** * Use the NFT for **authentication** or **access control** in third-party apps or integrations (e.g., gated Discord roles, VeBetter endorsements) * **Remove themselves** as manager at any time through the interface #### Node Managers Cannot: * Stake or unstake VET * Change validator or exit delegation * Lock or unlock the NFT * Transfer, sell, or burn the NFT This strict permission model ensures that managers can **assist** but not **compromise** the NFT's security or financial role. *** ### Use Cases NFT management is designed to offer **operational flexibility** for: * Users with **hardware wallets** who wish to avoid frequent signing * Power users managing **multiple NFTs** across wallets * DAO participants or services interacting with NFTs for **governance** or **access rights** * Projects integrating NFTs for ecosystem features that **don’t require staking control** By separating ownership from limited operational access, Stargate ensures that users can **retain full control** while delegating tasks for convenience and utility. # NFT Tiers
IDCategoryTypeVET Staking RequirementLimited SupplyMaturity (Days)Boost Price (VTHO)Rewards MultiplierGovernance Voting Power Voting Powe Units
7XMjolnir X15,600,000158N/A N/A52,340
6XThunder X5,600,000180N/AN/A4840
5XStrength X1,600,000843N/AN/A3240
4XVeThor X600,000735N/AN/A290
3EcoMjolnir15,000,000100601.034.400,003.51,500
2EcoThunder5,000,00030045206.100,002.5500
1EcoStrength1,000,0002,5003019.680,001.5100
10EcoFlash200,00025,000151.623,001.320
9EcoLightning50,000100,0005124,001.155
8EcoDawn10,000500,00029,3211
{% hint style="warning" %} Tokens with category "X" cannot be generated, they can only be purchased from secondary market. Once burned, the supply of the category associated to the "X" token will decrease forever. {% endhint %} # Contracts The Stargate staking system consists of two primary contracts that work together to manage VeChain protocol staking positions: * `Stargate.sol:` The main entry point and business logic contract * `StargateNFT.sol`: The ERC721 token contract representing staking positions These contracts implement a separation of concerns where the NFT contract handles: token ownership and details, metadata, boosting and managers. While the Stargate contract manages the staking mechanics, validator delegation and rewards logic. Contracts are public and can be found at the following repository:
ContractAddressUtilities
StarGate0x03c557be98123fdb6fad325328ac6eb77de7248cSourcify
VeChainStats
StarGateNFT0x1856c533ac2d94340aaa8544d35a5c1d4a21dee7Sourcify
VeChainStats
{% hint style="info" %} Need testnet addresses? [Check out the Testnet section](/for-developers/testnet)! {% endhint %} ## `Stargate.sol` Entry point for all staking, delegation, and reward operations. Acts as the orchestrator between users, the `StargateNFT` contract, and the VeChain Protocol `Staker` contract. * Orchestrates staking, delegation, exits, and reward accounting. * Custodies VET during non-delegated phases; funds the on-chain validator delegation when active. * Computes and pays out VTHO rewards. * Coordinates state with the protocol (IProtocolStaker) and with the NFT contract. Interactions with external protocol and tokens: * → `StargateNFT`: Calls `mint()`, `burn()`, `migrate()`, `boostOnBehalfOf()` * → Protocol `Staker` contract: Calls `addDelegation()`, `withdrawDelegation()`, `signalDelegationExit()` * → `VTHO` Token: Transfers rewards using SafeERC20 ## `StargateNFT.sol` ERC721 NFT contract representing staking positions. Manages token metadata, levels, maturity periods, and acts as a continuation of the legacy VechainNodes (X-Node/Eco Node) collection. * ERC721 that represents the staking position. * Stores token metadata required for protocol math (level, vetAmountStaked, maturity, rewardsMultiplier, etc.). * Manages levels, maturity periods, boosting, supply caps, and manager assignments. * Can only be minted/burned by `Stargate` (not by users). ## Security audits StarGate smart contracts have undergone two comprehensive security audits, respectively by [Hacken](https://hacken.io/) and [Trail of Bits](https://www.trailofbits.com/). {% file src="/files/iVm52BFA6ZVq0sOAIt6f" %} {% file src="/files/hoqGcbnzgF6ZJn8GbSNS" %} ## ABIs {% file src="/files/aoHeZ7pOBWt913Ixp5Ae" %} {% file src="/files/JxafsC9FFaI1QzwivtpB" %} ## Interfaces {% file src="/files/nPJmIm0Fw5VcllrArQXx" %} {% file src="/files/721EwKPBJodtEBughIW7" %} # API ## `Stargate.sol` interface ### Staking #### `stake(_levelId)` Hard stakes VET and mints an NFT. When calling this function, the ID of the desired level must be passed as a parameter and the exact amount of VET must be sent as a value of the transaction. A maturity period will be applied to the NFTs minted through this function. #### `unstake(_tokenId)` Burns the NFT and returns the staked VET to the user. If there are any claimable rewards, those will be automatically claimed and sent to the owner. Unstaking is possible only when the NFT does not have any active delegation. ### Delegation #### `delegate(_tokenId, _validator)` Delegates the token to the validator to increase its probability of being selected as a validator and accumulate rewards for each mined block. The delegation is not active until the start of the next period of the validator. In the meantime, the user can change the validator by calling this function again, cancel the delegation or unstaking the token. The validator must be in an `ACTIVE` or `QUEUED` state, and must not have requested to exit prior to this. If the NFT has any claimable rewards, those will be automatically claimed. When such action is done, a delegation, with its own ID, will be assigned and linked to the NFT. The delegation will be initially in `PENDING` state and become `ACTIVE` when the validator enters the next period or becomes active. If, in the meantime, the validator decides to exit, the delegation will be cancelled. #### `stakeAndDelegate(_levelId, _validator)` Stakes VET and mints an NFT, boosts the NFT maturity period by paying the `VTHO` fee, and initiates a delegation for the specified validator. Validator must be in an active or queued state. Apart from sending the exact amount of VET as value of the transaction, developers need also to call the `VTHO` contract and approve the `StargateNFT` contract address to transfer enough `VTHO` tokens to cover the boosting price. {% hint style="warning" %} Even if we are interacting with the Stargate.sol contract, VTHO approval must be allowed to the StargateNFT.sol contract, which is the one actually burning the VTHO. {% endhint %} #### `migrateAndDelegate(_tokenId, _validator)` Migrates a token from the legacy nodes contract to `StargateNFT`, and delegates it to the specified validator. Validator must be in an active or queued state. VET must be sent as value of the transaction. The legacy NFT will be burned and a new one, with the same level, will be minted in the `StargateNFT` contract. No maturity period is applied to migrated tokens. #### `requestDelegationExit(_tokenId)` Requests a delegation exit by signalling the exit to the protocol staking contract. If the delegation is active, the user will need to wait for then end of the period to actually exit, if instead the delegation is pending the user will exit immediately. Once the request to exit is signalled, the user cannot undo it and cannot request to exit again. #### `getDelegationDetails(_tokenId)` Returns the details of the delegation of a token. If the token does not have any delegation, it will return a set of default values. The returned details are: * `delegationId`: the latest delegation id for the token (can be pending, active, or exited) * `validator`: the validator address * `stake`: the amount of VET delegated to the validator (that is the same as the price of the NFT) * `probabilityMultiplier`: a multiplier used to multiply the stake of the user when calculating the weight of the delegation (scaled by 100) * `startPeriod`: the period when the delegation became active * `endPeriod`: the period when the delegation ended (if exited); `uint32.max` if still active * `isLocked`: the delegation is locked while active, and it means that the VET cannot be withdrawn and user needs to request to exit * `status`: The status of a delegation {% hint style="warning" %} "Probability multiplier" is different from the "Rewards Multiplier". The first one is used by the protocol to handle validator's stakes, the second one is used by StarGate to calculate the effective stake and the share of rewards. {% endhint %} #### `getDelegationStatus(_tokenId)` Possible statuses of a delegation: * `NONE`: the delegation id is not valid, or user never delegated * `PENDING`: the user has selected a validator and staked the VET, but is waiting for the next period to start or for the validator to be become active * `ACTIVE`: the user is accumulating rewards; if the user requests to exit the delegation the status remains `ACTIVE` * `EXITED`: the user has exited the delegation or the validator exited and forced the user to exit or the user exited a pending delegation and the stake is now 0 {% hint style="warning" %} There is no status to indicate if a delegation requested to exit. The ways to know that is by checking the `endPeriod` (if is `uint32.max` then it's active) or by calling `Stargate.hasRequestedExit(_tokenId).` {% endhint %} ### Rewards #### `lockedRewards(_tokenId)` Returns the VTHO accrued in the current ongoing period for an `ACTIVE` delegation. These rewards are not yet claimable, and will become claimable at the end of the current period. Returns 0 if the delegation is not `ACTIVE` (`NONE`, `PENDING`, or `EXITED`). #### `claimableRewards(_tokenId)` Returns the total VTHO currently claimable for all completed periods since the last claim. #### `claimRewards(_tokenId)` Transfers all currently claimable VTHO to the NFT owner and advances `lastClaimedPeriod` to the last claimed period in that call. Anyone can call this; funds are always sent to the current NFT owner. Automatically executed by `unstake(_tokenId)` and during `delegate(_tokenId, _validator)` when moving from a prior delegation, but these actions will revert if the unclaimed window exceeds the cap (see below). #### `claimableDelegationPeriods(_tokenId)` Returns the range of periods that the token has available to claim. ### Rewards - Edge Cases To avoid out-of-gas with long period ranges, the contract enforces a claim window cap via `maxClaimablePeriods` (default: 832, equal to around 16 years of unclaimed rewards for periods of 7 days). In mainnet and testnet such limits will hardly be reached, but when testing locally or in an ad-hoc created environment where validators have way lower periods (for example 3 minutes) devs will easily encounter such edge case. For such edge case, we advise using the following procedure: 1. Call `claimableDelegationPeriods(_tokenId)` to obtain the range of claimable periods 2. Call the `getMaxClaimablePeriods()` to know the enforced limit of periods that can be claimable in one batch 3. Determine how many batches you will need (eg: `ceil((lastClaimablePeriod-firstClaimablePeriod)/maxClaimablePeriods)`) 4. Call `claimableRewards(tokenId, batch)`, where batch is 0-based, to know exactly the amount of total claimable rewards of a token 5. When claiming rewards, create a multiclause transaction with a `claimRewards(_tokenId)` clause per batch In such scenario `unstake(_tokenId)` and `delegate(_tokenId, _validator)` will revert with `MaxClaimablePeriodsExceeded()` to prevent accidental loss; claim the rewards with a multiclause transaction before executing those 2 functions to avoid errors. ## `StargateNFT.sol` interface ### Boosting and Maturity #### `boost(_tokenId)` Skips the remaining maturity blocks immediately by burning VTHO; token becomes usable for delegation right away. VTHO must be approved to the `StargateNFT` contract; the contract transfers VTHO from caller and burns it (sends to address(0)). Reverts if maturity already ended, with `MaturityPeriodEnded(_tokenId)`, or on insufficient VTHO balance or allowance. #### `boostAmount(_tokenId)` Useful getter to pre-calculate the fee to boost the maturity period of a token. When showing on the frontend, keep in mind that this may not be an accurate value, because the fee goes down as blocks are minted. So it may happen that you show/approve an amount, but you end up spending less (never more). #### `boostPricePerBlock(_levelId)` This function will return the amount of VTHO that needs to be paid for each block of the maturity period that needs to be boosted for a specific level. #### `boostAmountOfLevel(_levelId)` Retrieve the total boost price required for a specific level, which can assist in determining the fee for boosting the maturity period of a token at that level during the `stakeAndDelegate` flow when the `tokenId` is still uknown. ``` Boost Price = boostPricePerBlock * StargateNFT.getLevel().maturityBlocks ``` #### `maturityPeriodEndBlock(_tokenId)` End block is tracked per token; migrated tokens have no maturity (end block set to the current block). #### Levels and Token Details #### `getLevel(_levelId)` Returns the immutable level spec: `name`, `isX`, `id`, `maturityBlocks`, `scaledRewardFactor`, `vetAmountRequiredToStake`. `scaledRewardFactor` is scaled by `REWARD_MULTIPLIER_SCALING_FACTOR (100)` and is used by `Stargate.sol` to compute effective stake for rewards. Caps and circulating supply are enforced at mint; X-level caps auto-adjust on migrate/burn. #### `getToken(_tokenId)` Returns token metadata: `tokenId`, `levelId`, `mintedAtBlock`, `vetAmountStaked`, and a deprecated last-VTHO timestamp. `vetAmountStaked` equals the level’s `vetAmountRequiredToStake` at mint/migration time. For token URI, the contract uses a level-based base URI with a “locked” suffix when delegation is active. #### `isX(_tokenId)` Returns if a token is of category "X" or not. ### Ownership and Manager System #### `idsOwnedBy(_owner)` Returns all token IDs owned by `_owner` using `ERC721Enumerable` indexing. #### `tokensOwnedBy(_owner)` Returns a full array of typed Token for the owner. #### `idsManagedBy(_user)` Consider the following scenario to understand how the functions operate: * **Dan** minted NFTs with ID 1 and 2 * **Victor** minted NFT with ID 3 * Dan adds Victor as a manager for NFT ID 2 * Victor adds Dan as a manager for NFT ID 3 Based on this setup: * `idsManagedBy(dan)` will return IDs: 1 and 3 * `idsManagedBy(victor)` will return ID 2 This means the function returns all NFTs owned by the user and not managed by someone else, along with all the NFTs that the user is managing on behalf of someone else. Note that the owner is always a potential manager, but if the owner assigns a different manager, they are no longer considered the manager. #### `tokensManagedBy(_user)` Same as i`dsManagedBy(_user)` but returning the `Token` datatype. Returns the list of: 1. Tokens managed by the user 2. Tokens owned by the user and not managed by someone else #### `tokensOverview(_user)` The `tokensOverview` function returns an array of `TokenOverview` structures for the specified `_user`. Each `TokenOverview` includes the token ID, the owner’s address, the manager’s address and the level ID. #### `getTokenManager(_tokenId)` Returns the manager of the token; If it's not set it will return the owner address, otherwise the manager added by the owner. Returns address(0) if the token does not exist. #### `addTokenManager(_manager, _tokenId)` Let owners assign a separate “manager” that can use the token for off-chain integrations (e.g., governance) without ownership rights. A token can have only 1 manager. **If no manager is added, then the owner is considered the manager of the token.** Adding a new manager replaces any existing one (emits removal for previous). Manager is automatically removed on token transfer. #### `removeTokenManager(_tokenId)` Callable by the current manager or the token owner, and reverts if there is no manager already set. ### Transfer Behaviour #### `transferFrom/safeTransferFrom(...)` ERC721 implementation of transferability. The token remains fully transferable at all times. Only the owner can transfer tokens. # NPM You can install an NPM package containing all the types and artifacts of the StarGate contracts so you do not need to manually import the ABI files and you can have full types support in your queries / clause building. NPM Package: #### Installation: ```sh yarn add @vechain/stargate-contracts-artifacts ``` or ```sh npm install @vechain/stargate-contracts-artifacts ``` #### Usage (with [SDK](https://docs.vechain.org/developer-resources/sdks-and-providers/sdk)): ```javascript import { StargateNFT__factory } from "@vechain/stargate-contracts-artifacts" const res = await thor.contracts .load(stargateContractAddress, StargateNFT__factory.abi) .read.balanceOf(address); ``` **Usage (JSON Artifacts)** You should be also able to get the JSON artifacts from this package ```javascript import * as StargateNFTArtifact from "@vechain/stargate-contracts-artifacts/artifacts/contracts/StargateNFT.sol/StargateNFT.json"; ``` # Testnet If you need to experiment with the StarGate contracts, you can point to the below testnet contracts. ## Addresses
ContractAddress
StarGate0x1E02B2953AdEfEC225cF0Ec49805b1146a4429C1
StarGateNFT0x887d9102f0003f1724d8fd5d4fe95a11572fcd77
## ABIs {% file src="/files/aoHeZ7pOBWt913Ixp5Ae" %} {% file src="/files/JxafsC9FFaI1QzwivtpB" %} ## Interfaces {% file src="/files/nPJmIm0Fw5VcllrArQXx" %} {% file src="/files/721EwKPBJodtEBughIW7" %} ## Import the contracts on Inspector Go to , switch to testnet (on top-right), click add, add the above address and the ABI that you can find in the below section.
## Run locally You can deploy the contracts on your own or run the tests by using the public repo with the contracts at . This resource contains all necessary files and instructions, allowing you to clone the repository, explore the smart contract code, and follow setup procedures step-by-step, allowing you to interact with the contracts on testnet or thor solo. {% hint style="info" %} Need VTHO? Use this faucet: {% endhint %} # Intro In Phase 1 (used as a bootstrapping period) there were no validators and interactions with the protocol: the delegation was just a simulation and an incentive for users to start staking and get used to future dynamics. Rewards, in fact, were not coming from validating blocks by validators but from a pool of VTHO created by the VeChain Foundation. This big difference is why **in Phase 2 some flows and functionalities had to change and to be adapted to the way the protocol works**. In Phase 2, a **new smart contract was created (`Stargate`)** as the central entry point for most staking and delegation operations. This new contract streamlines the process and replaces certain outdated contracts. Notably, the **`NodeManagement` and `StargateDelegation` contracts have been deprecate**d. To **gain a deeper understanding of the changes** in features and smart contracts, we invite you to explore two key sections: * **Functionality Section**: This section outlines all breaking changes from the feature point of view, providing a comprehensive overview of how these changes might impact your interaction with the protocol. * **Contracts Section**: Here, you'll find detailed information on breaking changes in smart contracts and their interfaces, including deprecations and the introduction of new contracts. This section is crucial for understanding the underlying technical adjustments made during Phase 2. {% content-ref url="/pages/ybsKjnXAtlG0wh87fRgB" %} [Functionality Changes](/phase-2-breaking-changes/functionality-changes) {% endcontent-ref %} {% content-ref url="/pages/gnIq387tAb4jaN3OEcGN" %} [Contracts and API Changes](/phase-2-breaking-changes/contracts-and-api-changes) {% endcontent-ref %} # Functionality Changes ### Maturity Period **In Phase 1**, when staking, the delegation was automatically started and rewards would start accruing only after the maturity period would end. This means that the only operation the user had to make is "stake" and he could forget about everything and come back months later to claim all accumulated rewards. **In Phase 2**, it is not possible to delegate if maturity period is not elapsed. This means that the user now needs to stake, wait the maturity period, come back to StarGate and delegate in order to start accumulating rewards. A Boosting functionality was added in Phase 2 to allow the user to skip any maturity period by paying a fee in VTHO. If such option is selected during the stake phase then everything can be done by the user in one operation and start to accumulate rewards immediately: stake, boost and delegate. ### Delegation **In phase 1**, when staking, the delegation was automatically initiated. Starting a new delegation was also immediate, starting accumulating rewards from that block. **In phase 2**, when staking (without boosting), the **delegation is not automatically initiated**. Also, when starting a new delegation, the **NFT does not start to accumulate rewards from that block** but from the block when the next period of the selected validator starts. **Auto-renew is always on**: there is no such option as entering delegation with auto-renew turned off. To achieve this behaviour, the user must enter delegation then request to exit it once the delegation becomes active. Another important difference is that previously it was up only to the user to decide when exiting delegation. This remains true, but because of the nature of the protocol, **if the validator the user is delegating to decides to exit, the delegation will end as well.** ### APY **In Phase 1**, APYs were fixed and decided by VeChain Foundation, with rewards coming from a specific pool of VTHO rewards. **In Phase 2**, **APY is dynamic** and depends on many factors, such as: amount of **blocks the validator is processing, amount of delegations** the validator has, **and tiers of delegated NFTs**. ### Rewards **Base VTHO rewards** (accumulated just by holding VET) **do not exist any more.** VTHO can be generated only by actively delegating to a validator. In Phase 1, rewards were accumulating over a 7 days period, after which they were becoming claimable. Now the **periods are not fixed to 7 days any more but depend on the validator settings, which can be: 7, 15 or 30 days.** When transferring an NFT, **unclaimed rewards are not automatically claimed any more** (only happening now when changing delegation or unstaking). **All accrued delegation and base VTHO gerenation rewards accumulated during Phase 1 were all claimed for users by the VeChain Foundation** with the rollout of Phase 2, allowing users to start with a fresh state. ### NFT Managers The **manager** of the NFT **is reset** upon any new transfer. All functionality is now handled internally without the need of a proxy contract. ### NFT Transferability Differently from Phase 1, where NFT was locked while delegation was active, in Phase 2 such restriction was removed and the **NFT is always transferable**. When transferring an NFT, by manually sending it or by selling on a marketplace, **the new owner owns the staked VET, all the unclaimed rewards and all currently locked rewards** (if NFT is delegated). ### Migration Migrating now requires specifying a validator to delegate to. # Contracts and API Changes The recent updates deprecate the `StargateDelegation.sol` and `NodeManagement.sol` contracts, consolidating functionalities within the `Stargate.sol` and `StargateNFT.sol` contracts. Key changes include the removal and replacement of functions to improve delegation handling and NFT transferability, as well as the migration of node management functionalities. Functions like `stakeAndDelegate()`, `migrateAndDelegate()`, and methods to manage node and reward processes have either been relocated or modified. ### Contracts 1. `StargateDelegation.sol` contract is deprecated: all delegations and rewards are now handled by the `Stargate.sol` contract. 2. Removed, in `StargateNFT.sol`, everything related to vet generated vtho (setters, getters, library), since the protocol is not generating VTHO just for owning VET, but only when delegating; 3. Claimable delegation rewards are not automatically claimed any more upon a token transfer, only during unstake or new delegation, and such actions are handled by the `Stargate.sol` contract. 4. NFT is now always transferable, even when it is delegated to a validator. ### API 1. `stakeAndDelegate()` now requires a fee paid in VTHO to allow skipping the maturity period, and the user needs to select a validator. 2. `migrate()` function was removed, now it is only possible to `migrateAndDelegate()` and a validator must be selected when performing such action. 3. `delegate()` must receive a validator as a parameter and delegation does not start immediately but at the start of the next period of the validator; delegation now has 4 states: uknown, pending, active, exited. 4. `isDelegationActive()` was removed in favour of `getDelegationStatus()`. 5. `accumulatedRewards()` was removed in favour of `lockedRewards()`. 6. Removed getters in `StargateNFT.sol` to optimize contract size: `normalTokensCount()`, `getCap()`, `canTransfer()`, `ownsNormalToken()`, `isNormalToken()`, `levelsOwnedBy()` 7. The following functions are moved from `StargateNFT.sol` to the `Stargate.sol` : \ \- `stake()`\ \- `unstake()`\ \- `stakeAndDelegate()`\ \- `migrateAndDelegate()` 8. `NodeManagement.sol` contract is deprecated. Managers are now handled by the `StargateNFT.sol` contract. All previous managers from `NodeManagement` were migrated. The following functions have been deprecated:\ `NodeManagement.getNodeManager()` -> `StargateNFT.getTokenManager()`\ `NodeManagement.getNodeOwner()` -> `StargateNFT.ownerOf()`\ `NodeManagement.getNodeLevel()` -> `StargateNFT.getTokenLevel()`\ `NodeManagement.isNodeManager()` -> `StargateNFT.isTokenManager()`\ `NodeManagement.delegateNode()` -> `StargateNFT.addTokenManager()`\ `NodeManagement.removeNodeDelegation()` -> `StargateNFT.removeTokenManager()`\ `NodeManagement.getNodeIds()` -> `StargateNFT.idsManagedBy()`\ \ \ \ \ \ New functions were added to expand the functionality\ `StargateNFT.tokensManagedBy` -> Returns a list of the tokens managed by an address.\ `StargateNFT.isManagedByOwner` -> Since by default the owner is the manager of a token and that is reflected in functions like `idsManagedBy` or `tokensManagedBy` this function returns `false` if the token is managed by an address that is not the owner.\ `StargateNFT.tokensOverview` -> Given an address returns an overview of all the tokens related with the given address. This overview includes `owner`, `manager`, `id` and `level`.
9. Legacy nodes are not being considered any more. # Stake, Boost and Delegate This guide provides a way to: stake your vet, boost the maturity period, and delegate to a validator in a single transaction without using VeWorld mobile app or the StarGate dApp. ## Guide {% stepper %} {% step %} ### Install VeWorld extension in the browser The extension is a tool that allows you to manage a cryptocurrency wallet and use it to interact with dApps. Install it from [here](https://chromewebstore.google.com/detail/veworld/ffondjhiilhjpmfakjbejdgbemolaaho). {% endstep %} {% step %} ### Create a wallet and deposit VET and VTHO After installing the extension, create a wallet, backup the seed phrase and deposit enough VET to cover the stake, and enough VTHO to cover the gas fees and the boost price. {% endstep %} {% step %} ### Open the Inspector website [Inspector](https://inspector.vecha.in/) is a website that allows you to interact with smart contracts. You can both visit the online version or fork the [public repo](https://github.com/vechain/inspector-app) and run it locally. {% endstep %} {% step %} ### Add the contracts you will interact with Once you open the Inspector website you will find an empty page asking you to add contracts you want to interact with. To reach our goal we will need to add 2 contracts: VTHO and StarGate. **Add VTHO** To do it, just click the "New +" button, then in the "Name" input field write "VTHO", you will see an autocomplete dropdown suggesting you to use the pre-uploaded contract. Click on it and it will prefill the address and ABI fields automatically. Then click "Add" again to save it. **Add StarGate** Now do the same, but to add the StarGate contract. Click "New +", write "Stargate" and you will see 2 suggestions: "StarGate NFT" and "StarGate". Click on "StarGate", then click "Add" again. {% hint style="warning" %} Check that the addresses are the official ones you see in the [Contracts](/for-developers/contracts) page. {% endhint %} {% endstep %} {% step %} ### Find the NFT level you want to stake for Go to the [NFT Tiers](/overview/nft-tiers) section and find the id of the level you want to stake for, eg: Thunder has level ID 2. {% endstep %} {% step %} ### Find the validator address you want to delegate to You can find this information by searching the validator on [StarGate](https://app.stargate.vechain.org) app. Once you find the validator you must copy its address, eg: `0x244306eea413a1b94d156c93dc679b2b1e18bebf` {% endstep %} {% step %} ### Approve the `StarGateNFT` contract to move VTHO from your wallet {% hint style="info" %} When boosting, the `StarGateNFT` contract will transfer VTHO from your wallet and burn those tokens. An approval for the contract to do so it's mandatory in order to use the boost feature. {% endhint %} In Inspector open the `VTHO` contract, go to the "Write" section, and find the `approve` function. Fill the form with the correct data: * caller: the address of your wallet, the one you will use to stake * \_spender: the `StarGateNFT` contract (address can be found [here](/for-developers/contracts) for mainnet, [here](/for-developers/testnet) for testnet, or just copy it from the added contract on the Inspector website) * \_value: the maximum amount the contract will be able to transfer, in wei; set this to the boost price (that you can find in the [NFT Tiers](/overview/nft-tiers) section, eg: for Thunder NFT it is 206.100,00 VTHO, which is 206100000000000000000000 converted to WEI) Click "Excute": this will open your wallet and ask you to sign the transaction. Once done wait that the transaction is successful. {% endstep %} {% step %} ### Call stakeAndDelegate in the `StarGate` contract Now it's time to stake, boost and delegate. In Inspector click the StarGate contract, then go to the "Write" section and search for the `stakeAndDelegate` function. Fill the form with the right information, based on the NFT level you want to stake for. Eg, for an NFT of level Thunder we will fill with the following information: * Caller: the address of the wallet you will use to stake * \_levelId: the level id of the NFT, in our example it is "2" * \_validatorId: the address of the validator we want to delegate to, in our example we picked a random one `0x244306eea413a1b94d156c93dc679b2b1e18bebf` * value: add here how much VET do you want to send when doing this transaction, it must be EXACTLY the price needed for the stake; in our example is "5000000" VET. Click "Execute", confirm with the VeWorld extension, and wait for the transaction to be successful. {% endstep %} {% step %} ### That's it! You staked your VET, got an NFT representing your staking position, and delegated to a validator. Once per validator cycle you will be able to claim all the generated rewards. {% hint style="warning" %} You delegation may still be in a pending state, depending on the current status and cycle of the validator. The delegation will become ative once the validator will enter in a new cycle. {% endhint %} {% endstep %} {% endstepper %} {% hint style="info" %} There are many other functions you can call in the StarGate or StarGateNFT contract from inspector that will allow you to see details about your maturity period, NFT, delegation status and rewards. You can find the full list of APIs [here](/for-developers/api). {% endhint %} ## Tutorials ### Install VeWorld extension {% embed url="" %} ### Setup Inspector {% embed url="" %} ### Approve VTHO {% embed url="" %} ### Stake, Boost and Delegate {% embed url="" %}