The Hacken 2025 Yearly Security ReportCovers major Web3 breaches, their root causes, prevention insights, and key regulatory trends for 2026.
Learn more

Audit name:

[SCA] VeChain | Stargate | Oct2025

Date:

Feb 4, 2026

Table of Content

Introduction
Audit Summary
System Overview
Potential Risks
Findings
Appendix 1. Definitions
Appendix 2. Scope
Appendix 3. Additional Valuables
Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the Vechain Foundation team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

The VeChain 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.

Document

NameSmart Contract Code Review and Security Analysis Report for Vechain Foundation
Audited By, Stepan Chekhovskoi
Approved ByIvan Bondar
Websitehttps://www.vechain.org
Changelog03/11/2025 - Preliminary Report
06/11/2025 - Remediation Report
16/01/2026 - Remediation Report
03/02/2026 - Final Report
PlatformVeChain
LanguageSolidity
TagsLiquid Staking, Non-Fungible Token, Staking
Methodologyhttps://hackenio.cc/sc_methodology
  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Vechain Foundation
    Audited By
    , Stepan Chekhovskoi
    Approved By
    Ivan Bondar
    Changelog
    03/11/2025 - Preliminary Report
    06/11/2025 - Remediation Report
    16/01/2026 - Remediation Report
    03/02/2026 - Final Report
    Platform
    VeChain
    Language
    Solidity
    Tags
    Liquid Staking, Non-Fungible Token, Staking

Review Scope

Repositoryhttps://github.com/vechain/stargate
Initial Commit74f2662
Remediation Commit5f981b0
Remediation Commit0b97c95
Final Commitdd10677

Audit Summary

22Total Findings
19Resolved
3Accepted
0Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

{Finding_Table?columns=title,severity,status&setting.filter.type=Vulnerability}

Documentation quality

  • Public documentation clearly specify the functional requirements.

  • Technical description is provided, the project runs well out-of-box.

Code quality

  • The code considers best architectural practices, functionality is split in separate libraries.

  • The role based access control is clear.

  • The development environment is configured.

Test coverage

Code coverage of the project is 87.7% (branch coverage).

  • Unit tests cover deployment and basic contract operations in mocked environment.

  • Certain getters and permissioned functionality of StargateNFT contract is not covered with unit tests.

  • Integration tests cover high-level operations such as staking and delegation in connection with Thor Solo node.

System Overview

Stargate is a decentralized VET staking and delegation system on the VeChain blockchain that enables users to stake their VET tokens through NFTs and delegate them to validators to earn VTHO rewards. The system utilizes an NFT-based approach where each staking position is represented as a transferable ERC721 token, allowing users to participate in the VeChain PoA consensus mechanism while maintaining liquidity and flexibility of their staked assets.

The protocol implements a sophisticated delegation model with validator periods, reward distribution based on effective stake calculations, and comprehensive maturity and migration mechanisms for legacy node holders. The system is composed of several modular smart contracts working together to provide a complete staking infrastructure with upgradeability, access control, and pausability features.

Stargate.sol (Main Entry Point): The primary contract that orchestrates all staking, unstaking, delegation, and reward distribution operations. It serves as the main entry point for users and manages interactions with the VeChain Protocol Staker contract.

  • Handles VET deposits and withdrawals

  • Manages delegation lifecycle (initiate, exit, withdraw)

  • Calculates and distributes VTHO rewards based on effective stake

  • Tracks delegation periods and validator states

  • Implements checkpointed effective stake tracking per validator

  • Provides automatic reward claiming during unstake/redelegate operations

  • Enforces maximum claimable period limits to prevent gas exhaustion

StargateProxy.sol (Proxy Pattern): A standard ERC1967 UUPS proxy contract that delegates all calls to the Stargate implementation. It follows OpenZeppelin's upgradeable proxy pattern and stores the implementation address using the EIP-1967 standard storage slot to avoid collision with the implementation's storage layout.

  • Delegate calls to current Stargate implementation

  • Store implementation address in EIP-1967 standard slot

  • Support upgrades via UUPS pattern

StargateNFT.sol (NFT & Position Management): An ERC721 upgradeable contract that represents staking positions as NFTs. Each NFT corresponds to a specific level (tier) with associated VET requirements and reward multipliers.

  • Mints NFTs when users stake (callable only by Stargate)

  • Burns NFTs when users unstake (callable only by Stargate)

  • Manages NFT levels, caps, and metadata

  • Handles maturity periods for newly minted NFTs

  • Supports migration from legacy VeChain X-Nodes and Eco Nodes

  • Implements boost functionality to skip maturity periods

  • Tracks token managers for delegation management

The system also uses a modular library approach to manage different aspects of the NFT functionality:

