Penyelesaian boleh disahkan di PredictAsiaX

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

1. Trade or settlement event happens. The event is written to the operational ledger with all fields needed for later reproducibility.
2. Batching. Ledger events are grouped into batches. Every batch produces a Merkle root deterministically from its contents.
3. 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.
4. 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

1. Open the Trade Explorer and pick any recently settled market.
2. Note its market ID and the published proof hash.
3. Read the Verify section of the API docs and run the audit query for that market.
4. 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.