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 | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Vechain Foundation |
| Audited By | , Stepan Chekhovskoi |
| Approved By | Ivan Bondar |
| Website | https://www.vechain.org→ |
| 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 |
| Methodology | https://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
- Website
- https://www.vechain.org→
- 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
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/vechain/stargate→ |
| Initial Commit | 74f2662 |
| Remediation Commit | 5f981b0 |
| Remediation Commit | 0b97c95 |
| Final Commit | dd10677 |
Review Scope
- Repository
- https://github.com/vechain/stargate→
- Initial Commit
- 74f2662
- Remediation Commit
- 5f981b0
- Remediation Commit
- 0b97c95
- Final Commit
- dd10677
Audit Summary
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
StargateNFTcontract 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.sol: Manages 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.sol: Manages 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.sol: Provides 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 storageWhitelist entry structure for migration edge cases
Errors.sol: Centralizes 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 operationsunpause()- Resumes contract operations after pausesetMaxClaimablePeriods()- Updates the maximum claimable periods limit (currently 832)Manage roles via
grantRole()andrevokeRole()
UPGRADER_ROLE can call:
upgradeTo()/upgradeToAndCall()- Upgrades the contract implementation
onlyTokenOwner modifier for user-specific operations:
unstake()- Only NFT owner can unstakedelegate()- Only NFT owner can delegaterequestDelegationExit()- Only NFT owner can request exit
StargateNFT Contract Roles
DEFAULT_ADMIN_ROLE can:
Manage all other roles via
grantRole()andrevokeRole()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 transfersunpause()- Resumes NFT operations
LEVEL_OPERATOR_ROLE can:
updateLevel()- Updates existing level parameters (VET requirement, rewards, maturity)updateLevelCap()- Updates the maximum supply cap for a leveladdLevel()- 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 stakeburn()- Burns NFTs when users unstakeboostOnBehalfOf()- Skips maturity period forstakeAndDelegate()
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-1478 | Rewards Drain due to Invalid Last Claimed Period Update | fixed | Critical | |
| F-2025-1378 | Missing Effective Stake Decrease During Unstake | fixed | High | |
| F-2025-1372 | Permanent 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-1378 | Unauthorized Delegation via migrateAndDelegate() Function | fixed | Medium | |
| F-2025-1370 | ERC-7201 Storage Location Comment Does Not Match Actual Value | fixed | Medium | |
| F-2025-1359 | Off-By-One Error in _exceedsMaxClaimablePeriods() Allows Claiming One Extra Period Beyond Configured Maximum | fixed | Medium | |
| F-2025-1351 | Storage Inconsistency in migrateTokenManager Function Leading to Data Corruption | fixed | Medium | |
| F-2025-1379 | Potential Precision Loss on Reward Claim | fixed | Low |
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 | |
|---|---|
| Repository | https://github.com/vechain/stargate→ |
| Initial Commit | 74f2662e742af94882e3f73b7ab349adff2c1ceb |
| Remediation Commit | 5f981b084e266c0850d7b80e12a3aab65a08685d |
| Remediation Commit | 0b97c95d263d2d8959b71c6c3b4d32b221c8d4db |
| Final Commit | dd10677bffbccc51f975d79bbef9d4c122a18e7f |
| Whitepaper | https://www.vechain.org/assets/whitepaper/whitepaper-3-0.pdf→ |
| Requirements | https://docs.stargate.vechain.org→ |
| Technical Requirements | README.md |
Scope Details
- Repository
- https://github.com/vechain/stargate→
- Initial Commit
- 74f2662e742af94882e3f73b7ab349adff2c1ceb
- Remediation Commit
- 5f981b084e266c0850d7b80e12a3aab65a08685d
- Remediation Commit
- 0b97c95d263d2d8959b71c6c3b4d32b221c8d4db
- Final Commit
- dd10677bffbccc51f975d79bbef9d4c122a18e7f
- Requirements
- https://docs.stargate.vechain.org→
- Technical Requirements
- README.md
Assets in Scope
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 transaction | Passed |
| INV-01 One-Click Process (Migrate + Auto-Delegate) | should revert if payment is incorrect | Passed |
| INV-02 Payment Validation (Exact VET Amount) | should accept exact VET amount for level | Passed |
| INV-02 Payment Validation (Exact VET Amount) | should revert with insufficient payment | Passed |
| INV-02 Payment Validation (Exact VET Amount) | should revert with excess payment | Passed |
| INV-03 Legacy NFT Burning | should burn legacy NFT during migration | Passed |
| INV-04 New Token Minting with Preserved Attributes | should mint new StargateNFT with same token ID | Passed |
| INV-04 New Token Minting with Preserved Attributes | should preserve token level after migration | Passed |
| INV-05 Preserving Attributes (Node Level, Token ID) | should preserve token ID during migration | Passed |
| INV-05 Preserving Attributes (Node Level, Token ID) | should preserve node level during migration | Passed |
| INV-06 Delegation After Migration (Auto-Delegation) | should automatically delegate to specified validator | Passed |
| INV-07 Irreversibility of Migration | should not allow double migration of same token | Passed |
| INV-07 Irreversibility of Migration | should permanently burn legacy NFT | Passed |
| INV-08 No Migration During Auction | should prevent migration if token is on auction | Passed |
| INV-09 Post-Migration Verification | should verify new token exists after migration | Passed |
| INV-09 Post-Migration Verification | should verify legacy token is fully burned | Passed |
| INV-10 Dynamic Cap Management During Migration | should increase cap during migration | Passed |
| INV-10 Dynamic Cap Management During Migration | should increase circulating supply during migration | Passed |
| INV-11 One-Time Migration Enforcement | should prevent re-migration of already migrated token | Passed |
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.