MintingLogic.sol: Implements the core minting logic for both regular staking and legacy node migration. Handles:

  • VET amount validation for each level

  • Circulating supply and cap checks

  • Maturity period assignment

  • Whitelist-based migration (V2 feature)

  • Integration with legacy TokenAuction contract

Token.solManages individual token operations, including:

  • Token data structure access

  • Token state queries (maturity status, level, VET amount)

  • Token validation and existence checks

TokenManager.sol: Handles the manager functionality where NFT owners can assign managers to their tokens:

  • Manager assignment and removal

  • Manager validation

  • Automatic manager removal on token transfer

Levels.solManages NFT level configurations, including:

  • Level metadata (VET requirements, reward multipliers, maturity periods, caps)

  • Circulating supply tracking per level

  • Historical supply checkpoints for analytics

  • Level addition and updates

Settings.solProvides administrative functions for contract configuration:

  • Legacy nodes contract reference

  • Stargate contract address management

  • Whitelist entry management (V2)

  • Base URI configuration for metadata

Clock.sol: Provides block-based timing functionality:

  • Returns current block number as clock time

  • Implements EIP-6372 clock mode for compatibility

  • Used for maturity period calculations

DataTypes.sol: Defines all shared data structures used across the system:

  • Token: Stores token-specific data (level, VET amount, mint time)

  • Level: Defines level parameters (VET requirement, reward multiplier, maturity, cap)

  • StargateNFTStorage: Main storage structure using EIP-7201 namespaced storage

  • Whitelist entry structure for migration edge cases

Errors.solCentralizes all custom error definitions for gas-efficient error handling, including:

  • Staking-related errors

  • Migration-related errors

  • Access control errors

  • State validation errors

Privileged Roles

The contracts use OpenZeppelin's AccessControlUpgradeable for role-based access control management. The following roles are defined:

Stargate Contract Roles

DEFAULT_ADMIN_ROLE can call:

  • pause() - Pauses all staking, delegation, and reward operations

  • unpause() - Resumes contract operations after pause

  • setMaxClaimablePeriods() - Updates the maximum claimable periods limit (currently 832)

  • Manage roles via grantRole() and revokeRole()

UPGRADER_ROLE can call:

  • upgradeTo() / upgradeToAndCall() - Upgrades the contract implementation

onlyTokenOwner modifier for user-specific operations:

  • unstake() - Only NFT owner can unstake

  • delegate() - Only NFT owner can delegate

  • requestDelegationExit() - Only NFT owner can request exit

StargateNFT Contract Roles

DEFAULT_ADMIN_ROLE can:

  • Manage all other roles via grantRole() and revokeRole()

  • Perform emergency administrative functions

  • Migrate manager storage (V3 migration only)

UPGRADER_ROLE can:

  • upgradeTo() / upgradeToAndCall() - Upgrades the contract implementation

PAUSER_ROLE can:

  • pause() - Pauses NFT minting and transfers

  • unpause() - Resumes NFT operations

LEVEL_OPERATOR_ROLE can:

  • updateLevel() - Updates existing level parameters (VET requirement, rewards, maturity)

  • updateLevelCap() - Updates the maximum supply cap for a level

  • addLevel() - Adds new NFT levels to the system

MANAGER_ROLE can:

  • Designated by the Stargate contract for specific delegation operations

  • Managed per-token through the TokenManager library

Stargate Contract (special role):

  • mint() - Mints new NFTs when users stake

  • burn() - Burns NFTs when users unstake

  • boostOnBehalfOf() - Skips maturity period for stakeAndDelegate()

Potential Risks

Scope Definition and Security Guarantees: The audit does not cover all code in the repository. Contracts outside the audit scope may introduce vulnerabilities, potentially impacting the overall security due to the interconnected nature of smart contracts.

Critical External Contract Dependency: Complete reliance on IProtocolStaker creates single point of failure. Any flaws or vulnerabilities in these contracts adversely affect the audited project, potentially leading to security breaches or loss of funds.

Dynamic Array Iteration Gas Limit Risks: The project iterates over large dynamic arrays, which leads to excessive gas costs, risking denial of service due to out-of-gas errors, directly impacting contract usability and reliability.

Insufficient Multi-signature Controls for Critical Functions: The lack of multi-signature requirements for key operations centralizes decision-making power, increasing vulnerability to single points of failure or malicious insider actions, potentially leading to unauthorized transactions or configuration changes.

Administrative Key Control Risks: The digital contract architecture relies on administrative keys for critical operations. Centralized control over these keys presents a significant security risk, as compromise or misuse can lead to unauthorized actions or loss of funds.

Single Entity Upgrade Authority: The token ecosystem grants a single entity the authority to implement upgrades or changes. This centralization of power risks unilateral decisions that may not align with the community or stakeholders' interests, undermining trust and security.

