Omen was the prediction market that DXdao governed and that most early DAO futarchy experiments ran on. It matters to a governance-tooling directory for two reasons, and the second is the one nobody records: it established the exact stack – Gnosis conditional tokens, Reality.eth resolution, Kleros arbitration, Gnosis Chain settlement – that Seer rebuilt and runs on today; and its ending is not the ending its own website reports.

Everything below was read first-hand on 16 August 2026 off keyless surfaces: the deployed frontend bundles at omen.eth.limo and aiomen.eth.limo, the GitHub API, the Gnosis Chain and Ethereum Blockscout APIs, and a public Gnosis RPC. Nothing here is taken from coverage.

The app answers 200 and cannot show you a market

omen.eth.limo returns HTTP 200 and a 4,001-byte application shell titled “Omen”. Every liveness check anyone runs – status code, content type, page title – reads green. The shell is a React app that fetches its markets on load, and each of the three things it fetches from is gone:

• The market index. The bundle reads markets from api.thegraph.com/subgraphs/name/protofire/omen-xdai. That host now answers 301 and redirects every query to error.thegraph.com/apierror.json – The Graph’s hosted service was retired, and the subgraph was never republished to the decentralized network under this name. The subgraph repository is archived, last pushed 24 January 2023.
• The chain connection. The same bundle points at rpc.xdaichain.com, which has no DNS A record at all. Gnosis Chain retired that hostname; the frozen build never learned the new one.
• Its own identity. Every og: and twitter: tag in the shell still points at http://omen.eth.link/, and the inline bootstrap script still branches on hostname.endsWith(".eth.link"). The build predates the ENS gateway migration that replaced .eth.link with .eth.limo.

This is a sharper form of a failure the wiki tracks across its citations: a resource can die at HTTP 200. Here it is an entire application rather than a page. The frontend repository, protofire/omen-exchange, tells the same story more quietly – opened 5 September 2019, last pushed 20 September 2023, default branch still master, never archived. Nobody closed Omen. They stopped answering it, and the infrastructure underneath expired on its own schedule.

The contracts kept taking writes for three more years

The market-maker factory on Gnosis Chain, FPMMDeterministicFactory at 0x9083A2B699c0a4AD06F63580BDE2635d26a3eeF0, was deployed on 4 September 2020 and is verified. Its lifetime counters read 2,035 transactions and 141,860 token transfers. Its code still returns from eth_getCode on a public RPC.

It also still gets used. The most recent calls to create2FixedProductMarketMaker landed on 1 April 2026 – roughly two and a half years after the frontend’s last commit, and long after the app could display anything. Reading the fifty most recent inbound transactions, spanning 16 December 2025 to 1 April 2026, they come from exactly two addresses: 0x677C86…Fd02D (47 of them) and 0x3Cc14F…cbe7A (3). Not a user base. Two machines.

Ethereum mainnet is the control case. The mainnet factory at 0x89023D…76220 carries three transactions in its entire history, the last of them a market created on 8 May 2023. Omen was a Gnosis Chain product in practice from the start, and the mainnet deployment barely moved.

Why a dead venue still gets writes: it became an agent substrate

The two addresses are explained by software that is very much alive. Gnosis maintains prediction-market-agent-tooling – opened 8 February 2024, last pushed 22 April 2026, 58 stars – a Python library for deploying autonomous agents that trade and create prediction markets. It ships a full markets/omen/ module, and its factory class hardcodes the address above, character for character. Its supported-platforms table lists three venues, and the one it supports for reading, betting and creating is AIOmen.

aiomen.eth.limo is Omen’s frontend rebuilt for that audience, and the rebuild is almost literal: its HTML shell is byte-identical to omen.eth.limo’s except for the two JavaScript chunk hashes. The bundle inside was partly repaired – the chain connection now points at the working rpc.gnosischain.com (POST-only: it answers eth_blockNumber and 404s a plain GET) instead of the dead rpc.xdaichain.com – but it still reads its market index from the same retired hosted-service subgraph. Both browser frontends are blind for the same reason.

The agents are not. The Python library reads Omen through The Graph’s decentralized network instead, at gateway subgraph IDs behind an API key. That single migration is the whole divergence. The read path a human needs was left on a service that shut down; the read path a program needs was moved to one that did not. Omen did not die so much as stop being addressable by people.

What this changes about auditing a DAO’s tooling

Omen is the cleanest available counterexample to two habits that DAO directories, this one included, fall into.

A live domain is not a live product, and a frozen repository is not a dead protocol. Checked from the outside, Omen looks maintained: the site resolves, the repository is unarchived, the social accounts still exist. Checked from the inside, its data layer has been gone for years. Meanwhile the part everyone treats as the archaeology – the deployed contracts – is the part still doing work. The two signals point in opposite directions, and the on-chain one is the one that is hard to fake.

The stack outlives the organization that paid for it. DXdao wound down; Omen’s frontend froze; and the conditional-tokens-plus-Reality.eth-plus-Kleros arrangement Omen proved out is exactly what Seer runs on Gnosis Chain today, carrying 395 live futarchy markets. When a DAO winds down, the interesting question is not what it shut off but which of its components other people picked up – a pattern the wiki treats at length in winding down a DAO.

How Caper approaches this

Omen’s failure mode is a governance risk, not just an engineering one: the venue where decisions were priced became unreachable to the people whose decisions they were, while remaining perfectly reachable to whoever still had the address. A caper is built so that the action that matters most to a holder does not sit behind a frontend. Exiting is a method on the component itself, called with the holder’s own vote and governance tokens in the transaction and paying out to an account they name – no indexer, no hosted subgraph, no website in the path. If caper.network went dark tomorrow, a holder with a wallet and the component address could still leave. That is a lower bar than it sounds, and Omen is what it looks like when a project does not clear it.