V2 Updates

In the reheat function the reserveSize is computed with a denominator of 100e18, however the minPortion and maxPortion are assigned to as .05 ether and .15 ether respectively in the constructor.

The comment on line 150 indicates that the portion ought to be 15% rather than 0.15%, therefore the portion is a factor of 100x smaller than it ought to be.

Use a denominator of 1e18 rather than 100e18.

Baseline Team: Resolved.

A malicious actor may significantly increase their odds of winning the YesArena at the end of the game time by using two addresses to ensure they control both the winner and hotPotato addresses and then submitting many transactions to stuff Blast blocks for the next 2 minutes.

For example:

• Bob calls deposit with address A, A is now the hot potato
• Bob calls deposit with address B, A is now the winner & B is the hot potato
• Bob submits many gas waster transactions to stuff the next 2 minutes of Blast blocks until he is

the winner

This can significantly reduce the chances that other actors have at getting a deposit call recorded before the 2 minutes is over.

Be aware of this risk, consider adding more time to the game for every deposit to make it more costly to block stuff the chain to improve winning odds.

Baseline Team: Pending.

In the claim function the claimed boolean is not assigned to true, therefore the system never indicates that the claim can occur.

As a result arbitrary users can trigger multiple transfers to the winner and emit the Claim event several times.

Assign the claimed boolean to true in the claim function.

Baseline Team: Pending.

The reheat function will buy YES and loop it when the random roll hits. However the random value is based upon the the block.timestamp and block.prevrandao which are both deterministically available at the block in which the reheat transaction is recorded.

In environments where front-running is possible, a malicious actor may create a contract which buys YES and reverts if the block.timestamp and block.prevrandao would not fulfill the random requirements.

This way the attacker can detect owner transactions to reheat and frontrun them in the same block to buy YES right before the price increases as a result of the reheat. The attacker can then back run the reheat and sell their YES tokens if a reheat looping was performed for a risk free immediate profit.

This is not an immediate concern on the Blast L2 network, however be sure to consider this risk before deploying to a network with high MEV activity.

Baseline Team: Pending.

In the YesArena contract there is no configuration for gas yields, however the YesArena contract is likely to accrue a nontrivial gas expenditure during the game.

Consider implementing appropriate configurations and functions to claim the gas yields that would accrue for the YesArena contract.

Baseline Team: Pending.

In the _buy function there is no slippage protection configured in the swap call. This allows malicious actors to sandwich the reheat transaction’s swap and extract value from the system.

The system is currently deployed on Blast which does not have a public mempool, so frontrunning sandwich vectors are not an immediate concern.

However upon deploying to new chains, carefully consider this risk and implement the necessary swap protections to mitigate the sandwich attack vector.

Baseline Team: Pending.

The mm and cf addresses are declared immutable in the AfterBurner contract, however In the event that the MarketMaking or CreditFacility contracts are upgraded, a new AfterBurner contract would need to be deployed. This may become unwieldy and incur the team unnecessary deploy expenses over time.

Consider implementing functions to update the cf and mm addresses, and be sure that the owner address is a multi-sig. Otherwise if trust of the owner is a concern, do not add these functions and be aware that the AfterBurner should be re-deployed with funds ported over in the event of a MarketMaking or CreditFacility contract upgrade.

Baseline Team: Pending.

In the YesArena contract constructor there is no validation that the GROWTH_RATE is correctly assigned to a value greater than 1e18. If the GROWTH_RATE value is assigned to less than 1e18 it will result in a smaller deposit price over time. Similarly, there is no validation requiring the FEE_RATE to be a reasonable proportion of 1e18.

Consider implementing validations such that the GROWTH_RATE cannot be assigned to a value less than 1e18 and the FEE_RATE cannot be above a certain threshold.

Baseline Team: Pending.

In the YesArena contract the afterburner address is hardcoded as the existing afterburner contract, which does not include the latest updates.

Consider making the afterburner address configurable within the constructor. Otherwise be sure to update this address in the YesArena contract before deployment.

Baseline Team: Pending.

The UNLOCK_TIMESTAMP may occur within the gameTime period if enough deposits are made, as a result the winner will be able to claim the jackpot immediately after winning.

Consider if this is expected behavior, if it is not then consider altering the unlock time validation such that it validates that a certain amount of time has passed since the end of the game time period.

Baseline Team: Pending.

In the deposit function a pseudo random value is generated to be emitted with the Deposited event for the deposit. However this random value is generated based upon values that apply to the entire block, not just the particular transaction being executed.

As a result several deposits within the same block will have the same random value associated with them in the Deposited event.

Consider if this is the expected behavior, otherwise consider seeding the deposit with values that can distinguish each deposit within a single block from each other, such as the depositNumber.

Baseline Team: Pending.

In the deposit function the Deposited event emits the depositPrice as the amount variable, however this is not the amount which the caller paid as the depositPrice was subsequently increased by the growth rate.

Consider caching the depositPrice variable at the beginning of the deposit function and emitting this as the amount in the Deposited event.

Additionally, use this cached depositPrice stack variable to perform the deposit validation, transfers, and new depositPrice calculation to save gas in the deposit function.

Baseline Team: Pending.

In the Afterburner contract any yield for the weth reserve assets held in the Afterburner will automatically be included in the reheat actions as they will automatically be applied to the Afterburner contract balance.

This may be expected, however it is worth pointing out as the protocol may wish to claim these yields instead of having them automatically attributed to each reheat.

Consider if the weth yields should be applied to reheat actions, otherwise implement logic in the constructor such that the yield mode is claimable and a trusted address may withdraw these yields for the protocol.

Baseline Team: Pending.

In the reheat function the hit value is determined based on roll % probabilityDenominator == 69, however the roll value has already been modded by the probabilityDenominator and incremented by 1.

Therefore modding by the probabilityDenominator a second time only maps rolls of 100 to 0, and therefore will not affect the odds of a hit.

Remove the second module which occurs on line 142 as it is unnecessary.

Baseline Team: Pending.

In the Afterburner contract there are several owner configuration functions which lack important validations. For example, in the setSources function, the sources array should be validated to be within a reasonable length such that the reheat function cannot be accidentally or maliciously DoS’d due to an extremely long sources array.

In the setPortionBounds and setDelayBounds functions there is no validation that the configured min bound is less than the max bound. And the setProbabilityDenominator does not validate that the denominator is nonzero.

Consider implementing the suggested validations to protect against accidental assignments or owner compromises.

Baseline Team: Pending.