Flexibility and Risk in Contract Upgrades: The project's contracts are upgradable, allowing the administrator to update the contract logic at any time. While this provides flexibility in addressing issues and evolving the project, it also introduces risks if upgrade processes are not properly managed or secured, potentially allowing for unauthorized changes that could compromise the project's integrity and security.

Transfer From Arbitrary Address: The boostOnBehalfOf function of the StargateNFT contract allows for arbitrary from parameter propagation for the ERC20.transferFrom operation. The function is carefully restricted with onlyStargate modifier and the Stargate contract is processes the parameter correctly, however, the practice is considered to be risky in terms of future contract upgrades.

Findings

Code
Title
Status
Severity
F-2026-1477[DualDefense] Exited Delegator Receives Rewards
fixed

Critical
F-2026-1478Rewards Drain due to Invalid Last Claimed Period Update
fixed

Critical
F-2025-1378Missing Effective Stake Decrease During Unstake
fixed

High
F-2025-1372Permanent Phantom Stake Accumulation Due to Missing Effective Stake Cleanup on Re-delegation
fixed

High
F-2026-1477[DualDefense] Double Effective Stake Reduction on Redelegation Leading to Arithmetic Underflow
fixed

High
F-2025-1378Unauthorized Delegation via migrateAndDelegate() Function
fixed

Medium
F-2025-1370ERC-7201 Storage Location Comment Does Not Match Actual Value
fixed

Medium
F-2025-1359Off-By-One Error in _exceedsMaxClaimablePeriods() Allows Claiming One Extra Period Beyond Configured Maximum
fixed

Medium
F-2025-1351Storage Inconsistency in migrateTokenManager Function Leading to Data Corruption
fixed

Medium
F-2025-1379Potential Precision Loss on Reward Claim
fixed

Low
1-10 of 22 findings

Identify vulnerabilities in your smart contracts.

Appendix 1. Definitions

Severities

When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.

Reference on how risk scoring is done is available through the repository in our Github organization:

Severity

Description

Critical
Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

High
High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

Medium
Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

Low
Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.
  • Severity

    Critical

    Description

    Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

    Severity

    High

    Description

    High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

    Severity

    Medium

    Description

    Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

    Severity

    Low

    Description

    Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.

Potential Risks

The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.

Appendix 2. Scope

The scope of the project includes the following smart contracts from the provided repository:

Scope Details

Repositoryhttps://github.com/vechain/stargate
Initial Commit74f2662e742af94882e3f73b7ab349adff2c1ceb
Remediation Commit5f981b084e266c0850d7b80e12a3aab65a08685d
Remediation Commit0b97c95d263d2d8959b71c6c3b4d32b221c8d4db
Final Commitdd10677bffbccc51f975d79bbef9d4c122a18e7f
Whitepaperhttps://www.vechain.org/assets/whitepaper/whitepaper-3-0.pdf
Requirementshttps://docs.stargate.vechain.org
Technical RequirementsREADME.md

Assets in Scope

packages
contracts
contracts
deprecated
StargateNFT
V2
libraries
ClockV2.sol - packages › contracts › contracts › deprecated › StargateNFT › V2 › libraries › ClockV2.sol
DataTypesV2.sol - packages › contracts › contracts › deprecated › StargateNFT › V2 › libraries › DataTypesV2.sol
ErrorsV2.sol - packages › contracts › contracts › deprecated › StargateNFT › V2 › libraries › ErrorsV2.sol
LevelsV2.sol - packages › contracts › contracts › deprecated › StargateNFT › V2 › libraries › LevelsV2.sol
MintingLogicV2.sol - packages › contracts › contracts › deprecated › StargateNFT › V2 › libraries › MintingLogicV2.sol
SettingsV2.sol - packages › contracts › contracts › deprecated › StargateNFT › V2 › libraries › SettingsV2.sol
TokenV2.sol - packages › contracts › contracts › deprecated › StargateNFT › V2 › libraries › TokenV2.sol
VetGeneratedVthoV2.sol - packages › contracts › contracts › deprecated › StargateNFT › V2 › libraries › VetGeneratedVthoV2.sol
StargateNFTV2.sol - packages › contracts › contracts › deprecated › StargateNFT › V2 › StargateNFTV2.sol
Stargate.sol - packages › contracts › contracts › Stargate.sol
StargateNFT
libraries
Clock.sol - packages › contracts › contracts › StargateNFT › libraries › Clock.sol
DataTypes.sol - packages › contracts › contracts › StargateNFT › libraries › DataTypes.sol
Errors.sol - packages › contracts › contracts › StargateNFT › libraries › Errors.sol

Appendix 3. Additional Valuables

Verification of System Invariants

During the audit of Vechain Stargate, Hacken followed its methodology by performing invariant-testing on the project's main functions. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use invariant-testing to ensure that several system invariants hold true in all situations.

Invariant

Test Name

Test Result

