Tokenomics (TIMLG)¶
This page documents protocol economics as implemented for the TIMLG MVP: what is staked, how rounds settle, and how funds are routed.
It also includes a token distribution section, but marks it as TBD until the project formally defines supply, allocations, and vesting.
Scope
This page is about protocol rules and incentives, not an investment pitch.
What exists today (MVP-aligned)¶
Economic unit (base units)¶
- The protocol accounts in base units (
u64). - TIMLG uses
decimals = 9, meaning 1 TIMLG = 1_000_000_000 base units. - This decimal configuration is consistent across all environments (Devnet and Mainnet).
Implementation note
The on-chain program does not enforce mint decimals; stake_amount should be interpreted as base units of the configured mint.
Why this exists¶
The economics are designed to: 1. Enforce commit–reveal integrity (discourage “commit then disappear”). 2. Keep settlement deterministic and auditable from on-chain state. 3. Support a treasury model for long-term sustainability (infra + future reviews).
Outcomes and routing (MVP)¶
After the pulse is finalized and the reveal window closes, each ticket is classified:
| Outcome | Condition | Economic effect (MVP) |
|---|---|---|
| WIN | valid reveal and matches assigned target bit | user may claim: refund stake + mint reward |
| LOSE | valid reveal but does not match | stake is burned during token settlement |
| NO-REVEAL | no valid reveal by deadline | stake is burned during token settlement (same as LOSE) |
No promises
Rewards are protocol-defined accounting outcomes. They are not guarantees of profit, yield, or investment returns.
Ticket rent (SOL) and “residue zero” cleanup¶
Each ticket is an on-chain account that holds a rent-exempt lamport deposit. This deposit is not part of the TIMLG reward.
- Winners claim SPL tokens via
claim_reward(stake refund + minted reward). - After settlement (and after claim if you won), the ticket owner should call
close_ticketto close the ticket PDA and reclaim its lamports.
This keeps the system “residue zero” for users: token outcomes are auditable on-chain, and the network deposit is recoverable by the user.
Claim + settlement model (what happens and when)¶
TIMLG separates “classification” from “distribution”:
- Commit: stake escrowed into the round token vault (legacy code name:
timlg_vault) - Pulse: oracle publishes the 512-bit pulse (Ed25519 verified)
- Reveal: proof of commitment (guess + salt)
- Finalize: round is locked
- Settle tokens: losers and unrevealed are burned
- Claim: winners can claim refund + mint
- Close ticket: users close finished tickets to reclaim the ticket account’s SOL rent deposit (
close_ticket) - Sweep: after a grace window, round vault native SOL and remaining SPL tokens are swept to their respective treasuries (tickets are not closed by sweep).
This separation makes the protocol easier to audit and harder to exploit with timing tricks.
Anti-griefing design¶
The primary griefing pattern in commit–reveal systems is:
- users commit, then refuse to reveal (to influence outcomes or stall settlement)
TIMLG addresses this by: - enforcing slot-bounded windows - routing NO-REVEAL stake to be burned (prevents “free option to disappear”) - burning LOSE stake (makes spam participation costly)
Supply intuition (MVP)¶
Per ticket, the token supply changes like this:
- WIN: supply +1,000,000,000 base units (reward is minted on claim)
- LOSE: supply −1,000,000,000 base units (stake is burned during settlement)
- NO-REVEAL: supply -1,000,000,000 base units (stake is burned during settlement)
If the experiment is truly unbiased for a single bit (p ≈ 0.5) and participants are not advantaged, then in expectation:
E[Δsupply] ≈ +0.5 − 0.5 = 0(ignoring NO-REVEAL)
Token Flow Visualization (Expectation)¶
The following diagram shows the statistical flow of the TIMLG token per round.
MVP nuance
The reward is minted only when the winner claims. If winners do not claim, fewer rewards are minted while loser burns still happen → the system becomes net deflationary relative to “all winners claim”.
Fees (On-Chain Reference)¶
The system enforces a dual‑fee model to sustain the network and incentivize participation.
| Fee Component | Description | Current Default |
|---|---|---|
| Reward Fee (bps) | Percentage taken from the winner's reward before minting. | reward_fee_bps = 500 (5%) |
| Reward Fee Pool | SPL‑token vault PDA that receives the accumulated fees. | reward_fee_pool (Seed: reward_pool) |
| Replication Pool | Reserved for future protocol‑level replication incentives. | replication_pool (Seed: replication) |
Fee Calculation Logic¶
When a ticket outcome is determined as a WIN, the protocol calculates fees before minting:
// Logic implemented in programs/timlg_protocol/src/instructions/reward.rs
let fee = reward_amount * reward_fee_bps / 10_000;
let net_reward = reward_amount - fee;
The fee is transferred to the protocol's fee pool, and only the net_reward is minted to the participant. These parameters are stored in the Tokenomics account and manageable by the admin.
Token distribution (TBD)¶
The project name/ticker has been updated to TIMLG (TimeLog).
A full “launch tokenomics” plan is not finalized yet, including: - total supply / emission schedule - allocations (team, treasury, community, liquidity, advisors, etc.) - vesting and unlock schedules - exchange/liquidity strategy - governance distribution (multisig / DAO transition)
Until defined, the public docs will only describe protocol economics (how the game settles and routes value), not a market distribution plan.
Good public practice
When distribution is defined, publish it in a versioned whitepaper release (e.g., v0.2) and mirror a summarized version here.
What is intentionally not published here¶
- private treasury operations / signer custody procedures
- relayer/oracle operational runbooks
- any detail that enables unauthorized authority changes or fund movement