SerrataOS

@assymetrix_com @Polymarket Your breakdowns of Polymarket UMA vs Kalshi resolution premiums are sharp. I'm testing an independent evidence layer for disputed events—interested in whether preserving ancillary data + trader view would surface these mismatches better

@Polymarket When Polymarket lists a contract like this, the UMA oracle resolves against natural-language rules. If Kalshi listed it, CFTC-enumerated criteria would define 'agree' with legal precision. Two architectures, same space race. assymetrix.com/blog/predictio…

🚨 NEW POLYMARKET: Google x SpaceX agree to put data centers in space by the end of next month?polymarket.com/event/google-x…

We shipped a third Serrata receipt this one compares market-definition surfaces for a live Polymarket market the interesting bit: trader-visible surfaces say the market resolves by leaderboard Rank, while decoded oracle-facing ancillary data says Score Serrata doesn’t decide which surface is authoritative. it just preserves the mismatch, artifacts, and hashes serrata.ink/receipts/marke…

We shipped a second Serrata receipt R0 was boring on purpose: BLS source payload capture R1 is closer to the actual use case: a scoped final-resolution-path receipt for a contested Polymarket/UMA market still not a verdict. just the record, artifacts, hashes, and boundaries serrata.ink/receipts/polym…

@ParetoPrincipl yeah those last second dumps in the 5 min contracts are brutal

We have 2 markets. Same rules - different clarifications. Traders get screwed over. Let's sink into it. First market — "What will Trump say during Fox Business interview on April 15?". We have rules - "The resolution source will be video of the events. Only remarks which are broadcast or streamed live will count toward this market's resolution." And we have clarification - "Prerecorded footage from this interview will qualify toward this market's resolution if it is aired within timeframe." Second market - "What will Trump say during bilateral events with Xi Jinping?" We have rules - "The resolution source will be video of the events. Only remarks which are broadcast or streamed live will count toward this market's resolution." And we have clarification - “only remarks which are broadcast or streamed live will count toward this market’s resolution.” Markets have the SAME rules, but a different clarification. It's a serious violation of market integrity. It's impossible to traded fair when no can predict how rules of market is has to be meant. The clarification on the market "What will Trump say during bilateral events with Xi Jinping?" was issued WRONGLY, without due diligence. We got totally ghosted by the Polymarket team. Draw attention to this matter. We expect Polymarket to refund the YES-holders of the market "What will Trump say during bilateral events with Xi Jinping?".

@ParetoPrincipl This is the gap Serrata is aimed at. Not “who is right?” first — but: what did the source/oracle/market report, when, and can everyone verify the same artifact? Record the state. Don’t resolve the dispute.

This time on the market “Enhanced Games” on Polymarket, UMA was totally killed - Polymarket can decide the outcome of the market at will. But when the market polymarket.com/event/what-wil…, which we wrote about extensively and tried to expose the manipulation of, we are getting totally ignored by the Polymarket team. Why does Polymarket have such double standards?

@tonyz_defi Appreciate that — and thanks for following. Exactly the intent: record the state upstream of the dispute, without pretending the receipt resolves it. On anchoring: I think the clean model is separate hashes for source payload, normalized receipt, and dispute envelope.

Just clicked through — Serrata is the layer the piece underweighted. "Record the state, don't resolve the dispute" sits structurally upstream of the four patterns; the failure modes compound when there's no agreed source-of-truth artifact underneath. Ukraine minerals is the right pilot for what the format claims and doesn't. Curious if the digest anchors to the resolution block or a separate commitment chain. Following.