INV-01 One-Click Process (Migrate + Auto-Delegate)should migrate and auto-delegate in a single transactionPassed
INV-01 One-Click Process (Migrate + Auto-Delegate)should revert if payment is incorrectPassed
INV-02 Payment Validation (Exact VET Amount)should accept exact VET amount for levelPassed
INV-02 Payment Validation (Exact VET Amount)should revert with insufficient paymentPassed
INV-02 Payment Validation (Exact VET Amount)should revert with excess paymentPassed
INV-03 Legacy NFT Burningshould burn legacy NFT during migrationPassed
INV-04 New Token Minting with Preserved Attributesshould mint new StargateNFT with same token IDPassed
INV-04 New Token Minting with Preserved Attributesshould preserve token level after migrationPassed
INV-05 Preserving Attributes (Node Level, Token ID)should preserve token ID during migrationPassed
INV-05 Preserving Attributes (Node Level, Token ID)should preserve node level during migrationPassed
INV-06 Delegation After Migration (Auto-Delegation)should automatically delegate to specified validatorPassed
INV-07 Irreversibility of Migrationshould not allow double migration of same tokenPassed
INV-07 Irreversibility of Migrationshould permanently burn legacy NFTPassed
INV-08 No Migration During Auctionshould prevent migration if token is on auctionPassed
INV-09 Post-Migration Verificationshould verify new token exists after migrationPassed
INV-09 Post-Migration Verificationshould verify legacy token is fully burnedPassed
INV-10 Dynamic Cap Management During Migrationshould increase cap during migrationPassed
INV-10 Dynamic Cap Management During Migrationshould increase circulating supply during migrationPassed
INV-11 One-Time Migration Enforcementshould prevent re-migration of already migrated tokenPassed
  • Invariant

    INV-01 One-Click Process (Migrate + Auto-Delegate)

    Test Name

    should migrate and auto-delegate in a single transaction

    Test Result

    Passed

    Invariant

    INV-01 One-Click Process (Migrate + Auto-Delegate)

    Test Name

    should revert if payment is incorrect

    Test Result

    Passed

    Invariant

    INV-02 Payment Validation (Exact VET Amount)

    Test Name

    should accept exact VET amount for level

    Test Result

    Passed

    Invariant

    INV-02 Payment Validation (Exact VET Amount)

    Test Name

    should revert with insufficient payment

    Test Result

    Passed

    Invariant

    INV-02 Payment Validation (Exact VET Amount)

    Test Name

    should revert with excess payment

    Test Result

    Passed

    Invariant

    INV-03 Legacy NFT Burning

    Test Name

    should burn legacy NFT during migration

    Test Result

    Passed

    Invariant

    INV-04 New Token Minting with Preserved Attributes

    Test Name

    should mint new StargateNFT with same token ID

    Test Result

    Passed

    Invariant

    INV-04 New Token Minting with Preserved Attributes

    Test Name

    should preserve token level after migration

    Test Result

    Passed

    Invariant

    INV-05 Preserving Attributes (Node Level, Token ID)

    Test Name

    should preserve token ID during migration

    Test Result

    Passed

    Invariant

    INV-05 Preserving Attributes (Node Level, Token ID)

    Test Name

    should preserve node level during migration

    Test Result

    Passed

    Invariant

    INV-06 Delegation After Migration (Auto-Delegation)

    Test Name

    should automatically delegate to specified validator

    Test Result

    Passed

    Invariant

    INV-07 Irreversibility of Migration

    Test Name

    should not allow double migration of same token

    Test Result

    Passed

    Invariant

    INV-07 Irreversibility of Migration

    Test Name

    should permanently burn legacy NFT

    Test Result

    Passed

    Invariant

    INV-08 No Migration During Auction

    Test Name

    should prevent migration if token is on auction

    Test Result

    Passed

    Invariant

    INV-09 Post-Migration Verification

    Test Name

    should verify new token exists after migration

    Test Result

    Passed

    Invariant

    INV-09 Post-Migration Verification

    Test Name

    should verify legacy token is fully burned

    Test Result

    Passed

    Invariant

    INV-10 Dynamic Cap Management During Migration

    Test Name

    should increase cap during migration

    Test Result

    Passed

    Invariant

    INV-10 Dynamic Cap Management During Migration

    Test Name

    should increase circulating supply during migration

    Test Result

    Passed

    Invariant

    INV-11 One-Time Migration Enforcement

    Test Name

    should prevent re-migration of already migrated token

    Test Result

    Passed

Additional Recommendations

The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.

To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:

  • Detecting changes to ownership or critical permissions.

  • Monitoring large or unexpected transactions and minting events.

  • Pausing operations when irregularities are identified.

These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.

Frameworks and Methodologies

This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment , and the Penetration Testing Execution Standard (PTES) , These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.

Disclaimer

Vechain Foundation audit by Hacken