Basefee-only oracle sizing can make false reports unprofitable to dispute

[KillariDev]

Severity: High

Confidence: High

Classification: Deployment-blocking economic risk

Affected locations:

• OpenOraclePriceCoordinator.sol
• OpenOraclePriceCoordinator.sol
• OpenOraclePriceCoordinator.sol
• OpenOraclePriceCoordinator.sol
• SecurityPool.sol
• SecurityPool.sol
• oracleInitialReport.ts

Description

minimumToken1Report() calculates the correction incentive from:

block.basefee × gasUnitsForOneDispute

It does not include a priority fee, builder payment, capital cost, or inclusion premium. If this product is zero, it returns one wei.

Under the default parameters, the report position is sized to generate approximately ten times the request block’s base-fee-only dispute cost at the configured 5% error. Let:

• b_req be request base fee,
• b_inc be the correction transaction’s inclusion-block base fee,
• p be the necessary priority or inclusion fee,
• g be dispute gas.

Ignoring integer rounding, correction is profitable only while:

10 × b_req × g > (b_inc + p) × g

Therefore:

• At the same base fee, correction becomes unprofitable around p ≥ 9 × b_req.
• At the coordinator’s accepted maximum settlement base fee of 3 × b_req, it becomes unprofitable around p ≥ 7 × b_req.
• At b_req = 0, any positive inclusion cost exceeds the modeled incentive, while the on-chain report floor is only one wei.

The sponsor controls the initial REP/ETH price. The callback validates report identity, nonzero amounts, and base fee, but it has no external truth check. Once undisputed settlement occurs, the price is accepted and reused for five minutes.

The protocol documentation correctly identifies ORACLE-A1 as a required assumption and says concrete parameters that cannot support profitable timely correction are deployment-blocking. The reviewed deployment does not establish an inclusion-fee floor or an on-chain exposure limit.

Violated invariant

Price-dependent vault operations must not rely on a report that rational independent participants cannot profitably correct and include before settlement.

Preconditions

• The cached price is stale.
• The attacker can sponsor a report and provide the small WETH/REP report position.
• Required correction priority or inclusion fees exceed the basefee-only profit budget, or a builder censors correction.
• No subsidized honest watcher corrects the report despite an economic loss.

Concrete attack sequence

1. A vault operator waits for the cached price to expire.
2. The operator stages an allowance update or withdrawal while proposing an artificially low REP-per-ETH price.
3. The coordinator sizes the WETH position only from block.basefee; in the limiting case it requires one wei.
4. Real correction requires a priority fee that makes disputing economically irrational.
5. After the 480-second settlement period, the attacker settles the undisputed report.
6. The callback records the false price and executes queued operations.
7. While the cache is fresh, the attacker can execute further allowance or withdrawal operations without opening another report.
8. A low REP-per-ETH price lets the vault retain far less REP than would be required at the true price, leaving open interest and resolution security materially underbacked.

A malicious high price can similarly manufacture liquidation eligibility and distort the amount of REP transferred.

Impact

• Major weakening of REP security behind live ETH open interest.
• Incorrect vault withdrawals or allowance expansion.
• Invalid liquidations.
• Pool-wide exposure because report liquidity does not cap operation value.
• Potential wrong-outcome settlement after security capital is withdrawn.
• Exposure can exceed the report position by an arbitrary factor.

Proof and execution evidence

No new PoC file was necessary.

The existing focused test proves that zero-basefee sizing produces exactly one wei:

• priceOracleSecurity.test.ts

The existing simulator helper proves that any sponsor-selected price settles unchanged when undisputed:

• peripheralsTestUtils.ts

The existing suite also proves repeated operations reuse a single cached price:

• priceOracleSecurity.test.ts

Execution:

bun test --preload ./bun-test-setup-solidity.ts --timeout 300000 \
  solidity/ts/tests/priceOracleSecurity.test.ts

29 pass, 0 fail

Recommended remediation

Before deployment:

1. Size reports using a conservative total inclusion cost, including a configured nonzero priority-fee floor and minimum total gas-price floor.
2. Do not derive that floor solely from attacker-controlled tx.gasprice.
3. Add an absolute minimum WETH report position that remains meaningful at low base fees.
4. Bound cumulative price-dependent exposure by report security, or replace the incentive-only oracle with an oracle carrying slashable collateral proportional to protected value.
5. Add rate limits or circuit breakers for large price changes, REP withdrawals, allowance expansion, and liquidations.
6. Increase the settlement window if timely correction cannot be demonstrated.
7. Operate and fund independent correction infrastructure, but do not treat an operator as a substitute for an enforceable economic bound.

Suggested regression tests:

• Profitability at nonzero base fee plus configured priority fee.
• Zero-basefee request with positive priority-fee floor.
• Request at b, settlement at 3b, and correction at the configured maximum tip.
• End-to-end false-price withdrawal and allowance attempts.
• A cumulative operation-value cap across cached-price reuse.

please research on the issue and come up with the best plan to fix the issue. Keep in mind that we dont truly know how much eth is worth, how much rep is worth, how much the base fee is going to change etc.