Provably fair: how Sivex Play verification works
What does provably fair mean?
Provably fair means the platform's honesty does not have to be taken on trust — it can be checked with cryptography.
On most trading-competition platforms, you have to assume the operator recorded everyone's trades correctly and did not quietly adjust results. Sivex Play removes that assumption. Every trade leaves an immutable cryptographic fingerprint that anyone can recompute and verify. If the verification passes, the trade is exactly what the platform recorded at the time — and the platform has no way to rewrite it afterwards.
This is the same trust property that makes blockchain settlement different from a bank's internal ledger: the record is structurally tamper-evident, not just policy- tamper-evident.
What does the verifier actually check?
Three independent groups of checks, seven sub-checks total. A trade is "fully verified" only when every available check passes — partial passes (when one check is skipped because Bybit's API is momentarily unreachable, for example) are still acceptable proof.
| Trades unaltered | Five sub-checks proving the event is in a Merkle-committed snapshot, the proof verifies against the recorded root, the IPFS payload matches that root, the chain links to the previous snapshot, and the on-chain Solana commitment matches. |
|---|---|
| Bybit reference | One sub-check confirming the recorded fill price falls within Bybit's 1-minute candle range at the exact tick timestamp (±0.5% tolerance for last-traded vs mark divergence). Catches any inflated or fabricated fills. |
| Nothing hidden | One sub-check confirming the snapshot's recorded eventCount matches the actual event list length. Catches a tampered IPFS payload where events were removed to hide trades. |
Group 1 — Trades unaltered
Cryptographic proof that the trade was recorded exactly when it happened, in the exact form it happened, and that nobody has edited the record since.
Found in snapshot
The platform writes a snapshot every five minutes containing every open and close event since the last window closed. The verifier confirms your specific event is present in the snapshot that covers its timestamp.
Merkle proof verifies
A SHA-256 Merkle proof — the audited sibling hashes that lead from your event to the snapshot's root — re-derives the recorded root exactly. This is the cryptographic anchor that says "this event existed at snapshot time, in this form, no other".
IPFS payload matches the root
The verifier re-hashes the entire event list pulled from IPFS and confirms the recomputed Merkle root matches the snapshot's recorded root. This catches any post-pin tampering of the JSON payload — if someone edited, added, or removed events from the file after the snapshot was sealed, the recomputed root would differ.
On-chain anchor (Solana)
The snapshot worker posts the Merkle root to a Solana program every five minutes alongside the IPFS upload. The verifier confirms the on-chain commitment matches the IPFS root. Once a root is on Solana, it cannot be rewritten — so any later attempt to alter the IPFS data is immediately detectable.
The Solana program is deployed during the Phase 2 production rollout. Until it lands, the verifier shows this sub-check as pending with a clear explainer. The IPFS Merkle proof + the chain integrity check below are sufficient mathematical evidence even without the on-chain anchor. The check lights up automatically once the program is live; no user action needed.
Chain links to previous snapshot
Every snapshot embeds the previous snapshot's root as its previousRoot field. The verifier walks one link back and confirms that field matches the recorded root of the previous snapshot in the database — preventing a "fork attack" where one snapshot is rewritten in isolation. The first snapshot of every tournament chains back to the all-zero genesis root by convention.
Group 2 — Bybit reference
The recorded fill price falls within Bybit's 1-minute candle range at the exact tick timestamp. Catches inflated or fabricated fills that the cryptographic checks can't see.
The Merkle proof says "this event was recorded unchanged" — but it can't say anything about whether the recorded price was real. The Bybit check closes that gap: every Sivex Play fill is sourced from Bybit's real-time price feed; the verifier fetches Bybit's published 1-minute kline at the same tick timestamp and confirms the fill price falls within [low − 0.5%, high + 0.5%].
The ±0.5% tolerance accounts for the natural divergence between Bybit's mark price (what the kline reports) and last-traded price (what individual fills are quoted at), plus any residual clock skew between Bybit's tick and the server's entryTick write. In practice fills sit well within ±0.1%; the wider tolerance just rules out false negatives on edge cases.
Bybit's API can occasionally rate-limit or return no kline for a delisted symbol. The verifier marks the check as skipped in that case — not failed. The cryptographic checks remain authoritative; the Bybit check is corroborating evidence, not the only line of defence.
Group 3 — Nothing hidden
The snapshot is internally consistent. Every event it claims to contain is actually there, and the count matches.
The snapshot records a fixed eventCount field in its metadata. The verifier confirms that the actual events array has that exact length. This catches the case where a motivated party edits the IPFS payload to remove trades they want to hide — without re-hashing, the recomputed root wouldn't match (caught by "IPFS payload matches root"), and the event-count line wouldn't balance (caught here). Two independent paths catching the same tampering is the point.
How is each event canonicalised?
Every event is serialised into a deterministic JSON string with alphabetically sorted keys, then SHA-256 hashed into a Merkle leaf. Anyone with the same event data can recompute the same hash byte-for-byte.
The exact format is documented in src/lib/snapshot/merkle.ts (function canonicalizePositionEvent). The event object is built with these keys in alphabetical order:
| eventAt | ISO 8601 timestamp of when the event occurred. |
|---|---|
| eventType | "open" or "close". |
| exitReason | "manual" | "tp" | "sl" | "timeout" — null on open events. |
| positionId | The TournamentPosition row id (cuid). |
| price | The fill price for this event (entry on opens, exit on closes). |
| priceTickAt | ISO 8601 of the LivePrice tick used to fill, sourced from Bybit's real-time feed. |
| quantity | Instrument quantity (sizeUsdt / entryPrice at open time). |
| realizedPnl | Realised P&L in USDT — null on opens, populated on closes. |
| serverSignature | Reserved for a future server-signed HMAC over the canonical bytes. Empty string today; the tree still binds the event because the rest of the payload is hashed. |
| side | "long" or "short". |
| sizeUsdt | Notional size at the time of the event. |
| stopLoss | SL level set at the time of the event (or null). |
| symbol | e.g. "BTCUSDT". |
| takeProfit | TP level set at the time of the event (or null). |
| tournamentId | The Tournament row id (cuid). |
| userIdHash | sha256(userId + ":" + USER_HASH_SALT) in hex. The salt is a launch-time constant that never changes — rotating it would break verification of older snapshots, so it is fixed for the life of the platform. Salting keeps the per-user identity opaque to casual inspection while still letting the user verify their own events by recomputing the hash with the same salt. |
The bytes are then SHA-256 hashed: leaf = SHA256(canonical JSON bytes). The Merkle tree is built with sorted-pair hashing and no odd-duplication, matching the verification logic used on the Solana side. The recovery property is the key one — given any single event, you can recompute its leaf hash byte-for-byte on any machine with any standard SHA-256 library.
Changing field order or adding a field in the middle of the sort would change the canonical bytes for every event past and future. New fields are only added at the END of the alphabetically sorted set (and only when older snapshots wouldn't contain them, so the verifier knows to skip them on legacy events). This is a structural constraint of cryptographic verification — not a stylistic choice.
Is the score also verifiable?
Yes. The V3 scoring formula is pure arithmetic, so given the canonical events, anyone can recompute a player's score and final rank. The platform cannot recompute the leaderboard differently from what the canonical data implies.
A tournament's leaderboard is derived from each player's closed events. For each player, the formula is:
| netPnlPercent | (closingEquity − startingEquity) / startingEquity × 100. Closing equity is the sum of realised P&L from every closed event plus the starting balance. |
|---|---|
| drawdownPenalty | Drawdown beyond the tournament's threshold (default 3%) is penalised at the multiplier (default 1.5). Formula: max(0, maxDrawdownPercent − threshold) × multiplier. Peak equity is tracked across the closed events; max drawdown is the largest fall from any peak to a later trough. |
| hastePenalty | Closing a position within 30 seconds of opening applies a penalty of 0.5 × |tradePnlPercent|. The sum across all qualifying trades is the player's total haste contribution. |
The full implementation lives in src/lib/tournament/scoring-v3.ts (function calculateScoreV3). It is a pure function — same canonical events always produce the same score, on any machine, with any standard math library.
That means once a tournament's final snapshot is sealed, the leaderboard is mathematically determined. The platform cannot quietly bump someone's score after the fact: any discrepancy between the displayed score and the canonical- events-derived score would be visible to anyone who runs the verifier on a winner's close events.
How do I verify a trade myself?
Verification opens for everyone once a tournament settles. You can read the three-check verdict on the trade page, or download a self-contained proof bundle and re-derive the proof offline with a tiny zero-dependency script.
- Open the trade. From a settled tournament's recap, click into any closed trade or visit
/verify/[positionId]directly. The verifier runs all seven sub-checks and displays the verdict. - Read the verdict. A single banner up top (✅ fully verified, ☑️ verified with caveats, or ❌ failed) and then the three groups with per-check details you can expand.
- Download the proof bundle. The "Advanced — Raw verification data" section has a Download bundle (.json) button. The bundle is a single JSON artifact containing the canonical event, the Merkle proof, the IPFS gateway URL, the on-chain anchor, plus the verification spec — everything a third party needs to re-derive the proof offline.
- Run the verifier script. We publish a zero-dependency verifier at /verify.mjs (Node 18+, ~150 lines, no installs). Run
node verify.mjs <bundle.json>and it prints PASS / FAIL per check. The script is short enough to read top-to-bottom in two minutes — auditing the verifier is itself part of the proof.
The verifier URL is shareable. Once a tournament is settled, anyone can open /verify/[positionId] or /verify/tournament/[tournamentId] and see the proof — no wallet, no auth, no Sivex account. If a skeptic doubts a result, you can hand them the URL plus the downloaded bundle.
What happens if a check fails?
A failing check on the cryptographic side is a serious integrity issue — please contact support. A failing Bybit check by itself can be a data hiccup; the cryptographic checks remain authoritative.
The verifier is honest about which check failed and why. Common "not yet verifiable" states (no snapshot window has closed yet, on-chain anchor pending Phase 2, Bybit kline unavailable for a delisted symbol) are clearly distinguished from "failed" states (recomputed root doesn't match, chain link broken, Bybit kline shows the fill outside the candle range).
A true cryptographic failure — recomputed root mismatch, or chain link broken — would mean the IPFS payload was edited after sealing. Sivex Play has every incentive to know about that immediately; please email support@sivex.io with the verifier URL and a screenshot of the failure.
Why this is rare
Most trading-competition and prop-firm platforms cannot make the "independently verifiable" claim. Their results live entirely in a private database that only the operator can read.
On a typical platform, a player who suspects a result was adjusted has no way to check. They can complain to support, who can reply with reassurance — but the reassurance is policy, not proof. The player has to take it on trust.
Sivex Play inverts that. The proof is the platform's structural commitment: you don't have to trust us, because the math doesn't need our cooperation. A third-party with no Sivex login can pull the IPFS data, recompute the Merkle root, compare to the on-chain commitment, and reach the same conclusion. This is a structural trust advantage — a property of the architecture, not a feature toggle.
For further reading on the system design, see Tournament scoring and How tournaments work.
Common questions
- What does "provably fair" mean on Sivex Play?
- It means anyone can independently verify that a tournament was not tampered with. Every five minutes, every trade is hashed into a Merkle tree, the root is committed to a public ledger, and the full data is published to IPFS — so the platform cannot rewrite results without instant detection.
- Do I need a crypto wallet to verify a trade?
- No. The verifier checks the cryptographic proof using only the public IPFS pin and on-chain commitment. No wallet, no signing, no cryptocurrency required.
- Where is the full tournament data stored?
- Full snapshot JSON is published to IPFS, a public content-addressed file system. The Merkle root that fingerprints that data is posted to Solana mainnet as an on-chain commitment.
- What is the Bybit reference check?
- Sivex Play records every fill price as it happens, sourced from Bybit's real-time price feed. The verifier confirms each recorded fill falls within Bybit's published 1-minute candle range at the same timestamp (±0.5% tolerance for last-traded vs mark divergence). This catches any inflated or fabricated fills.
- What if the Bybit check fails to run?
- Bybit's historical API can occasionally rate-limit or return a missing kline for delisted symbols. In that case the verifier returns "skipped" — not "failed". The cryptographic checks (Merkle proof, IPFS integrity, chain links) remain authoritative; the Bybit check is corroborating evidence.
- How is the trade-recording deterministic?
- Each trade event is serialised into a canonical JSON form with alphabetically sorted keys — same input always produces the same bytes. Those bytes are SHA-256 hashed into a Merkle leaf. Anyone with the same event data can recompute the same leaf hash and verify the proof.
- Is the tournament score also reproducible?
- Yes. The V3 scoring formula (net P&L percent minus drawdown penalty minus haste penalty) is pure arithmetic — same canonical events always produce the same score. Once a snapshot is committed, the leaderboard for that window is mathematically determined; the platform cannot recompute it differently.
- Why does the on-chain anchor sometimes show "pending"?
- The Solana program that records the commitment is deployed during the Phase 2 production rollout. Until it lands, the IPFS Merkle proof is the durable record. The verifier shows the on-chain check as "pending" with a clear explainer, and it lights up automatically once the program is live — no code change needed.
◆ Keep learning
What a skill-based trading tournament is, how a session runs from registration to payout, and how competing against the lobby differs from trading the market.
What a hosted tournament is, why the host has no advantage, and how the Creator Clash, Interval Kings and crews work for players who join one.
How a creator’s community enters a Sivex Play tournament together, how a crew is scored on its top 10 rather than its size, and how the winning crew’s 2% is shared with the people who showed up.
How Sivex Play ranks traders on risk-adjusted return, why drawdown is penalised, and why the scoring model rewards skill over luck.
A direct, evidence-based answer to whether a skill-based trading tournament is gambling — explained through the scoring design.
How a skill-based trading tournament compares with a prop firm challenge — cost structure, time commitment, and what each one actually measures.
How a skill-based trading tournament compares with trading your own money on an exchange — bounded risk, asymmetric reward, and why a market crash does not break your plan.
How TradeLab lets you practise trading free on hidden-outcome historical scenarios, and how each session builds your skill rating.
How the Sivex Rating works — TradeLab practice sets your starting rating, tournaments are how you climb — why it is worth climbing, and what a high rating unlocks as the platform grows.
How the Rating Drop works — a cash pool split every two weeks among the top of the Sivex Rating, who qualifies, how the banded payouts work, and why the pool only goes up.
How the Sivex Play referral program works — 15 days of Sivex Pass for the trader you bring, a freeroll pass for both of you on their first deposit, a Shield per qualified referral, and for creators 2% of what their players deposit plus a per-player bounty, in Free Cash.
A plain-language guide to the Sivex Pass — the Run, the Table and the Sivex Playdesk, what else the Pass carries, how billing works against your wallet, what happens at renewal, and how to cancel.
The answer-first guide to trading tournaments — what they are, every format that exists (exchange contests, demo contests, fantasy apps, skill tournaments), how prize pools work, and what separates skill-based scoring from gambling.
Why most trading-competition entrants blow up, the scoring math that actually decides rankings, and the risk-discipline playbook that wins skill-scored tournaments.
Every kind of crypto trading competition compared — exchange volume contests, demo contests, and skill tournaments — and why identical capital with risk-adjusted scoring levels the field.
Where to compete on gold, silver, and crude oil — how commodity trading contests work, the market hours that shape them, and why XAU is a competition staple.
An honest map of the alternatives to FTMO — other prop firms, free broker contests, and skill-based trading tournaments — with the trade-offs of each model spelled out.
The consistency rules, drawdown technicalities, and discretionary reviews that commonly sit between a passed challenge and a paid trader — and what a no-review payout model looks like.
The 2026 field guide to paper trading competitions — free brand-funded contests, broker arenas, and entry-fee skill tournaments — and how prize density differs across them.
How fantasy stock-picking apps differ from live trading tournaments — drafting a portfolio is not trading, and only one of the two scores execution and risk management.
Plain-language definitions of every term used across Sivex Play tournaments, scoring, TradeLab, and rewards.