StarGate is the gateway to staking in the next era of the VeChainThor blockchain, marking a major milestone in the Hayabusa upgrade under the VeChain Renaissance initiative. It’s a next-generation staking protocol designed to give VET holders an active role in securing the network and earning rewards through NFT-based staking and delegation.
Evaluating
Triaged by Immunefi
Runnable PoC Required
KYC required
This Audit Competition Is Under Evaluation
Thank You to All Participating Security Researchers!
The audit competition has now concluded and is currently in the evaluation phase. During this period, all submitted reports are being carefully reviewed by the Immunefi triage team and the project team.
Rewards
Rewards by Threat Level
Rewards are distributed among SRs according to Immunefi’s Standardized Competition Reward Terms and includes All Star Pool and Podium Pool reserved for All Star Program participants.
Rewards are denominated in USD and distributed in USDT on Ethereum.
The reward pool is $40,000 USD if any bug is found. That means that even if 1 Low severity bug is found, the whole reward pool is unlocked and has to be fully distributed between security researchers.
If not a single bug is found (Insights do not count as bugs) the reward pool is $6,000 USD.
KYC Requirement
VeChain requires KYC information to pay for bug submissions. The following information will be required: Full name Date of birth Proof of address (either a redacted bank statement with address or a recent utility bill) Copy of Passport or other Government issued ID Security researchers are required to submit KYC within 14 days of KYC being requested, else their rewards may be forfeited. Immunefi may make exceptions due to extenuating circumstances.
Program Overview
StarGate is the gateway to staking in the next era of the VeChainThor blockchain, marking a major milestone in the Hayabusa upgrade under the VeChain Renaissance initiative. It’s a next-generation staking protocol designed to give VET holders an active role in securing the network and earning rewards through NFT-based staking and delegation.
Key Features
- NFT-Based Staking: Users stake VET to mint unique staking NFTs, which represent their locked position and can be delegated to validator nodes.
- Earn VTHO: Delegators earn a share of block rewards (in VTHO) every time their selected validator produces a block, based on the amount and type of NFT staked.
- Decentralized Access: Any VET holder can participate in the network by staking and delegating to validators—no need to run a full node.
Powering Hayabusa's Delegated Proof of Stake
The Hayabusa hard fork introduces Delegated Proof of Stake (dPoS) to VeChainThor, enabling a network of 101 validators who rotate to produce blocks and secure the chain. StarGate integrates directly with this system, serving as the onboarding layer for validators and delegators alike. Whether you're running a validator machine or holding VET, StarGate turns every user into a contributor to network security—bringing performance, transparency, and reward opportunities to all.
The Hayabusa hard fork introduces Delegated Proof of Stake (dPoS) to VeChainThor, enabling a network of 101 validators who rotate to produce blocks and secure the chain. StarGate integrates directly with this system, serving as the onboarding layer for validators and delegators alike. Whether you're running a validator machine or holding VET, StarGate turns every user into a contributor to network security—bringing performance, transparency, and reward opportunities to all.
For more information about VeChain, please visit https://vechain.org/.
VeChain is running an audit in parallel. However, submitted reports depicting the same issues raised in the audit will be confirmed.
Known Issues
KYC required
The submission of KYC information is a requirement for payout processing.
Proof of Concept
Proof of concept is always required for all severities.
Prohibited Activities
- Any testing on mainnet or public testnet deployed code; all testing should be done on local-forks of either public testnet or mainnet
- Any testing with pricing oracles or third-party smart contracts
- Attempting phishing or other social engineering attacks against our employees and/or customers
- Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
- Any denial of service attacks that are executed against project assets
- Automated testing of services that generates significant amounts of traffic
- Public disclosure of an unpatched vulnerability in an embargoed bounty
- Any other actions prohibited by the Immunefi Rules
Feasibility Limitations
The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity.
Therefore, Immunefi has developed a set of feasibility limitation standards which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.