What Are Permissionless Prediction Markets?

Imagine a question such as: “Will the U.S. Bureau of Labor Statistics report a 12-month increase above 3.0% for the August 2026 CPI-U, U.S. city average, all items?” A curated venue may ask you to submit the idea for review. An open-creation system may let you publish it yourself. The hard part begins immediately after publication: which BLS release and data field control, whether the contract uses seasonally adjusted or unadjusted data, what happens if the figure is revised, and who is authorized to settle the market? The U.S. Bureau of Labor Statistics publishes the relevant CPI series and release tables in its Consumer Price Index program.

This article uses permissionless in an operational sense: the market-creation process does not require a case-by-case approval by the venue operator. It is not a formal legal classification, and it does not mean that every person may trade, that every topic is allowed, or that the market is free of an operator, rules, or governance.

1. Permissioned listing and permissionless creation

On a permissioned route, the venue decides which market ideas it will create or list. Polymarket’s Help Center says that markets are created by its markets team with input from users, and that users cannot directly create their own markets. Its current guidance asks for a title, a resolution source, and evidence of demand; the idea is submitted to the team rather than deployed by the user. See Polymarket’s market-creation guidance.

Kalshi’s current Help Center similarly directs an entirely new idea to its market suggestion feed. It says suggestions are reviewed for CFTC compliance, manipulation risk, and user interest, and that a suggestion is not guaranteed to become a live market. Its market FAQs ask for an objective event definition, settlement criteria, reliable data sources, a timeframe or expiration, and an explanation of trader value. See Kalshi’s current submission guidance and market FAQs.

The useful distinction is therefore not “centralized versus decentralized” as a single label. A market can be open to create but restricted to trade. It can use an automated market maker but rely on one creator to resolve. It can store terms on-chain but depend on an external source for the fact being measured. Creation, trading, resolution, and governance are separate design layers.

2. What the open-creation route looks like

Permissionless creation is possible on different venues. The route ranges from a community forecasting service with play money to an on-chain contract that holds collateral and pays out after a resolution transaction.

Community markets with play money

Manifold’s current FAQ says that anyone can create a prediction market about a question they want. It describes Manifold’s Mana as play money that cannot be converted to cash. The same FAQ says the market creator resolves the market, while moderators may overturn a resolution in exceptional cases. It also explains that creators and other users can add Mana to a liquidity pool. This is a relatively accessible model for questions about a community, a project, or a decision where social reputation and play-money incentives are acceptable. See Manifold’s FAQ.

The tradeoff is visible in the resolution rule. A market can be easy to create because the creator is trusted to interpret the terms, but traders must assess that creator’s reliability and conflicts. A community can add moderation and reputation, yet those controls remain different from an independently verifiable settlement source.

XO Market: an open-creation model with access qualifications

XO Market is an important current example because its public materials explicitly position “conviction markets” as permissionless, user-created Yes/No markets. Its homepage says anyone can create markets quickly, while its terms describe a non-custodial interface, automated market-maker trading, and resolution processes that may use artificial intelligence and the MODRA (Moderated Oracle) framework. See XO Market’s overview and Terms of Service.

The current terms also qualify the word permissionless: access to user-generated market creation requires a Catalyst Badge, which the terms tie to activity, a login streak, and a verified social account. They further state that proposed markets undergo administrative review and require approval before launch. XO is therefore best understood as an open-creation design with an eligibility and review layer in its current implementation, not as a promise that every visitor can publish immediately. This is exactly why creation access, publication approval, trading access, and resolution authority should be analyzed separately.

On-chain markets with collateral

OpenOmen’s current documentation gives a more direct on-chain example. It says that anyone with a connected wallet can create a binary market, trade YES or NO positions with USDC, and have the market deployed through smart contracts. The creator supplies the question, resolution rules, trading close, and resolution deadline. The documentation also states that the creator submits the outcome after trading closes and that the resolution is final and irreversible under that design. See OpenOmen’s market documentation.

