025.md

Refined Hotpink Sloth

Medium

Seller might acces initial market liquidity leading to loss of funds for users and temporary DOS

Summary

When we calculating price of votes we rounding down price for positive votes and rounding up for negative votes ReputationMarket.sol: _calcCost()

    cost = positiveCostRatio.mulDiv(
      market.basePrice,
      1e18,
      isPositive ? Math.Rounding.Floor : Math.Rounding.Ceil
    );

Current design choice let us keep the price of 1 negative + 1 positive = base price Meanwhile, it causes an issue if amount bought and sold varies. Let's consider an example: 1)user bought 3 negative votes in a single buyVotess() call. Price of his votes before rounding was 18158966749999999 (~0.018 eth), the price will be rounded by protocol to 18158966750000000 2)user sold 3 negative votes in 3 buyVotes() calls. The price before rounding will be: a)6,045,700,083,333,333.3 b)6,053,266,666,666,666.6 c)6,060,000,000,000,000.0 Total amount of prices AFTER rounding up will be 18158966750000001 Reversed situation will be with positive votes Even tho impact of these issues doesn't looks big it is important to note, in this Ethos update we changed rules for creating markets by admin ReputationMarket.sol : _createMarket()

    } else {
      // when an admin creates a market, there is no minimum creation cost; use whatever they sent
      marketFunds[profileId] = msg.value;
    }

In this update admin willing to send any amount of as initial liquidity, when it creating market for someone. This exactly means, admin is able to not send any funds at all (It is LEGIT activity for admin) moreover it seems there is no any incentives for admin to put protocol funds inside someone's else market pool.

Note: we assumed here, user is only trader for that market 1) a)Considering this fact our issue will cause a DOS of sellVotes() function to work with specific market, because if there was 0 or small amount of initial funds, and user bought few negative votes in bulk and then sold it one by one(or bought positive one by one and sold in bulk), market's funds won't be enough to pay for last vote. Exactly same thing will happens if user bought positive votes one by one and then sold it in bulk b)Markets with big trading volume will be affected more

2)Considering the fact, the actual price of votes depends on amounts user bought them we clarify that now 1 negative + 1 positive price will be equal to base price ONLY in case users bought same amounts of positive and negative votes, so it will break main invariant of protocol 3)User accessed initial liquidity, which also break invariant

Root Cause

ReputationMarket.sol: _calcCost()

    cost = positiveCostRatio.mulDiv(
      market.basePrice,
      1e18,
      isPositive ? Math.Rounding.Floor : Math.Rounding.Ceil
    );

and because the line bellow we might got market temprorary DOSed

ReputationMarket.sol : _createMarket()

    } else {
      // when an admin creates a market, there is no minimum creation cost; use whatever they sent
      marketFunds[profileId] = msg.value;
    }

Internal Pre-conditions

In reality dos of market will be possible in case admin will create market with small or 0 amount of funds as initial liquidity, as i mentioned before it is LEGIT activity for admin

External Pre-conditions

No response

Attack Path

1. User buy negative votes in bulk and sell them one by one or
2. User buy positive price one by one and sell them in bulk It is not benefit to 'attacker', but can happen occasionaly

Impact

1)temporary dos of sellVote() for specific market. If market funds 0 or low it will impossible to sell last vote 2)2 invariants broken

PoC

No response

Mitigation

i personally would keep the main root cause of issue untouched, since in is not makes real impact to the protocol funds but i would be fix process of creating market by admin and ensure he put common initial liquidity to the market while creating it