Platform Documentation

Trading Cards is an algorithmic trading platform designed to enhance and simplify the trading space. Users can easily create, backtest, and mint strategies as verifiable financial NFT assets backed with ZK proofs on the blockchain. Investors can also view and verify top-performing NFT strategies and their backtest and live results — Win Rate, Sharpe Ratio, Total Trades, and PnL.

Users have a wide variety of parameters to select from while backtesting — including exchange, symbols, timeframe, patterns, date range, position size, leverage, and more — making this a powerful and dynamic feature.

Algorithmic trading has a trust problem.

Anyone can claim their strategy returns 200% annually. Anyone can publish a backtest screenshot. There is currently no trustless, verifiable way for a strategy creator to prove their results are genuine without revealing the strategy itself — and no way for an investor to verify a claim without simply trusting the person making it.

This creates three compounding issues:

Trading Cards solves all three problems simultaneously using zero-knowledge proofs and the Sui blockchain.

The platform is built on Next.js with a TypeScript API layer, MongoDB for persistent storage, Redis for ephemeral caching, and the RISC0 zkVM running as a native binary alongside the server process.

Frontend (Next.js)
├── Strategies Page  ──→  Backtester Page  ──→  Results + Proof
│         ↕                     ↕                      ↕
│   MongoDB (cards)       SSE Stream            ProofButton
│
API Routes (Next.js)
├── /backtest/stream   GET  SSE progress stream
├── /backtest/cancel   POST Cancel via Redis flag
├── /backtest/prove    POST Run prover + mint NFT
└── /verify            GET  Public proof lookup
        ↓                         ↓
Redis Cache                 RISC0 zkVM Host
proof:candles:{runId}       proof_receipt.bin
proof:entries:{runId}       proof_output.json
        ↓                         ↓
Storage Layer
├── MongoDB   receipts (BSON Binary), proofs, users/cards
├── Walrus    proof_receipt.bin  (blob ID referenced on-chain)
└── Sui       Strategy NFTs (public outputs)

The backtester is the platform's core computation engine, designed to mirror real trading conditions as closely as possible. Backtests run in three sequential phases:

Performance Metrics

Supported Strategies

Backtest Configuration

What is a ZK Proof?

A zero-knowledge proof is a cryptographic protocol that allows one party (the prover) to convince another party (the verifier) that a statement is true, without revealing any information beyond the truth of the statement itself.

How RISC0 Works

Trading Cards uses the RISC0 zkVM — a zero-knowledge virtual machine that can prove the correct execution of any Rust program. The backtest logic is compiled to run inside the zkVM. When the program runs:

1. It takes private inputs — the strategy config, candle data, and trade signals — which are never exposed.
2. It produces public outputs — the candle data hash, trade statistics — which are committed to the proof receipt.
3. The STARK proof receipt cryptographically guarantees that the public outputs were produced by the correct program running on the private inputs.

Private vs Public Outputs

A Strategy NFT is a Sui object that represents a verified algorithmic trading strategy. It is minted after a ZK proof is successfully generated and contains only the public outputs from the proof circuit.

NFT Data Model

struct BacktestProof has key, store {
    id:             UID
    image_id:       String    // RISC0 circuit version
    journal_digest: String    // Hash of all public outputs
    candle_hash:    String    // SHA-256 of candle data
    strategy_id:    String    // Hash of strategy name
    total_trades:   u64
    win_rate_bps:   u64       // 6500 = 65.00%
    total_pnl_bps:  u64       // 2341 = +23.41%
    sharpe_x1000:   u64       // 1840 = Sharpe 1.840
    timestamp:      u64       // Unix ms
    version:        String    // "pattern:proof:v1"
}

Minting Flow

1. User completes a backtest and views results
2. User clicks "Generate Proof" — the platform calls POST /api/backtest/prove
3. The API reads cached candle data from Redis and runs the RISC0 prover
4. The receipt is uploaded to Walrus; the blob ID is stored in the NFT
5. The API calls mint_proof on the deployed Move contract
6. The NFT is transferred to the user's Sui wallet address
7. A transaction digest and Sui Explorer link are returned to the user

Any third party can verify a strategy proof independently, without trusting the Trading Cards platform.

GET https://tradingcards.app/api/backtest/prove?proofId=<id>

curl "https://tradingcards.app/api/backtest/prove/receipt?proofId=<id>" \
  -o proof_receipt.bin

# Install RISC0
curl -L https://risczero.com/install | bash

# Verify
rzup verify \
  --receipt proof_receipt.bin \
  --image-id <IMAGE_ID>

Strategy NFTs represent the base layer of the platform's economic model. Key properties:

Strategy Config Privacy

The strategy configuration is the user's intellectual property. It never leaves the Trading Cards server:

• The config is passed to the RISC0 prover as a private input and deleted from disk after proof generation
• It is stored in MongoDB as _privateConfig for internal audit, but never returned by any API endpoint and never put on-chain
• The ZK proof mathematically guarantees the results without requiring the config to be disclosed

Wallet-Scoped Storage

Saved backtest configurations are stored scoped to the user's Sui wallet address. No authentication system beyond wallet ownership is required.

Candle Data Caching

During backtesting, candle data and trade signals are cached in Redis under the runId with a 2-hour TTL. This data is consumed by the prover and deleted from Redis immediately after proof generation. It is never exposed to the browser.

Proof Receipt Integrity

The proof receipt is stored as immutable BSON Binary in MongoDB and uploaded to Walrus with a 1-year epoch commitment. The receipt is content-addressed — any modification to the bytes would invalidate the STARK proof.