Verifiable Settlement on PredictAsiaX (2026)

Verifiable settlement on PredictAsiaX

Published 2026-09-078 minProduct

TL;DR

PredictAsiaX publishes a proof hash for every market settlement into the Trade Explorer, pays winners in USDT on-chain, and anchors periodic Merkle roots to R2 so any client can independently reconstruct and verify that any fill was included in a signed batch. Every disputed outcome is reviewed against the same public record. You never have to take our word for how a market resolved.

Every outcome, provable

Prediction markets only work if the outcome is trustworthy. PredictAsiaX treats every settlement as a public record: the resolved price and a verifiable proof hash are written into the Trade Explorer for every market. Anyone can look up a settled market by ID, read the outcome, and independently confirm the proof — without a login, without asking us, and without trusting our word.

This is the promise made on the Technology & Security page and delivered by the public Verify tools in the API documentation.

What gets published for every settlement

Resolved outcome and price. The exact resolved price, side (YES / NO for binary markets), and timestamps are attached to the market's settlement record.
Proof hash. A cryptographic hash of the settlement inputs, published alongside the outcome. Anyone can reconstruct the same hash from the same inputs.
On-chain USDT payout transactions. Winning payouts are executed on-chain and every transaction can be verified on a public block explorer, independently of any PredictAsiaX dashboard.
Merkle audit inclusion. The settlement is included in a batch whose Merkle root is periodically anchored to R2 storage. Any client can call the audit endpoints to reconstruct the proof and confirm inclusion.

How verification works, end to end

Trade or settlement event happens. The event is written to the operational ledger with all fields needed for later reproducibility.
Batching. Ledger events are grouped into batches. Every batch produces a Merkle root deterministically from its contents.
Anchoring. Merkle roots are anchored to R2 storage and published. Anchored roots cannot be silently rewritten — any subsequent change to the batch contents would produce a different root.
Client-side reconstruction. The docs.predictasiax.com Verify section documents six no-auth read endpoints under /v1/audit/*. Any client can query for a fill, request the batch it belongs to, and confirm the Merkle path back to the published root.

The result: any fill you place, and any settlement you receive, can be independently proven to have been included in a signed batch. You never have to trust our dashboards.

Independent review before payouts move

Outcomes are confirmed by our operations layer before any payout is released. This is a deliberate design choice — not to introduce discretion, but to catch data-source ambiguity, feed errors, and edge cases that automated resolution alone would miss. The confirmation is recorded into the same public settlement record, so the review is auditable.

Once the outcome is confirmed, winning positions are paid instantly in USDT — no manual queue, no waiting on approvals.

The formal dispute window

Every settled market has a formal dispute window during which any user can raise a challenge. Challenges are decided against the published settlement proof, not against verbal claims. The outcome of any review — upheld, corrected, or dismissed — is written back into the same public trail. Because Merkle batches are anchored, silent rewriting of a decided settlement is impossible: it would break the audit chain in a way that any client running the verification flow can detect.

Capital protection sits underneath

Verifiable settlement only matters if the money moves when it should. Two design choices support that:

Real USDT only. Every balance is settled in USDT. There is no simulated balance and no play money — each position reflects real funds.
Segregated insurance fund. A dedicated insurance fund, financed by a fixed share of every settled market, absorbs extreme outcomes so payouts are never held up by a liquidity gap. The moment a market resolves, winners are paid — the fund exists to bridge unusual settlement obligations without delay.

Trying it yourself

Open the Trade Explorer and pick any recently settled market.
Note its market ID and the published proof hash.
Read the Verify section of the API docs and run the audit query for that market.
Confirm the reconstructed hash matches the published one, and that the fill is included under the anchored Merkle root for its batch.

If any step disagrees with the public record, that is a bug and we want to hear about it.

Frequently asked questions

What does 'verifiable settlement' mean on PredictAsiaX?

Every market settlement records the resolved price plus a proof hash in the public Trade Explorer. Anyone — trader, builder, auditor — can look up any settled market by ID, read the outcome, and independently confirm the proof hash without asking PredictAsiaX for anything. Winnings are then paid in USDT on-chain, where every transaction is separately verifiable.

Where do I look up a settled market's proof?

Open the Trade Explorer on predictasiax.com/explorer, search by market ID or by keyword, and open the market's settlement record. You will see the resolved outcome, the resolved price, timestamps, and the proof hash for that settlement. The Trade Explorer has no login requirement for read access.

How do PredictAsiaX proofs work end-to-end?

Every fill and settlement event is written to an operational ledger. Batches of ledger events are hashed together into a Merkle root. The Merkle root is periodically anchored to R2 object storage and published, so the batch cannot be silently rewritten later. The docs.predictasiax.com Verify section documents the six no-auth read endpoints under /v1/audit/* that let any client reconstruct proofs and confirm any specific fill was included in a signed, R2-anchored batch.

How are winnings paid?

Winning positions are paid in real USDT the moment a market resolves — no manual queue, no waiting on internal approvals. Payouts settle on-chain, so every transaction can be confirmed for yourself against the public blockchain, independently of any dashboard on predictasiax.com.

What happens if a settlement is contested?

Every settled market has a formal dispute window during which any user can raise a challenge. Challenges are reviewed directly against the published settlement proof, not against verbal claims. The published record is the authority, and the review outcome is recorded back into the same public trail. This is documented in the platform's Technology & Security page.

Do I have to trust PredictAsiaX for outcomes?

No. That is the point. Every outcome is confirmed by our operations layer before payouts move — never released unchecked — and every outcome is published with a proof that any third party can verify. Integrity is something you can check independently, not something you have to take on faith.

Are outcome resolutions ever changed after publication?

Only through the dispute window process, with a full public record of the challenge and its resolution. Because Merkle batches are anchored to R2 with published roots, silent rewriting is not possible — a changed record breaks the audit chain, which is detectable by any client running the /v1/audit/* verification flow.

What is the segregated insurance fund and how does it relate to settlement?

A dedicated insurance fund — financed by a fixed share of every settled market — absorbs extreme outcomes so payouts are never held up by a temporary liquidity gap. This means the settlement moment is decoupled from platform-level cash flow: the moment a market resolves, winners are paid, and the insurance fund exists to bridge unusual settlement obligations without delay.