Skip to content

Latest commit

 

History

History
54 lines (36 loc) · 3.62 KB

File metadata and controls

54 lines (36 loc) · 3.62 KB

Cool Mango Bobcat

Medium

Market Initialization State Manipulation in LMSR Pricing System due to Fixed Initial Vote Count

Summary

A critical vulnerability exists in the ReputationMarket contract's market creation mechanism where all new markets are initialized with exactly 1 trust and 1 distrust vote, regardless of their configuration tier. This creates a severe price manipulation opportunity, particularly in higher-tier markets designed for stability.

The vulnerability stems from the hardcoding of initial votes in _createMarket():

https://github.com/sherlock-audit/2024-12-ethos-update/blob/main/ethos/packages/contracts/contracts/ReputationMarket.sol#L346

markets[profileId].votes[TRUST] = 1;
markets[profileId].votes[DISTRUST] = 1;

The impact is that it enables direct value extraction from other users through price manipulation, permanently corrupts market price discovery mechanisms, and is easily exploitable with significant profit potential.

Proof of Concept

The attack exploits the mismatch between the LMSR pricing mechanism's expectations of liquidity and the actual initial state of the market. When a premium market is created with a liquidity parameter of 100000 but only 1 initial vote on each side, the price impact of initial trades becomes severely magnified.

An attacker can exploit this by creating a premium market and immediately purchasing a large number of trust votes when the market is in its artificial low-liquidity state. The LMSR formula, operating on the 1:1 initial ratio, will produce extreme price movements from this first large purchase. This manipulation establishes a new, artificially inflated price baseline that subsequent users must trade against.

The market's intended price stability mechanisms become ineffective because the fundamental relationship between the liquidity parameter and vote counts has been corrupted from inception. The high liquidity parameter of premium markets, paradoxically, makes them more vulnerable as the gap between intended and actual initial liquidity is larger.

The attack's profitability derives from the difference between the artificially low initial purchase price and the manipulated prices that subsequent users face. The attacker's cost basis (market creation fee plus initial vote purchase) is significantly lower than the manipulated market prices, creating a profitable exit opportunity through gradually selling votes to later participants.

Recommended Mitigation Steps

The vulnerability can be addressed by ensuring market initialization properly reflects the intended stability characteristics of each market tier. This requires modifying the MarketConfig structure to include initial vote counts:

struct MarketConfig {
    uint256 liquidity;
    uint256 basePrice;
    uint256 creationCost;
    uint256 initialVotes;  // Add initial vote parameter
}

The market initialization logic should then use these configuration-specific initial votes rather than hardcoded values:

function _createMarket(uint256 profileId, address recipient, uint256 marketConfigIndex) private {
    MarketConfig memory config = marketConfigs[marketConfigIndex];
    markets[profileId].votes[TRUST] = config.initialVotes;
    markets[profileId].votes[DISTRUST] = config.initialVotes;
}

The relationship between liquidity parameters and initial votes should be enforced through a minimum ratio requirement, ensuring that higher-tier markets maintain their intended price stability characteristics from inception. This prevents the exploitation of artificial low-liquidity states while preserving the market's ability to reflect genuine changes in sentiment.