057.md

Slow Tan Swallow

Medium

sellVotes is lacking slippage protection

Summary

Unlike buyVotes it's opposite sellVotes lacks slippage protection.

https://github.com/sherlock-audit/2024-11-ethos-network-ii/blob/main/ethos/packages/contracts/contracts/ReputationMarket.sol#L446

  function buyVotes(
    uint256 profileId,
    bool isPositive,
    uint256 expectedVotes,
    uint256 slippageBasisPoints
  ) public payable whenNotPaused activeMarket(profileId) nonReentrant {
    // ...
    _checkSlippageLimit(votesBought, expectedVotes, slippageBasisPoints);
     // ...
  }

https://github.com/sherlock-audit/2024-11-ethos-network-ii/blob/main/ethos/packages/contracts/contracts/ReputationMarket.sol#L495

  function sellVotes(
    uint256 profileId,
    bool isPositive,
    uint256 amount
    //@audit no slippage protection
  ) public whenNotPaused activeMarket(profileId) nonReentrant {

This will put users in danger as selling votes decreases their price, and such if a user sells too many votes he can decrease his vote price bellow the one he is willing to get for selling, resulting in him selling, but receiving little to nothing. Same can be done if a TX of another sells happens before ours, where our user would sell at a starting lower price and further decrease his profit.

Root Cause

sellVotes lacking slippage protection, while buyVotes has it

Internal pre-conditions

No response

External pre-conditions

No response

Attack Path

1. Bob make a TX to sell 50 votes
2. Alice also makes a TX to sell 500 votes
3. Alice TX gets executed first, meaning Bob sells at a much lower price

If Bob knew his actual sell price he wouldn't sell.

Impact

Users lose funds when selling.

PoC

No response

Mitigation

Add slippage protection, requiring the profit to be above a given amount (can be calculated off chain or in the front end).