Polymarket Under Pressure: Outages, Stale Order Losses, Rebategate and Wallet Concerns

There is a specific kind of trust that prediction markets require that no other financial instrument needs in quite the same way. When you trade equity futures, the exchange's technical infrastructure is backed by decades of regulatory oversight, clearing house guarantees, and legal frameworks that define exactly what happens when something goes wrong. When you trade on Polymarket, you are trusting a relatively young platform's engineering team, its resolution processes, its rebate structures, and its commitment to treating users fairly when the system breaks down.

The events of August 30 and 31, 2026 tested that trust comprehensively, and the results are worth examining in detail because they reveal something important about where Polymarket's infrastructure, governance, and community relationship currently stand.

The Outages That Turned Stale Orders Into Losses

Polymarket experienced multiple CLOB outages within a single 24-hour window. The Central Limit Order Book went down around 17:48 UTC on August 30. It went down again around 20:08 UTC the same day. At approximately 01:07 UTC on August 31, the platform entered cancel-only mode, a degraded state where users could cancel existing orders but not place new ones, and remained in degraded operation through at least 03:38 UTC. Engineering confirmed the cause was database issues at approximately 03:48 UTC. This was the third major outage within a week.

The outage sequence created a specific and painful problem for traders who had resting limit orders on the book when the system went down. When a trading platform goes offline, it typically freezes the order book in its last known state. When it comes back online, that frozen state represents prices from some point in the past. In the minutes or hours that elapsed during the outage, the underlying probabilities the market was pricing may have shifted significantly due to new information, time passing, or related market movements.

When the system restarts and trading resumes, those stale resting orders at historical prices are suddenly available to be filled by other traders. If you had a limit buy order at a price that is now significantly above the fair market value because conditions changed during the outage, another trader can immediately take the other side of that trade at favorable terms for them and unfavorable terms for you. You placed the order based on conditions that no longer exist, and you had no opportunity to cancel it during the outage because cancellations were also disabled.

The documented losses from this mechanism in the August 30 to 31 window are specific and substantial. Lochnload2718 reported approximately $5,000 in losses from stale orders being filled at unfavorable prices when trading resumed. Balthazar_826 reported approximately $7,000. Flynskwirl0765 reported losses in the hundreds of dollars. These are not hypothetical harms or abstract risks. These are documented cases of users losing real money because the platform's restart procedure filled their stale limit orders at historical prices before they had any opportunity to cancel.

The community's response to these losses has coalesced around a specific technical request: a cancel-on-downtime order flag that would automatically cancel all resting limit orders when the platform detects it is going offline rather than preserving them in a frozen state that becomes a liability when trading resumes. This feature already exists on Kalshi, Polymarket's primary US-based regulated competitor. The fact that Kalshi has implemented this protection while Polymarket has not is a straightforward competitive and user-protection gap.

As of the digest date, there has been no official response from Polymarket about compensation for users who lost money due to stale fills during these outages. The engineering team confirmed the cause of the outage. The product and operations team have not addressed what happens to users who were harmed by the restart mechanism.

The Rebate Dispute That Has Not Been Resolved

The rebategate situation that broke into public view in the days preceding this digest has not been resolved, and new details from the August 31 window make the situation more rather than less concerning.

The core allegation, which we covered in detail in previous analysis, is that Polymarket secretly granted approximately 80% taker fee rebates to a cluster of wallets linked to a single entity operating under various aliases, while the publicly known maximum rebate tier provides only 50% and requires $154,000 in monthly volume. The rebate arrangement was discovered through on-chain analysis rather than official disclosure.

The additional development from the August 31 digest is the allegation that select firms received not just preferential rebates but free access to high-tier accounts. If accurate, this expands the scope of the preferential treatment beyond fee structure into account access itself.

Suhail Kakar, Polymarket's Head of DeFi Integration, had reportedly committed to providing an announcement about the situation. That announcement has not materialized. Meanwhile, users who continue raising the rebate issue in community channels are reportedly being muted.

The muting is the detail that will generate the most lasting damage to community trust. A platform can survive technical outages, even repeated ones, if it handles the communication and remediation well. A platform can survive being caught giving preferential treatment to specific firms if it acknowledges the issue transparently, explains the reasoning, and commits to fair treatment going forward. What is much harder to survive is a pattern of responding to legitimate community concerns by silencing the people raising them.

