First Flight #10: One Shot

Summary

The matchmaking process implemented for battles would lead to a stall, where all protocol users await for others to first enter the stage, in order to evaluate whether it is worth it or not to battle.

Vulnerability Details

In the current implementation, the matchmaking process works as follows:

• a user decides to battle using one of their NFTs

• they submit their will to battle, publically showing the NFT that will take part in the battle, and the bet representing the prize for the winner

This means that any potential attacker, or game-theory wise user, can wait for someone to enter the stage, evaluate their chances of winning, decide if the bet is high enough to be worth the risk of losing, and decide to participate or wait for another, future challenger to come in.

However, if EVERY user of the platform followed this logic, no-one would ever enter the stage first. And if no user ever enters the stage first, no battle will ever happen, meaning an entire, fundamental functionality of the protocol will be left unused.

Impact

The entire battling and betting functionality of the protocol will lose all users, as there is no advantage in joining the stage first, but only disadvantages, that will end up discouraging participation in the protocol.

Tools Used

Manual review, VSCode

Recommendations

Using a commit-and-reveal scheme would fix this issue, as the attackers (or game-theory wise users) would hold no significant advantage just by observing the mempool.