Perennial: a mismatched oracle timestamp makes a 1.000000 long impossible to close

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 24299-h-1-oracle-request-timestamp-and-pending-position-timestamp. Standalone Foundry PoC and full write-up: 24299-h-1-oracle-request-timestamp-and-pending-position-timestamp_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/logic/incorrect-state-transition · vuln/dos/frozen-funds

Reproduction: local synthetic, no fork. PythOracle.request is the audited body. The trader opens a long of 1.000000 (1,000,000 fixed-point units), posts 1,000 collateral, and the close is ignored. Trace: output.txt.

Key info#


Impact	HIGH — the close is ignored, so a 1.000000 long stays open and 1,000 collateral stays in the market
Protocol	Perennial V2 — `PythOracle.request` / `Market` pending positions
Vulnerable code	`versionList.push(block.timestamp)` while the position timestamp is `current()`
Bug class	Timestamp mismatch → position update ignored
Finding	Sherlock 2023-07 Perennial · #24299 · WATCHPUG, panprog
Report	sherlock-audit/2023-07-perennial-judging

Root cause#

PythFactory.current() rounds block.timestamp up to the next granularity boundary (ceilDiv). The market stamps the new pending position with that future timestamp, then calls oracle.request in the same update. request does not store current(). It stores block.timestamp:

SOLIDITY

function request(address) external {
    if (versionList.length == 0 || versionList[versionList.length - 1] != block.timestamp) {
        // @> VULN: request key is block.timestamp, not current(), so the price misses the position
        versionList.push(block.timestamp);
    }
}

commitRequested writes the price at versionList[i]. Settlement then calls oracle.at(position.timestamp). Those two keys differ whenever block.timestamp is not already on a boundary. With granularity 100 and block.timestamp = 1, the position is stamped 100 and the price is stored at 1. The version is invalid, so the close is ignored.

Attack path#

flowchart TD A["Trader opens long 1.000000 and posts 1,000 collateral"] --> B["current rounds block.timestamp 1 up to 100"] B --> C["request pushes 1, not 100"] C --> D["Market records the long and holds the collateral"] D --> E["Keeper commits the price at timestamp 1"] E --> F["Trader submits a close"] F --> G["Settlement looks up timestamp 100, finds no price, ignores the close"] G --> H["Long stays 1.000000 and 1,000 collateral stays locked"]

PoC#

BASH

cd 24299-h-1-oracle-request-timestamp-and-pending-position-timestamp_exp
forge test -vv

The exploit asserts the long is still 1_000_000, closeIgnored is true, and the market still holds 1_000 ether. The control oracle pushes current() instead of block.timestamp. The same close is accepted: the long goes to 0 and the trader receives the 1,000 collateral back.

Remediation#

Stamp the request with current(), which is what the pending position already uses:

SOLIDITY

function request(address) external {
    uint256 nextTimestamp = current();
    if (versionList.length == 0 || versionList[versionList.length - 1] < nextTimestamp) {
        versionList.push(nextTimestamp);
    }
}

Fixed in equilibria-xyz/perennial-v2#57.

References#

Sources & further analysis#

Reproductions & code

Standalone PoC + full trace: 24299-h-1-oracle-request-timestamp-and-pending-position-timestamp_exp (evm-hack-registry mirror).
AuditVault finding: 24299-h-1-oracle-request-timestamp-and-pending-position-timestamp.

Alerts & third-party analyses

Web3Sec X hacked database: search.
Rekt leaderboard: search.
Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.

Source-level debugger — step opcodes and Solidity in sync