Muting users for raising a documented issue about undisclosed preferential rebates sends a message about the relationship between the platform and its user community. The message is that the platform's priority in this situation is managing the conversation rather than addressing the underlying issue. For a platform whose value proposition depends on being trusted as a neutral venue for price discovery, that priority ordering is precisely backwards.

The Wallet Drain That Has No Official Explanation

One of the more alarming technical incidents in the digest involves user peterljf reporting a wallet drain that occurred on August 28. Twenty-six conditional token positions were batch-transferred out of their account via a relayCall mechanism without any order book interaction. The operations used were setApprovalForAll, burn, and transfer, which together represent a sequence that could move tokens without a standard trade taking place.

The funds were traced to a Bybit address. The account had Google login enabled with two-factor authentication, and the user reported no unrecognized sign-ins in their account history.

This incident has several characteristics that make it unusual and concerning. Standard prediction market theft scenarios involve compromised credentials where an attacker logs in as the user, or smart contract exploits where a vulnerability in the platform's code allows unauthorized transfers. The setApprovalForAll mechanism is a different category of risk. It involves granting blanket approval for a specific contract to transfer your tokens on your behalf. If a user was at some point tricked into signing a setApprovalForAll transaction, that approval could sit dormant for weeks or months before being exploited.

The batch transfer of 26 positions without order book interaction suggests automation. This was not someone manually going through the positions one by one. A script or automated system executed the transfers in sequence. The specific combination of no unrecognized sign-ins plus two-factor authentication plus unconventional transfer mechanism points toward the possibility that the attack vector was not credential theft but rather a previously granted token approval being exploited.

Peterljf is seeking others who were affected during the same window around August 28. If multiple users experienced similar unauthorized transfers in that window using the same mechanism and ending at the same Bybit address, that would suggest a systematic exploit rather than an isolated compromise of one user's credentials or device.

The platform has not provided an official response explaining what happened, whether the vulnerability has been identified and remediated, or whether other users might be at risk. For a platform handling hundreds of millions of dollars in user funds, the absence of an official response to a documented unauthorized fund transfer is a significant gap.

The Technical Failures That Accumulated Across August 31

Beyond the major outages and the wallet drain, the digest catalogs a set of technical failures that individually would be routine bugs but in aggregate suggest infrastructure under significant stress.

The orders endpoint was returning 500 errors, timeouts, and inconsistent data throughout August 31. This is the endpoint that traders use to see their open orders and positions. An unreliable orders endpoint means traders cannot confidently verify whether their positions exist, whether their cancellations were processed, or whether fills have occurred. Trading in a state of uncertainty about your own position is not trading. It is guessing with financial consequences.

Limit orders were disappearing from the order book and the open orders panel, affecting multiple users beginning around 15:29 UTC on August 30. The specific case of one user receiving a Sold confirmation at 53 cents and then watching the position reappear at 15 cents ten seconds later is an example of the kind of state inconsistency that suggests the platform's data layer was not maintaining a consistent view across its components.

Cancellations were disabled simultaneously with trading at approximately 17:58 UTC and not restored until 18:18 to 18:28 UTC. A twenty-minute window where you can neither trade nor cancel your existing orders is, in a fast-moving market, the precise window where stale order losses accumulate.

The crypto five-minute markets for Bitcoin, Ethereum, Solana, XRP, and several other assets were generated 10 to 20 minutes late, with some time slots missing entirely. These markets are time-sensitive by design, their entire value proposition being the ability to trade on near-term price movements in specific windows. A five-minute market that opens 15 minutes late has a fundamentally different character than the market that was advertised.

The Dallas Temperature Market That Cannot Be Redeemed

The Dallas July 9 temperature market produced a specific smart contract failure that illustrates a different category of technical problem: not infrastructure instability but a flaw in the on-chain settlement mechanism.

The 100 to 101 degree Fahrenheit bracket resolved YES. The match was correct. The resolution decision was made. But users who hold positions in the resolved bracket cannot redeem their contracts. The NegRiskAdapter.ready() function continues to return false, which is the on-chain check that gates whether positions can be settled. Position tokens that were initially redeemed briefly reappeared in portfolios, suggesting that the settlement transaction was either reverted or the state was inconsistent.