This model removes the venue’s pre-publication listing decision, but it adds practical responsibilities: a wallet, transaction fees, collateral, careful handling of keys, a reliable answer to the resolution question, and a plan for what happens if the creator disappears or has a conflict. “On-chain” records how the market is executed; it does not make an ambiguous question unambiguous.

Composable market infrastructure

A third route is to assemble the market from reusable components. Gnosis’s Conditional Tokens documentation describes a condition with an oracle account, a question identifier, and a number of possible outcome slots. Its prediction-market documentation also describes automated market makers (AMMs): smart contracts that provide prices from funded inventories of outcome tokens. The creator or developer still has to define the question, connect it to a resolution mechanism, and fund the market maker. See the Conditional Tokens condition tutorial and AMM documentation.

3. Define the market before publishing

Removing the listing gate does not remove the work of defining the question, outcomes, timing, resolution source, settlement procedure, failure cases, and access restrictions. For that market-definition checklist, see What Does It Take to Create a New Prediction Market?. Its guidance on precise market terms applies equally when users can create markets directly; permissionless creation changes who publishes the market, not what must be defined.

4. Resolution is the central design question

A market does not resolve itself merely because the real-world event has happened. The system needs a rule and an actor or mechanism that applies it. An oracle is the component or process that supplies the event result to the market; it may be a person, an official data source, a smart contract, or a dispute system.

The simplest model is a trusted creator who reads the source and selects the outcome. That is flexible and cheap, but it places trust in one person. Manifold documents this model explicitly: the creator resolves the market and the community can rely on reputation and moderation to address exceptional problems.

A more structured model uses an optimistic oracle. The proposer submits an answer, the system treats it as correct after a challenge period if no one disputes it, and a dispute escalates to an arbitration process. Reality.eth describes this pattern in terms of answer bonds, escalating challenges, timeouts, and a chosen arbitrator. It also warns that an oracle does not discover truth by magic; the question terms and arbitrator still have to be suitable. See the Reality.eth white paper.

UMA’s documentation describes a similar optimistic-oracle architecture: anyone may propose data, a liveness period leaves room for a dispute, and a disputed assertion can be escalated to its Data Verification Mechanism. This can reduce the cost of ordinary resolutions, but it introduces bonds, timing, governance, and dispute-participation assumptions. See UMA’s oracle overview.

A useful resolution specification therefore answers four separate questions:

• What fact or value is being observed?
• Which source or reporter is authoritative?
• What evidence and timing make the answer final?
• What happens when a participant disputes the answer?

5. Open creation does not create liquidity

Permissionless systems make it easier to offer questions. They do not make people trade them. A market needs participants who care about the question, an incentive to provide information, and enough liquidity for a trade to produce a meaningful price rather than a large movement caused by a very small order.

An AMM—an automated market maker—is a program that quotes prices from a pool of funded outcome tokens. Gnosis’s documentation explains that prediction-market AMMs need initial funding and that the resulting prices aggregate trading activity into an odds estimate. In practical terms, the creator or a sponsor may need to provide initial liquidity, explain who bears the risk, and decide whether a shallow market should be visible as a serious forecast. See the Gnosis AMM explanation.

Liquidity is not the same as accuracy. It can make prices easier to trade and harder to move, but it cannot repair a bad question, a conflicted creator, a weak source, or a broken payout rule. Conversely, a well-written market may have little informational value if almost nobody participates.

6. Permissionless is not lawless

A technical ability to publish a market is not a determination that the market may lawfully be offered, traded, or marketed to a particular audience. Legal analysis can depend on the payoff, collateral, operator, user interface, custody arrangement, jurisdiction, participant, underlying event, and dispute process. Access can also be restricted even when creation is open.

