Autonomous Prediction Market Oracle Interface: initial SEP draft

[zkpato]

What

Propose SEP-0059 (Draft), defining a read-side Soroban contract interface and event schema for prediction-market platforms to expose autonomously-resolved market outcomes as a generic oracle.

A conforming market commits its resolution rules on-chain as a content hash at creation time. Resolution publishes the outcome together with a hash of the inputs the rules were executed against, so any third party can fetch both, re-execute, and verify the published outcome off-chain.

The standardized surface is intentionally small:

• Trait PredictionMarketOracleTrait: pmo_version, market_spec, outcome, and an optional paginated markets discovery method.
• Data model: content-addressed MarketId = sha256(canonical_spec_bytes); Binary / Categorical / Scalar / Invalid outcomes; ResolutionProof carrying inputs_hash, attestation_method, and a method-specific attestation_data payload.
• Events: ("pm_created", market_id) and ("pm_resolved", market_id) carrying the spec and the resolution respectively, so indexers can reconstruct provider state from event history.
• Attestation symbols: AUTONOMOUS_V1 (primary), RESOLVER_ASSERTION_V1 and ORACLE_AGG_V1 reserved so providers with different trust models can still expose outcomes through the same interface.

Provider-internal concerns (positions, liquidity, payouts, settlement) are explicitly out of scope. Disputes are out of scope by design, they belong to human-judgment resolution models and can be added by a future SEP without breaking consumers of autonomous markets.

Why

Prediction markets produce verifiable, crowd-sourced signals (event outcomes, parametric resolutions) that downstream protocols want to consume, lending hooks, insurance triggers, DAO actions, parametric DeFi. On Stellar today there is no standard for reading those outcomes, so each consumer has to learn each provider's contract layout, encoding, and trust model individually. That per-provider integration cost is what has historically blocked oracle composability.

SEP-40 solves this for price feeds, this SEP fills the analogous gap for event resolutions. The two are intentionally complementary: a consumer can read "what is the price of X" from a SEP-40 feed and "did event Y happen" from a SEP-59 provider in the same transaction, and link them via the optional underlying: Asset field that reuses SEP-40's Asset enum verbatim.

The reference implementation will land at github.com/fermah-labs/sep-prediction-market-oracle, and the first conforming provider will be Flashcast Social, whose existing autonomous-resolution pipeline is the production motivation for this SEP.

Discussion: Github

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds a new SEP draft (SEP-0059) specifying a Soroban prediction-market oracle interface and registers it in the ecosystem SEP index.

Changes:

• Added SEP-0059 draft describing data model, interface, events, and attestation methods for autonomous prediction market outcomes.
• Updated the ecosystem README to include SEP-0059 in the active proposals table.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
ecosystem/sep-0059.md	Introduces the SEP-0059 specification (interface, events, rationale, security).
ecosystem/README.md	Adds SEP-0059 to the list of Draft proposals.

[leighmcculloch]

Hi @zkpato, SEP numbers are assigned by the person merging the change, which is often just whatever next version is available at the time of merge, so the SEP number will be determined that way just before merge rather than be assigned based on a request.

I noticed that this SEP is being posted at the same time as the discussion meaning this proposal has had no opportunity for public discussion prior to being formalised (see the SEP process). Discussions before hand can gather feedback and build confidence in a proposal before it becomes formalised and may have more success in finding adoption.

Are you wanting to formalise the proposal and for it to be assigned a number and merged now or would you like to hold off, focus on the discussion, then revisit formalising once you've gathered feedback? I can merge it now if the intent is to formalise now, just wanted to check before merging. Reply here to let me know.

[zkpato]

Hello @leighmcculloch , this PR and discussion were opened at the same time as Fermah applied to the Stellar Community Fund (using the form + a referral code), so I wanted to have something more tangible to show in the form itself. What's the best process here given that have I applied for SCF?

Regarding the discussion, I'd actually like to follow the correct procedure. All feedback is welcome from the community as we'd love to have Stellar be a part of this adoption.

Let me know how to proceed here!
Thank you.

[leighmcculloch]

Since it sounds like you're still seeking a discussion about the proposal at #1936, I changed this PR to draft to take it out of the review queue. But whenever you're wanting to move the idea to a formal SEP, feel free to click Ready for review on the PR and the proposal will fall back into our review queue and get assigned a number and merged.

[leighmcculloch]

Recommend dropping the 'SEP-59' references while the discussion is in its early stages, as another proposal is already assigned that number.