Wallet System

Transaction Ledger

Every financial operation that flows through the Predictu platform is recorded in an immutable transaction ledger. This provides a complete audit trail of every balance change, enabling dispute resolution, operator reconciliation, and regulatory compliance.

Append-only by design: The transaction ledger only supports new entries. To reverse a transaction, a new compensating entry is created. This means the full history of every operation — including reversals and retries — is permanently preserved.

What Is Tracked

Every wallet callback — whether it succeeds, fails, or is retried — creates a ledger entry. Each entry captures the full context of the operation:

The type of operation (bet placement, win payout, sell, refund, rollback, or loss notification)
The amount involved and the resulting balance
A unique identifier for idempotency and cross-referencing
The operator’s response status and timing
A reference linking back to the originating trade, position, or settlement
Timestamps for when the operation was initiated and completed

Transaction Types

The ledger tracks every type of balance operation that occurs on the platform:

Bet placement — Player purchases shares. Funds are debited from the player’s balance.
Position sale — Player sells shares back. Proceeds are credited to the player’s balance.
Win payout — Market resolves in the player’s favor. Winnings are credited.
Loss notification — Market resolves against the player. No funds move, but the event is recorded for completeness.
Refund — Market is voided. The player’s original cost is returned in full.
Rollback — A trade failed after funds were debited. The original debit is reversed.
Balance check — A read-only query to verify the player’s current balance. No funds move.

Idempotency

Every transaction carries a unique request identifier that serves as an idempotency key. If the operator receives the same request twice — for example, due to a network retry — they can safely recognize the duplicate and respond without reprocessing. This prevents double-debits and double-credits even under unreliable network conditions.

Callback Audit Trail

In addition to the transaction-level ledger, every individual HTTP callback attempt is recorded separately. A single transaction may have multiple callback attempts if retries were needed. This granular logging captures the full lifecycle of each operation, including timing, response details, and any errors encountered along the way.

Retry visibility: Network errors and transient failures trigger automatic retries with exponential backoff. Each attempt is logged regardless of outcome, so operators can see exactly what happened during any communication issue.

Reconciliation and Compliance

The immutable transaction ledger serves multiple critical business functions:

Operator reconciliation — Operators can request a transaction report for any time period and compare it against their own records. Every transaction includes a shared reference identifier that both sides received.
Dispute resolution — When a player questions a balance, support can trace every operation that affected it, including the operator’s response and timing for each one.
Operator reporting — Operators can view and filter all transactions for their players through the dashboard, organized by type, date range, or individual player.
Regulatory compliance — The immutable, append-only ledger satisfies audit requirements for financial record-keeping in regulated markets.

Focused Simplicity

The transaction ledger is intentionally focused on recording facts: what balance operation was requested, and what the operator responded. It does not contain business logic about trading, risk assessment, or settlement decisions. All business decisions happen in the layers above it, keeping the ledger clean, trustworthy, and easy to audit.