60318 sc low zero cost boost bypass for new levels

Submitted on Nov 21st 2025 at 10:34:35 UTC by @dray for Audit Comp | Vechain | Stargate Hayabusaarrow-up-right

  • Report ID: #60318

  • Report Type: Smart Contract

  • Report severity: Low

  • Target: https://github.com/immunefi-team/audit-comp-vechain-stargate-hayabusa/tree/main/packages/contracts/contracts/Stargate.sol

  • Impacts:

    • Theft of unclaimed yield

    • Contract fails to deliver promised returns, but doesn't lose value

Description

Brief/Intro

The StargateNFT contract allows privileged operators to add new NFT levels via addLevel() at any time after deployment. However, the contract provides no mechanism to configure the boostPricePerBlock for these newly added levels, causing it to remain at the default value of 0. This allows any user to bypass the maturity period for new levels without paying the intended VTHO fee, gaining an unfair economic advantage in the staking reward distribution.

Vulnerability Details

Root Cause

Location: packages/contracts/contracts/StargateNFT/StargateNFT.sol (lines 303-307) and packages/contracts/contracts/StargateNFT/libraries/MintingLogic.sol (lines 117-145)

  1. addLevel() is callable post-deployment: The function is protected only by LEVEL_OPERATOR_ROLE and can be invoked at any time to introduce new NFT tiers. Each level includes a maturityBlocks parameter that defines how long an NFT must wait before it can participate in delegation and earn rewards.

  2. No way to set boost price for new levels: The boostPricePerBlock mapping, which determines the VTHO cost to skip the maturity period, defaults to 0 for all levels. While initializeV3 sets prices for initial levels, there is no public function to configure prices for levels added afterward. The V3 changelog explicitly states:

    This means updateLevelBoostPricePerBlock is not exposed externally.

  3. Boost calculation uses zero price: When a user calls boost(tokenId), the system computes the required VTHO via:

    For new levels, boostPricePerBlock[levelId] == 0, so requiredBoostAmount == 0. The balance and allowance checks trivially pass, and the maturity period is immediately cleared.

Affected Code

StargateNFT.sol (lines 303-307):

MintingLogic.sol (lines 117-145, boostOnBehalfOf):

MintingLogic.sol (lines 382-391, _boostAmount):

Impact Details

  1. Unfair Reward Advantage: Users who exploit the zero-cost boost can delegate their NFTs immediately and begin earning protocol rewards one or more periods earlier than the intended design. For high-VET tiers, this translates to significant VTHO gains at the expense of other stakers.

  2. Reward Dilution: Early entry into the reward pool dilutes the share of honest users who either wait out the maturity period or pay the intended VTHO fee to boost. The exploiter captures a larger portion of the delegator rewards for the affected period.

  3. Protocol Design Violation: The maturity period exists to prevent instant farming and to charge a premium (via VTHO burn) for early participation. Bypassing this mechanism undermines the tokenomics and fairness model.

References

  • StargateNFT.sol: Exposes addLevel but no setter for boost price.

  • Levels.sol: Contains updateLevelBoostPricePerBlock logic but is not exposed externally.

  • MintingLogic.sol: boostOnBehalfOf and _boostAmount rely on the boostPricePerBlock mapping, which remains 0 for new levels.

  • Stargate.sol: Entry point for minting and delegation; users can exploit the bypass to gain early access to reward distribution.

Proof of Concept

Proof of Concept

Was this helpful?