The _totalAuctionTokenAllocation
and auction allocation token balances can be incorrectly updated when the same no-bid auction is recovered multiple times.
This causes subsequent auctions to use incorrect values for _totalAuctionTokenAllocation
and epochAuctionTokenAmount
.
Additionally, the SpiceAuction.recoverAuctionTokenForZeroBidAuction()
function does not record on-chain the epoch auction that was recovered, resulting in potential mistakes and causing the issue.
When the same no-bid auction is recovered multiple times, the _totalAuctionTokenAllocation
and auction allocation token balances are updated incorrectly.
This affects the allocation of tokens for subsequent auctions, leading to inability to start the subsequence auction or incorrect values being used in the auction token allocation for subsequent auctions.
The lack of on-chain recording in the SpiceAuction.recoverAuctionTokenForZeroBidAuction()
function increase the potentially occurs of this issue, as it allows for the possibility of repeated recoveries of the same auction epoch.
Inability to start subsequence auctions.
The incorrect updating of _totalAuctionTokenAllocation
can lead to improper token distribution in subsequent auctions.
onlyDAOExecutor: TempleDAO executor that can executes the SpiceAuction.recoverAuctionTokenForZeroBidAuction()
Alice: The auction starter (or any if config to zero address).
SpiceAuction: The SpiceAuction
contract
Scenario:
Initial State:
auctionToken
= TempleGold token
epochId: 1
auction has ended without bidding and can be recover
epochInfo(1).totalBidTokenAmount = 0
epochInfo(1).totalAuctionTokenAmount = 100e18
_totalAuctionTokenAllocation = 100e18
TempleGold.balanceOf(SpiceAuction) = 100e18
Step 1: 100e18
TGLD tokens is funded to the SpiceAuction
contract for the next auction.
Step 2: Alice starts new auction (epochId: 2
)
epochInfo(2).totalAuctionTokenAmount = 100e18
_totalAuctionTokenAllocation = 100e18 + 100e18 = 200e18
TempleGold.balanceOf(SpiceAuction) = 200e18
Step 3: onlyDAOExecutor recovers the epochId: 1
via the SpiceAuction.recoverAuctionTokenForZeroBidAuction()
_totalAuctionTokenAllocation = 200e18 - epochInfo(1).totalAuctionTokenAmount(100e18) = 100e18
TempleGold.balanceOf(SpiceAuction) = 200e18 - epochInfo(1).totalAuctionTokenAmount(100e18) = 100e18
Step 4: onlyDAOExecutor recovers the epochId: 1
again via the SpiceAuction.recoverAuctionTokenForZeroBidAuction()
_totalAuctionTokenAllocation = 100e18 - epochInfo(1).totalAuctionTokenAmount(100e18) = 0
TempleGold.balanceOf(SpiceAuction) = 100e18 - epochInfo(1).totalAuctionTokenAmount(100e18) = 0
Step 5: As the mistake in the Step 4, The protocol team attempt to transfer the TGLD back to the SpiceAuction
contract
TempleGold.balanceOf(SpiceAuction) = 0 + 100e18 = 100e18
Step 6: epochId: 2
auction ended with fully claiming 100e18 claimed auction tokens
_claimedAuctionTokens[auctionToken] = 100e18
TempleGold.balanceOf(SpiceAuction) = 100 - 100e18 = 0
Step 7: Alice attempts to start new auction (epochId: 3
) (no TGLD token funds in this auction)
As the _totalAuctionTokenAllocation
has incorrectly updated to 0 at Step 4. _totalAuctionTokenAllocation = 0
The epochAuctionTokenAmount
calculation will cause the revert.
Outcome: The epochId: 3
(subsequence auction) is unable to be started.
Implications:
This scenario describes the revert case as it drains the _totalAuctionTokenAllocation
to 0.
Let's consider the case where the _totalAuctionTokenAllocation
is not fully drained. The epochInfo
for subsequent auctions will use incorrect funds that should have been allocated for the previous epoch, as the allocation for that epoch was incorrectly updated.
Foundry
Manual Review
Modify the SpiceAuction.recoverAuctionTokenForZeroBidAuction()
function to include on-chain recording of recovered epoch auctions.
This ensures that each auction recovery is tracked and prevents multiple recoveries of the same epoch.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.