The short version

I took part in the OneShot audit contest on Codehawks and reported two High-severity vulnerabilities regarding a game-theory flaw in their matchmaking process. However, the judge did not agree, calling the protocol implementation a "design decision" instead of a vulnerability.
In the litigation period, I submitted my thoughts concerning how this design decision would actually cause the protocol to come to a full halt, given enough time, but my concerns were disregarded saying the protocol was simply mimicking the real world approach.

Now, I do understand the will to make things look like they are in the real world, but let's be honest. It's a protocol on a blockchain. An environment where there are no secrets and the strength of two foes is measured with a mathematical number. It is not often the case that you get to go around your town and think to yourself "Mark over there clearly possesses a strength of 8, I can totally overtake him with my strength level 10", or is it?
Down here I reported my submissions, judge for yourself, but more importantly, enjoy the read!

Matchmaking mechanism hinders participation to the protocol

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.

# A Brief Pause
This is the second submission that is related to the matter at hand. This is another design decision that can bring the protocol to a halt, as more and more players eventually realize that the battle mechanism of the protocol is rigged. This time though, we exploit back-running to increase our chances of winning a battle and, thus, the staked bet.
Here is the second report, enjoy!

Back-running increases chances of success

Summary

An attacker can back-run other players to increase their chance of victory.

Vulnerability Details

An attacker, when the smart contracts are deployed on the Ethereum blockchain, can monitor the mempool in order to:

• enter in a battle anytime another player with a "weak" NFT enters the stage waiting for a challenge, using their own "stronger" NFT. In this scenario, as the attacker owns a "stronger" NFT, they can also front-run the other player and enter the stage first;
• enter in a battle anytime another player with a "weak" NFT enters the stage waiting for a challenge, using a "strong" NFT they do not own, exploiting an already reported issue that the second challenger to enter a battle can use any rapper pre-approved to battle, even if they do not own it.

Impact

Using this approach, an attacker can significantly increase their chances of winning the bet staked for the battle, repeatedly gaining more and more NFTs while reducing their risk of ever losing some.

Tools Used

Manual review, VSCode

Recommendations

Using a commit-and-reveal scheme for challengers to participate in the battle would solve this issue, as no challenger would be able to know the skill level of their rival beforehand.