Core Contracts

Regnum Aurum Acquisition Corp
HardhatReal World AssetsNFT
77,280 USDC
View results
Submission Details
Severity: medium
Valid

MintRewards reverts because of wrong excessToken accounting in tick function

Summary

In the tick function, tokens are minted directly to the StabilityPool but the minted amount is also added to the excessTokens variable. Later, in the mintRewards function, excessTokens is used to determine if additional tokens need to be minted to this contract in order to transfer rewards. Since the tokens minted in tick are sent to the StabilityPool and not held by the RAACMinter contract, the contract’s internal accounting of excessTokens overestimates the tokens available. This discrepancy can cause the mintRewards function to attempt a transfer that reverts because the contract lacks sufficient tokens.

Vulnerability Details

  1. Token Minting in tick:

    In the tick function, when amountToMint is calculated, the following operations occur:

    if (amountToMint > 0) {
    // Add minted tokens to excessTokens for future distribution
    excessTokens += amountToMint;
    lastUpdateBlock = currentBlock;
    // Tokens are minted to the StabilityPool
    raacToken.mint(address(stabilityPool), amountToMint);
    emit RAACMinted(amountToMint);
    }

    Here, amountToMint is added to excessTokens, implying these tokens are available for reward transfers. However, the tokens are minted to the stabilityPool rather than to the RAACMinter contract.

  2. Reward Distribution in mintRewards:

    In the mintRewards function, the contract uses excessTokens to determine if additional minting is needed:

    uint256 toMint = excessTokens >= amount
    ? 0
    : amount - excessTokens;
    excessTokens = excessTokens >= amount
    ? excessTokens - amount
    : 0;
    if (toMint > 0) {
    raacToken.mint(address(this), toMint);
    }
    raacToken.safeTransfer(to, amount);
    emit RAACMinted(amount);

    This logic assumes that excessTokens reflects tokens held by the contract. In reality, tokens minted in tick were sent to the StabilityPool, so the RAACMinter contract's balance might be insufficient to satisfy the safeTransfer.

  3. Consequences:

    • False Availability:
      The contract erroneously believes it holds extra tokens (tracked by excessTokens), even though those tokens are located at the StabilityPool address.

    • Transfer Revert:
      When mintRewards calls raacToken.safeTransfer(to, amount), it may revert because the RAACMinter contract doesn’t actually hold the tokens it expects based on excessTokens.

Proof-of-Concept (POC) Example

Assume:

  • The tick function calculates amountToMint = 100 tokens.

  • These 100 tokens are minted to the StabilityPool.

  • The contract then sets excessTokens += 100.

Later, when mintRewards is called with amount = 50:

  1. The contract computes:

    • Since excessTokens (100) >= amount (50), it sets:

      • toMint = 0

      • excessTokens = excessTokens - amount = 100 - 50 = 50

  2. The function then attempts:

    raacToken.safeTransfer(to, 50);
  3. However, the RAACMinter contract’s own balance does not include these 100 tokens (they reside in the StabilityPool), so the transfer fails due to insufficient balance.

Impact

  • Reversion of Reward Transfers:*
    The mismatch causes the mintRewards function to revert because it attempts to transfer tokens that aren’t actually held by the RAACMinter contract.

  • Inaccurate Accounting:
    The internal accounting (excessTokens) does not accurately reflect the contract's token balance, leading to potential inconsistencies in token distribution.

  • Potential Denial-of-Service:
    Repeated failures in reward transfers may disrupt the normal operation of the reward distribution mechanism, affecting users relying on timely rewards.

Tools Used

Manual review

Recommendations

  1. Align Minting Destination with Accounting:

    • Either mint tokens directly to the RAACMinter contract in the tick function (so that excessTokens accurately reflects tokens available for transfer), or adjust the accounting to exclude tokens minted to the StabilityPool.

  2. Separate Accounting:

    • Maintain separate accounting for tokens minted to the StabilityPool and tokens held by the RAACMinter contract, ensuring that mintRewards only considers tokens actually available for transfer.

Updates

Lead Judging Commences

inallhonesty Lead Judge 3 months ago
Submission Judgement Published
Validated
Assigned finding tags:

RAACMinter wrong excessTokens accounting in tick function

inallhonesty Lead Judge 3 months ago
Submission Judgement Published
Validated
Assigned finding tags:

RAACMinter wrong excessTokens accounting in tick function

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.