TIMLG Protocol¶

A verifiable, slot-bounded commit-reveal protocol on Solana.

TIMLG couples deterministic on-chain settlement with a publicly verifiable 512-bit randomness pulse, wallet-level statistics, and a documentation set designed for technical verification.

Protocol Specification Current Status Devnet App

What TIMLG is, in one picture¶

You commit a hidden bet. The protocol then publishes a public random pulse from NIST. You reveal your bet. The on-chain program decides win or lose deterministically. Tokens settle automatically.

What TIMLG is — commit, pulse, reveal, settle

Read the full protocol overview →

How a round works¶

Every round is a slot-bounded sequence of windows. The order is fixed: commits close before the pulse arrives, the pulse closes before reveals expire, and settlement runs on top of the result.

Round lifecycle — commit window, pulse, reveal, settlement, claim

Read the lifecycle in detail →

Why nobody can cheat — the Hawking Wall¶

Commits must be sealed before the pulse becomes public. There is a wall between "what you can know when you bet" and "what the protocol will use to settle". The wall is enforced by Solana slots, not by trust.

The Hawking Wall — commit before the pulse, settle after the pulse

Read the timing windows →

Where the randomness comes from¶

A set of independent oracles each fetches the same NIST Beacon pulse and signs it. The on-chain program only accepts the pulse when a threshold of those signatures agrees, and it verifies a cryptographic chain back to the previous accepted pulse. No single oracle can substitute the value.

Read the oracle trust model →

What happens to your tokens¶

Every ticket has four possible terminal states. Wins mint a reward and refund the stake. Losses and no-reveals burn the stake — the protocol is deflationary by design. Refunds are a safety fallback for oracle outages. The per-ticket SOL service fee funds a separate jackpot pool.

Tokenomics — mint on win, burn on loss, refund on oracle outage, fee to streak jackpot

Read the tokenomics →

The Streak Jackpot¶

Every ticket commit pays a small SOL fee that accumulates in an on-chain pool. Anyone whose consecutive-win streak beats the global record can claim the entire pool in one transaction — and becomes the new record holder.

Streak Jackpot — pool funded by fees, claimed by whoever breaks the on-chain record

Read the Streak Jackpot mechanic →

Protocol snapshot¶

Topic	Current Devnet MVP
Randomness flow	Commit window closes before the oracle pulse is published; the pulse is verified on-chain
Outcome model	WIN / LOSE / NO-REVEAL / REFUND
Settlement rule	WIN = claimable stake refund + reward mint; LOSE and NO-REVEAL = burn
Oracle model	OracleSet quorum (M-of-N Ed25519) with on-chain NIST chaining (`output_value` + precommitment)
Round creation	Permissionless, gated by an on-chain canonical-target rule
Wallet analytics	`UserStats` tracks cumulative counters and consecutive-win streaks
Streak incentive	`StreakLeaderboard` PDA + `claim_streak_jackpot` (active on-chain)

Verifiable surfaces today¶

Surface	What a reviewer can check
Lifecycle	Commit → pulse → reveal → settle → claim / refund / sweep / close
Economic routing	Stake escrow, deflationary burn, reward mint, fee routing, treasury surfaces
Account model	PDAs for config, rounds, tickets, stats, vaults, treasuries, oracle set, leaderboard
User history	Wallet-level counters and consecutive-win streaks via `UserStats`
Timing	Slot-bound deadlines, grace windows, and refund timeouts
Source code	Anchor program, IDL, and TypeScript SDK at `github.com/richarddmm/timlg-protocol`

For technical readers¶

If you want to go deeper than the visual tour above:

Protocol Overview

Architecture, lifecycle, oracle quorum boundaries, and treasury surfaces.

Open Overview
Oracle Trust Model

Quorum-based pulse acceptance, on-chain NIST chaining, and the recovery mode.

Read Oracle Trust
Settlement and Tokenomics

Outcome routing, burn logic, fee model, and the streak jackpot funding source.

Read Settlement Rules
User Statistics & Streak Jackpot

Wallet-level counters, streak rules, and the on-chain jackpot claim flow.

Open User Statistics

Documentation policy¶

The site distinguishes clearly between:

implemented MVP behavior (current Devnet deployment),
future hardening (mainnet trajectory), and
explicit out-of-scope material (privileged operational topology and key custody).

That distinction is deliberate. It keeps the protocol easier to review, easier to audit, and easier to evolve without rewriting past claims.

Downloads and historical references¶

The canonical specification of the protocol lives in the Architecture Overview and the rest of the Protocol section. The PDF documents below are kept for historical and external-citation reference; in case of any discrepancy, the live protocol pages and the on-chain program are authoritative.

TIMLG Whitepaper v1.2 — Live audit integration and protocol dynamic hardening (February 2026)
TIMLG Whitepaper v1.1 — Pre-multi-oracle revision (February 2026)
TIMLG Whitepaper v1.0-beta — Initial protocol-implementation alignment (January 2026)
TIMLG Whitepaper v0.1 — Initial conceptual draft (December 2025)

Source code: github.com/richarddmm/timlg-protocol.