The NegRiskAdapter is the smart contract system that handles binary outcome markets with multiple possible result brackets. The critical technical issue reported by user_v123 goes deeper than the Dallas market. The NegRiskAdapter.getQuestionCount function is returning 22 for what should be an 11-bracket event, meaning the brackets appear to be duplicated in the contract's internal accounting. If this is accurate, attempting to resolve the correct bracket will cause the adapter's resolve function to revert permanently rather than completing the settlement.

The implication of a permanent revert is that the market cannot be resolved through the standard mechanism. An admin emergency intervention would be required to correct the state and allow settlement to proceed. This is not a routine bug fix. It is a situation where the smart contract's own logic blocks the resolution path, requiring someone with administrative access to the contract to intervene.

User_v123 made the observation that a 50/50 resolution is technically impossible for neg-risk markets in this state. This matters because the standard fallback when a market's resolution is disputed or uncertain is often some form of split resolution. If the technical architecture prevents that approach, the resolution options narrow significantly.

Staff member ak504111 responded by saying they would escalate the issue. There has been no subsequent update in the digest.

The Panama Markets and the Precedent Problem

The Panama weather markets situation from August 30 to September 1 is the most governance-intensive issue in the digest because it involves an unresolved conflict between community understanding of how disputes are handled and what the platform actually committed to in its resolution rules.

The aeronautical weather station that provides METAR data for the Panama markets was offline for more than 20 hours. METAR reports are the official meteorological data source that these markets use for resolution. Without METAR data, the markets cannot be resolved against the specified data source.

Polymarket archived active markets mid-trading without any public announcement. Users holding positions in these markets lost access to their positions without warning or explanation.

The community dispute centers on what should happen in this scenario. User 0x3577 argues that historical precedent from similar situations in Hong Kong, Shenzhen, and Lagos markets establishes a clear principle: when no data is available, the lowest bracket wins. This precedent-based approach would provide a clear resolution path for the Panama markets without requiring new rules to be created mid-dispute.

Staff member ak504111 acknowledged that the existing resolution rules did not cover this case and committed to improving the rules for future markets. This acknowledgment is actually the most concerning part of the response. If the existing rules did not cover this case, then the resolution decision for the current market must be made without clear contractual guidance. Users who traded these markets had an expectation of how disputes would be resolved based on public rules. If those rules are silent on this scenario, the resolution becomes a discretionary judgment call by the platform.

The technical dimension makes this more complicated. The NegRiskAdapter issue identified by user_v123 means that even if a resolution decision is made, the brackets are duplicated in the contract's internal accounting. Resolving YES on the correct bracket may cause the adapter to revert permanently. This is not just a governance dispute about which bracket should win. It is a situation where the technical implementation may prevent any clean resolution from being executed.

Community-proposed resolution paths include no data before midnight leading to the lowest bracket winning based on precedent, or if data returns after archival, a full refund of all positions. Neither path has received a formal commitment from the platform.

The LP Farming Question and Its Non-Answer

The liquidity provider farming abuse reported by kvn5255 is a different category of problem from the outages, wallet drain, and unresolvable markets. It is a game theory problem embedded in the incentive structure of the platform's reward mechanisms.

The specific case involves bots farming the LP rewards in low-liquidity markets by placing one-sided orders that qualify for rewards based on time parameters rather than on actually providing useful liquidity. The example given is a wallet farming approximately $400 to $500 per day on approximately $3,000 in capital with near-zero actual fills. A 13% to 17% daily return on capital through LP reward farming with no actual trading happening is an extreme example of a rewards program being exploited rather than used for its intended purpose.

Staff member 01010100b responded by disputing that this constitutes a bug, arguing that there is a 30-second minimum order time requirement and that orders meeting this requirement legitimately qualify for rewards. This response is technically accurate but misses the more important point. If the rewards program can be systematically farmed by bots placing one-sided orders that never fill in low-liquidity markets, the program is not achieving its stated purpose of improving market quality. It is transferring money from the platform to sophisticated farming operations in exchange for activity that does not benefit other users.

The debate is ongoing without resolution. This is the kind of issue that does not have an urgent technical fix but requires a policy decision about whether the current rewards structure is producing the outcomes the platform wants.