Core Contracts

Summary

The RAACReleaseOrchestrator contract is documented to manage the vesting and release of tokens for 65% of the total supply. However, the constructor initializes category allocations that sum to 65.1% of the total supply. This discrepancy indicates a miscalculation in the allocation parameters, which could result in an unintended token distribution that deviates from the project’s specified distribution plan.

Vulnerability Details

1. Allocation Initialization in Constructor:

   The constructor sets the following category allocations:

   categoryAllocations[TEAM_CATEGORY] = 18_000_000 ether; // 18%

   categoryAllocations[ADVISOR_CATEGORY] = 10_300_000 ether; // 10.3%

   categoryAllocations[TREASURY_CATEGORY] = 5_000_000 ether; // 5%

   categoryAllocations[PRIVATE_SALE_CATEGORY] = 10_000_000 ether; // 10%

   categoryAllocations[PUBLIC_SALE_CATEGORY] = 15_000_000 ether; // 15%

   categoryAllocations[LIQUIDITY_CATEGORY] = 6_800_000 ether; // 6.8% (5.8% + 1%)

2. Calculation Discrepancy:

   • When summing the percentages:

     • TEAM: 18%

     • ADVISOR: 10.3%

     • TREASURY: 5%

     • PRIVATE SALE: 10%

     • PUBLIC SALE: 15%

     • LIQUIDITY: 6.8%

   The total allocation is:

   18 + 10.3 + 5 + 10 + 15 + 6.8 = 65.1%

   • Intended Distribution: According to the documentation, the vesting is intended to manage 65% of the total supply.

   • Actual Distribution: The initialized allocations sum to 65.1%, which means an extra 0.1% of the total token supply is allocated.

3. Documentation vs. Implementation Mismatch:

   • The documentation explicitly states that the vesting schedules are set up for 65% of the total token supply.

   • The miscalculati

Impact

• Tokenomics Deviation:
  An extra 0.1% of the total supply is allocated beyond the documented 65%, potentially affecting token distribution and the overall tokenomics model.

Proof-of-Concept (POC) Example

Assume:

• The total token supply is 100,000,000 tokens.

• According to documentation, the vesting orchestrator should manage 65% (i.e., 65,000,000 tokens).

• However, the initialized allocations sum up to:

  • TEAM: 18,000,000 tokens

  • ADVISOR: 10,300,000 tokens

  • TREASURY: 5,000,000 tokens

  • PRIVATE SALE: 10,000,000 tokens

  • PUBLIC SALE: 15,000,000 tokens

  • LIQUIDITY: 6,800,000 tokens

• Total = 18,000,000 + 10,300,000 + 5,000,000 + 10,000,000 + 15,000,000 + 6,800,000 = 65,100,000 tokens.

Result:
An additional 100,000 tokens (0.1% of total supply) are allocated, contradicting the documented 65% allocation.

Tools Used

Manual review

Recommendations

1. Recalculate Allocations:

   • Adjust one or more category allocations to ensure the total equals exactly 65% of the total token supply.

   • For example, consider reducing the ADVISOR or LIQUIDITY allocation by the equivalent of 0.1% (e.g., reduce ADVISOR from 10,300,000 to 10,200,000 tokens if that aligns with overall distribution goals).

2. Update Documentation:

   • If the extra 0.1% is intentional, update the documentation to accurately reflect the token distribution as 65.1%.

   • Ensure all stakeholders are aware of the precise token allocation to avoid confusion.