> For the complete documentation index, see [llms.txt](https://funarchy.gitbook.io/funarchy/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://funarchy.gitbook.io/funarchy/security-for-prediction-market/trading-mechanism/clob-risks/state-inconsistency-in-hybrid-clob.md). # State Inconsistency in Hybrid CLOB ### Description This is a vulnerability that arises in the Hybrid CLOB system because the order processing sequence of the off-chain matching engine and the transaction confirmation sequence of the on-chain smart contract are not synchronized. Even if an order is matched and a specific nonce is assigned in the off-chain engine, no execution on the blockchain network is guaranteed until the data is recorded on-chain. On-chain networks determine the final execution order based on the gas fees of transactions submitted to the public mempool and the block creator's choice, rather than the off-chain nonce order. This results in a systemic disconnect where 'off-chain settlement' does not directly lead to 'on-chain state confirmation,' and attackers can exploit this asynchronous environment to manipulate the order of transactions. ### Root Cause * State Asynchrony: Exposure of Mempool waiting time between the order execution time of the Web2 matching engine and the final state confirmation time of the Web3 blockchain. * Strict Nonce Equivalence Verification: The order verification logic within the `CTFExchange` contract is designed with the structure `require(nonces[order.maker] == order.nonce)`, allowing execution only when the current nonce value exactly matches (`==`) the signed value. * Exploitation of the Public Cancel Function: Users can call the `incrementNonce()` function to collectively invalidate their previous signatures at any time simply by paying the gas fee. ### Attack Scenario {% hint style="info" %} **The attacker executes risk-free arbitrage using an automated bot and two independent wallets,** **Wallet A and Wallet B.** {% endhint %} {% stepper %} {% step %} Two-way position signature: The attacker signs an 'Up' buy order to Wallet A and a 'Down' buy order to Wallet B with `nonce = 0` (EIP-712) and submits them simultaneously to the off-chain order book. {% endstep %} {% step %} Off-chain Matching and Mempool Entry: The Polymarket operator matches the counterparty orders with the orders from Wallets A and B, respectively, and then sends two `matchOrders` transactions to the Polygon Network. (Currently waiting in the mempool) {% endstep %} {% step %} Price Fluctuation Monitoring: Before block confirmation, the bot detects that Wallet A (Up) has entered a profit zone and Wallet B (Down) has entered a loss zone as prices in external spot markets, such as Binance, rise. {% endstep %} {% step %} Selective Front-running: The bot immediately sets a higher Priority Fee (gas fee) than the operator and sends a transaction to the mempool that calls `incrementNonce()` only to the account of Wallet B where a loss is expected. {% endstep %} {% step %} Transaction Selective Revert: Based on gas fee priority, Wallet B's `incrementNonce()` is recorded in the block first, and Wallet B's on-chain nonce is changed to `1`. * The `matchOrders` for Wallet A submitted by the operator are executed successfully. (`0 == 0` passes) * The `matchOrders` for Wallet B submitted by the operator are forcibly reverted due to verification failure. (`1 == 0` failure) * Result: The attacker takes only profitable Up positions and avoids executing loss-making Down positions. {% endstep %} {% endstepper %} ### Mitigation * **Introduction of App-chain-based fully on-chain order book** * App-chain application layer built-in matching * Instead of relying on smart contracts of a general-purpose blockchain, we build an independent AppChain network specialized for order book processing. * The matching logic is embedded directly in the application layer (state machine) of the core node, rather than on an off-chain server. * Since order submission, cancellation, and matching logic are processed atomically within a single on-chain domain, it prevents systemic contradictions where an execution is recorded off-chain but is reverted on-chain due to state manipulation. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://funarchy.gitbook.io/funarchy/security-for-prediction-market/trading-mechanism/clob-risks/state-inconsistency-in-hybrid-clob.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.