The U.S. Commodity Futures Trading Commission (CFTC) explains that event contracts are typically structured as swaps and that regulated exchanges must meet core principles addressing matters such as manipulation, market disruption, position controls, and customer protection. Its material on designated contract markets describes ongoing obligations for the exchanges that operate those markets. See the CFTC’s prediction-market overview and designated contract market guidance. Those sources describe U.S. regulated-market obligations. They do not, by themselves, determine whether a particular permissionless design is lawful or suitable for a specific participant, and they do not turn a permissionless protocol into a regulated exchange.

The practical conclusion is to keep four reviews separate:

1. Technical review: can the chosen system create, trade, resolve, and pay out the market as specified?
2. Integrity review: can a participant influence the event, source, price, or resolution process?
3. Access review: who may create, trade, provide liquidity, resolve, or challenge, and from where?
4. Legal and regulatory review: what rules apply to the particular design and people involved?

7. A practical route for a new market

If the goal is to ask a question that a curated venue does not offer, the following sequence keeps the decision concrete:

1. Choose the purpose. Decide whether the market is for private coordination, a community forecast, research, play-money interaction, or real-value trading. The purpose affects the acceptable resolution and access model.
2. Choose the creation route. A community service may be enough for low-stakes questions. An on-chain protocol may provide collateralized positions and composability. A regulated venue may be the relevant route when its access, controls, and legal structure are required.
3. Freeze the meaning before funding it. Write the display question, complete terms, timing, source hierarchy, payout logic, and failure rules before inviting participants.
4. Select resolution deliberately. Decide whether the creator, an official source, an optimistic oracle, or a dispute mechanism will supply the final result. Record the challenge window and the fallback if the source fails.
5. Plan liquidity and discovery. Identify the initial liquidity provider, the likely participants, the price impact of small trades, and how the market will be distinguished from duplicates or low-quality questions.
6. Test the uncomfortable cases. Try a source correction, a delayed release, a cancelled event, an unavailable creator, a conflict of interest, a disputed answer, and a participant who cannot access the intended source.

Conclusion

Permissionless prediction markets change who gets to ask the question. They do not remove the need to explain what the question means, who can answer it, how people can challenge the answer, or what a price is meant to represent.

For a narrow community or low-stakes forecast, open creation can be a useful way to test questions that a curated venue would not prioritize. For a market involving real collateral or broad public access, the absence of a listing gate makes the specification and governance work more important, not less.

The core test is simple: could an independent participant read the terms, identify the authoritative evidence, understand the timing, assess the conflicts, and predict what happens when the normal path fails? If not, the market is not ready merely because a system allows it to be published.

Sources and citation note

The venue and protocol descriptions above were checked on 29 August 2026. Interfaces, documentation, access rules, and protocol parameters can change. The practical recommendations are my interpretation of the cited mechanics; they are not additional requirements imposed by any one venue or protocol.

• Polymarket Help Center: How Are Markets Created? Current explanation of team-created markets and user suggestions.
• Kalshi Help Center: Suggesting a New Market Current submission route and review considerations.
• Kalshi Help Center: Market FAQs Current information requested for a market suggestion.
• Manifold FAQ User-created markets, Mana, creator resolution, moderation, and liquidity.
• XO Market overview and Terms of Service on its user-generated market design, access qualifications, review, trading, and resolution terms.
• OpenOmen documentation On-chain market creation, collateral, timing, and creator resolution.
• Gnosis Conditional Tokens tutorial and AMM documentation on conditions, oracles, outcome tokens, and liquidity.
• Reality.eth white paper and UMA oracle overview on answer proposals, challenge periods, and dispute escalation.
• U.S. Bureau of Labor Statistics: Consumer Price Index for the U.S. CPI-U, U.S. city average, all-items example used above.
• CFTC: Understanding Prediction Markets and Event Contracts and CFTC: Designated Contract Markets on U.S. regulated-market obligations.

This article provides technical and conceptual guidance. It is not legal advice, a regulatory assessment, investment advice, a recommendation to trade, or a determination that a particular prediction market is lawful or suitable for any person or venue.