Resolution Is the Hardest Problem in Prediction Markets In the last 18 months, more than $500M in prediction market activity has been affected by resolution failures. Polymarket and Kalshi — the two largest platforms in the category — have both repeatedly failed to deliver clean outcomes on their highest-profile markets. The failures aren't random. They cluster into four patterns, each with a structural cause, and each one a consequence of running every market through the same resolution machinery. This is a builder's view of what went wrong, what the patterns suggest about oracle architecture, and why the next generation of prediction markets has to treat resolution as four problems rather than one. (The XO Market team has published the most thorough public catalog of these incidents; their post is the best starting point for case-by-case detail. What follows builds on that catalog with a design perspective.) Pattern 1: Vague resolution criteria The largest failures by volume have nothing to do with oracles or game theory. They happen at market creation, before any trader has placed a bet. — Zelensky "wearing a suit" ($242M, Polymarket, June 2025): resolution criteria did not define what counts as a suit. Lawyers, fashion journalists, traders, and even menswear writers disagreed publicly. After Zelensky appeared at a NATO summit in The Hague on June 24 in attire most major outlets described as a suit, UMA initially resolved "Yes," then reversed twice, and finally settled "No." — Cardi B performance ($47M, Polymarket): "what counts as a performance" was never defined. — TikTok ban ($120M, Polymarket): no ban duration defined. A short service interruption counted despite the market clearly being written for a longer-term policy ban. — Ethereum ETF approval ($13M, Polymarket): which specific SEC procedural step counts as approval? The market didn't say. These are process failures. A market with vague criteria is structurally unresolvable no matter how sophisticated the downstream oracle is. The fix lives upstream: a pre-launch validation step that catches ambiguity before trading begins, with hard rejection of markets that cannot be cleanly resolved. Nobody has built this layer. Markets continue to go live with criteria that careful readers can predict will be disputed at expiry. The fact that this is the largest failure category by dollar volume — and the most preventable — is a striking indictment of where the category currently sits. Pattern 2: Token-weighted oracle capture The next failure mode is more technical, and it's the one that gets worse as markets grow. The Ukraine minerals attack ($7M, UMA-based market, March 2025) demonstrated the structural issue precisely: a single actor distributed roughly 5M UMA tokens across three wallets, cast about 25% of voting power, and forced the market to resolve "Yes" despite no agreement existing — a result Polymarket itself later acknowledged was incorrect while declining to issue refunds. The mechanic is simple. When an oracle's security budget (token market cap × percentage required to swing a vote) is less than the value of an individual market being resolved, the oracle becomes economically capturable. This is not a question of whether capture eventually happens. It is a question of which specific market triggers it. UMA's response is instructive. In August 2025 they shipped the MOOV2 contract upgrade, restricting resolution proposals to a whitelist of 37 vetted addresses. In effect, the protocol acknowledged that pure token-weighted decentralized resolution doesn't work at scale and bolted a centralized gatekeeping layer onto it. That is a real concession about the structural limits of the design — and that gatekeeping layer is now doing load-bearing work the original architecture said it wouldn't need. The lesson is broader than UMA. Token-weighted dispute voting has this vulnerability built in — any new platform tempted to copy the pattern inherits the same ceiling. Pseudorandom jury selection, reputation weighting, commit-reveal voting, and quadratic damping all reduce the linear "buy more tokens, buy more votes" attack surface. None of them eliminate it. All of them are meaningfully better than what most current platforms ship. Pattern 3: Operator override inconsistency The third failure mode is the centralized-platform version of the same problem. When a market resolves ambiguously, the platform operator has to decide. Without a clear rule, they decide inconsistently. Inconsistency itself becomes the trust failure. — Polymarket overrode UMA on the Barron Trump market. Accepted UMA on Zelensky. Bypassed UMA on TikTok. Replaced UMA with Chainlink for straightforward markets after its QCEX-acquisition return to the US market. — Kalshi invoked a buried death-carveout provision on the Khamenei market ($54M, February 2026) after Khamenei's death was confirmed — refusing full payouts to "Yes" holders and resolving instead at the last traded price. The carveout was not in the user-facing rules summary; a class action followed. Kalshi has also used CFTC-regulated data sources for legal robustness while applying operator discretion at the edges. Each individual decision may have been defensible in isolation. The pattern across them was not. Traders cannot predict how disputes will be handled, which means they cannot price resolution risk into their positions, which means they trade with less confidence — or stop trading altogether on edge cases. The fix is documented override discipline: who has authority to override, under what conditions, with what public reasoning requirement, within what bounded limits. "We will override when necessary" is not a policy. "Pause authority is bounded to 24 hours, public reasoning required, no unilateral resolution overrides" is. Pattern 4: Insider trading on non-public information The final failure mode is the one nobody wants to talk about because it doesn't have a clean technical fix. — The Maduro arrest market ran from $32K to $437K on a wallet funded a week before the public announcement. — The ISW (Institute for the Study of War) map editor had the ability to change source data that markets were resolving against and used it for personal trading profit. The market resolved correctly in both cases. The problem is what "correctly" means when the prices were set by someone with classified or privileged access. This is not really an oracle problem. It is an enforcement and regulatory problem. But it constrains oracle design in one important way: when markets are sensitive to insider information, the credibility of the resolution depends on the credibility of the source. A market resolved against a single source that an insider can manipulate (the ISW pattern) is structurally weaker than one resolved against multiple independent sources where an insider would need to manipulate all of them simultaneously. Multi-source verification is not a complete defense against insider trading. It does raise the cost meaningfully — which is most of what oracle design can do here. The structural insight Each of the four failure patterns has a different cause. Vague criteria fails at market creation. Token-weighted capture fails at dispute. Operator override fails at policy. Insider trading fails at source. The current generation of prediction markets routes all of these through one resolution machinery. UMA-only on Polymarket (with the bolted-on whitelist now compensating). CFTC-regulated-feeds-plus-operator-discretion on Kalshi. Pure decentralized vote on Augur — which is part of why Augur didn't survive. This is the structural cause. Different failure modes need different mechanisms. A single resolution architecture cannot defend against all four simultaneously, and trying to make it do so produces the override inconsistency that defines current platforms. UMA's MOOV2 whitelist is the clearest recent acknowledgment: even the original decentralized-oracle thesis needed a centralized layer added to function. That layer is doing real work — and that's the point. The work needs a home in the architecture, not as a patch. What good oracle design looks like The architecture that follows from this analysis has four properties. Pre-launch validation. A formal step that checks resolution criteria for ambiguity before trading begins, with hard rejection of markets that cannot be cleanly resolved. The Zelensky / Cardi B / Ethereum ETF / TikTok class is preventable upstream. No oracle improvement at resolution time can fix a market that was unresolvable when it launched. Different layers for different market types. Price markets want sub-second feeds with minimal dispute. Event markets want longer windows with multi-source verification. Tail-risk markets need a defined final backstop. Forcing all of them through one mechanism is the structural source of the failures above. Dispute resolution that resists token capture. When markets escalate, the mechanism cannot be purely linear-stake-weighted. Pseudorandom jury selection, reputation weighting, commit-reveal voting, and quadratic damping all raise the cost of capture without claiming to make it impossible. Documented override discipline. Whoever has authority to override resolution — whether team, governance, or constitutional backstop — needs explicit rules for when and how. Traders should be able to predict the resolution outcome and the dispute path, including who gets the final word in tail cases. These are not novel observations. They are what should have been obvious from the first generation of failures. They aren't obvious in practice because building all four correctly is significantly harder than building one well and trusting the rest to be handled later. What this means for the next generation The disputes are not slowing down. A contested Israel-Hezbollah ceasefire market reopened the same UMA scrutiny just weeks ago. The Kalshi death-carveout class action is active. Polymarket's return to the US market under CFTC oversight adds a new regulatory dimension that compounds, rather than resolves, the underlying problem. The argument of this piece is upstream of any specific implementation: the next generation of prediction markets has to treat resolution as four problems rather than one. The platforms that don't will repeat the last 18 months at higher dollar volumes. The $500M figure from the past 18 months is not an upper bound on what bad resolution costs. It's a lower bound on what good resolution is worth solving.

