Skip to content

Latest commit

 

History

History
42 lines (24 loc) · 2.61 KB

042.md

File metadata and controls

42 lines (24 loc) · 2.61 KB

Shambolic Opaque Swift

Medium

Lack of deadline checks for vote orders can lead to stale or manipulated transactions

Summary

The absence of a deadline parameter or expiry mechanism for vote-buying/selling in ReputationMarket.sol leaves transactions open-ended. Without a time limit, user orders (minimumVotePrice, minVotesToBuy, maxVotesToBuy) can remain valid indefinitely, allowing front-running or execution under stale conditions that harm users expecting timely executions.

Root Cause

In ReputationMarket.sol#L440 and ReputationMarket.sol#L539, the parameters for buying/selling votes (e.g., minVotesToBuy, maxVotesToBuy, and minimumVotePrice) do not include or enforce a transaction deadline. Thus, a user’s trade can be left pending for an arbitrary duration, risking exploitation or unfavorable price changes.

Internal Pre-conditions

  1. The user initiates a buyVotes or sellVotes transaction specifying only minVotesToBuy, maxVotesToBuy, or minimumVotePrice—with no time-based constraint.
  2. The contract lacks any mechanism to invalidate or expire the transaction if not mined promptly.

External Pre-conditions

No response

Attack Path

  1. A user initiates a buyVotes or sellVotes transaction with certain price or vote constraints but no deadline.
  2. The transaction remains pending in the mempool due to low gas fees or congestion.
  3. Market conditions change (e.g., price fluctuations in the underlying asset), making the original min/max constraints stale.
  4. An MEV bot or malicious actor can time their blocks or reorder transactions to exploit the newly stale parameters, either front-running or sandwiching the user’s trade.
  5. The user ends up with a suboptimal or manipulated fill for their vote purchase/sale because they expected prompt execution but had no time-bound protection.

Impact

Users risk receiving worse-than-expected trade outcomes or having trades executed under disadvantageous conditions. Malicious actors can exploit the indefinite window to front-run or back-run transactions, causing unnecessary losses or slippage. This damages user trust in the protocol’s fairness.

PoC

No response

Mitigation

  1. Introduce Deadline Parameters: Similar to many DEX designs, add a deadline parameter to buyVotes and sellVotes. If the current block.timestamp exceeds the user-specified deadline, revert the transaction.