"The Mysterious Crypto Judges Who Settle Polymarket Disputes" Prediction markets keep hitting the same friction: real-world events are messy, and resolution depends on how the observed data gets interpreted later. This is why separating raw source payloads from normalized summaries (with durable digests) can reduce a lot of the post-facto arguing wsj.com/finance/polyma…

@dmint_founder @BinanceWallet On-chain event markets make the provenance question even sharper. Receipts that publish raw/canonical artifacts (instead of just screenshots) give everyone the same starting point for verification

Binance @BinanceWallet just launched Event Rush, a new on-chain binancecoin:native DApp that lets users trade prediction markets on real-world sports events and breaking news directly from their wallet 🔥 It’s a prediction-market style product focused on fast, verifiable outcomes (match results, news events, etc.), all settled on-chain. The move brings Binance’s massive user base one step closer to everyday on-chain betting and information markets, with the wallet acting as the seamless frontend. This is another example of how on-chain infrastructure is maturing for real-world events. While platforms like this create new ways to express views on outcomes, they also highlight the difference between temporary event-based bets and structurally scarce digital collectibles with fixed mintage and permanent on-chain provenance. One is a short-term trade on a headline; the other is ownership that lasts beyond any single event. As more real-world activity moves on-chain, the value of assets whose scarcity and history can never be altered becomes even more distinct. If you follow how on-chain markets are evolving beyond pure speculation into practical use cases, this kind of development is worth watching. Do you see products like Event Rush as the future of on-chain information trading, or do you think the real lasting value still lies in deliberately limited digital objects? #EventRush #OnChainMarkets

@DegenerateNews @HyperliquidX CPI markets are interesting because the source data is public but the exact payload and timing still matter when disputes arise. Receipts that capture the raw BLS API response + SHA-256 digest can make verification a lot cleaner.

BREAKING: @HyperliquidX DROPS CPI PREDICTION MARKET

@IzhImon @RollinsR79 @RialoHQ The oracle layer does get fragile as markets scale. One useful distinction is keeping the raw source payload separate from any normalized summary — it lets people verify independently without turning every dispute into a screenshot war.

Prediction markets are meant to function as truth engines, yet the weakest layer is often the one people pay the least attention to: the oracle. If the oracle can be influenced or manipulated, the entire market can be distorted along with it and as these markets grow larger, the incentives change fast. At a certain scale, bribing reporters, exploiting governance systems, or manipulating outcomes stops looking irrational and starts becoming economically profitable. That’s where Rialo stands out. Instead of depending on middlemen, governance votes, or complicated incentive structures, Rialo resolves markets directly from primary real world sources of trusted climate publishers. The concept is straightforward: don’t ask token holders to debate reality when the original source already publishes the answer. That shift changes the security model in a major way. @RialoHQ removes the telephone game that traditional oracle systems rely on and makes truth sourcing transparent, verifiable and machine readable from the start. The result is prediction market infrastructure that can scale without leaning on fragile governance incentives to hold everything together. @RialoBangladesh

@ParetoPrincipl @VitalikButerin Agreed — a prediction market is only as good as its oracle. Part of that is having durable records of exactly what the source reported at the time, separate from later interpretation

"A prediction market is only as good as its oracle." - @VitalikButerin It's hard to disagree - such a simple and precise point. If a platform chooses to align its growth with the goal of building the best prediction market in the world, they will pour a lot of their resources into developing comprehensive and fulfilling resolution rules simultaneously with their oracle system. On the other hand, if a platform chooses to extract as much money as possible from its users, they keep their market resolution mechanisms poorly maintained and corrupted, while maximizing engagement on crypto and sports, introducing parlays, and incentivizing their users to bet on high-risk contracts. It is so sad that, in the current situation, Polymarket is moving toward becoming a crypto-casino rather than a regulated prediction market. I hope that the situation will improve in the future.

Serrata’s first completed source receipt is live. It preserves a captured BLS CPI API payload, publishes raw/canonical artifacts, and exposes SHA-256 digests so the receipt can be independently checked. It does not resolve a dispute. It proves the receipt pipeline works. serrata.ink/receipts/bls-c…

@OnlyClickClick yeah the last-second dumps in those 5-min contracts are brutal

@SerrataOS x.com/OnlyClickClick… What is savage is the fact no one is callling them out for fucking retail flow in the 5 min up down contracts What is savage is the clear as day fraud stealing funds by crashing the price in the last seconds when they know no one can flip the other way.

Polymarket got pwnd. The UMA CTF = UMA’s “Cross-Chain Teleport Framework” (also called Optimistic Oracle / CTF Adapter system) Was exploited. Funny how no one gives a shit when it's them exploiting the users is it. But soon as they get pwnd it's a big deal. Karma bitch.

Yep — that’s the intended split. A completed receipt should hash the captured source/input payload separately from the receipt/envelope itself. So downstream consumers can audit: “did the underlying captured payload change?” vs “did Serrata’s packaged receipt/change-log change?” The current Ukraine page is only a scaffold, so it only has the scaffold digest.

@SerrataOS @thecryptobrando @Polymarket @wallstreetbets @WallStreetMav @AshCrypto clean design. immutability plus a contested flag means downstream consumers can filter on consistency without trusting serrata's judgment. does the dispute receipt itself get a separate payload hash for auditability?

Crazy missresolve going on on @Polymarket ! You should check it out guys, potential 200x gain hahah @wallstreetbets @WallStreetMav @AshCrypto

What we are building with Serrata: A receipt format + evidence desk for oracle/event resolutions. Useful when markets, protocols, or users need to answer: “Why was this resolved this way?” Not trying to replace UMA / optimistic oracles / voting. Trying to make the aftermath legible, citable, and harder to obscure.

Yes — disputes stay with the venue/protocol that has settlement authority. If source + payload hash disagree, Serrata would not “fix” the result. It marks the receipt as inconsistent/contested, preserves the original sealed payload, and appends a dispute/revision receipt showing the delta, challenger, timestamp, and evidence. No silent overwrite.

@SerrataOS @thecryptobrando @Polymarket @wallstreetbets @WallStreetMav @AshCrypto so the receipt is an attestation envelope, not a resolution mechanism. clean separation. who handles disputes when the recorded source and the payload hash disagree post-settlement?

@0x_Benav @Polymarket clean breakdown — the adapter being isolated probably saved the main platform from worse

TLDR: @Polymarket Adapter Exploit (May 22, 2026) => Attacker draining funds live from Polymarket’s UMA CTF Adapter on Polygon (oracle/dispute resolution contract). => Pulling 5,000 POL every 30 seconds from the adapter contract. => Total drained: $600k–$660k+ in POL (some reports also mention mixed USDC). => Funds split across wallets and sent to mixers/swap services (e.g. ChangeNOW). => Cause: Compromised old private key (not a smart contract vulnerability) => Impact: Main Polymarket platform, user positions, and trading appear unaffected. The adapter is isolated. => Status: Attack appears slowed/stopped in last 20 mins; team investigating, users advised to pause activity as precaution. Stay Safu frens

@Henk0x_ with UMA voters you really never know on these edge cases

Potential new Polymarket drama coming next week around Nantes vs Toulouse in Ligue 1, which was suspended a few days ago after a pitch invasion. The rules seem pretty clear and, if the match doesn’t resume, Draw should resolve as YES. But with UMA voters, you never really know.