TWARP Whitepaper

I. Introduction

Timewarp Foundation issues $tWARP (ProofOfTime) on Ethereum mainnet. The project separates when new supply enters circulation from who receives it: a fixed genesis allocation, then up to 500,000 additional tokens released on a public block schedule through the TimeVault contract.

Holders with tokens in their own wallets accrue vault emissions pro-rata. There is no deposit into the vault, no admin withdrawal of user funds, and no discretionary mint after launch configuration is complete.

II. Design principles

• Time, not coordination — Emission rate is tied to Ethereum block height, not governance votes or off-chain promises.
• Self-custody earns — Reward weight uses wallet balanceOf; the vault mints to itself and pays claims on demand.
• Fixed ceiling — Maximum supply is 1.5M tWARP (1M genesis + 500k vault cap), enforced on the token contract.
• LP-neutral emissions — Liquidity pool balances can be excluded from the reward denominator so emissions target holders outside the pool.
• Minimal admin surface — Admin configures wiring once; the schedule starts with a single irreversible call.

III. The tWARP token

ProofOfTime is a standard ERC-20-style token with a restricted mint path. The deployer may call gatherTWARP() once to mint 1,000,000 tWARP. The deployer may call setMintManager(address) once to assign the sole vault minter. Only that manager can invoke mintTWARP(to, amount), and every mint is checked against MAX_SUPPLY.

IV. TimeVault

TimeVault implements the 365-day emission schedule. It maintains a global reward index (rewardPerTokenStored) and per-wallet snapshots (userRewardPerTokenPaid, rewards).

Core user-facing actions:

• claim() — Accrues global state, settles the caller’s share, and transfers owed tWARP from the vault balance.
• accrueRewards(holder) — Updates global state and one holder’s accounting without transferring (useful for interfaces).

On each accrual window with positive eligible supply, the vault mints scheduled tWARP to itself, increases totalMinted, and bumps the reward index by amount / eligibleSupply.

V. Supply schedule

Schedule math assumes ~12 second Ethereum blocks (7,200 blocks per day). The vault runs for 365 days (2,628,000 blocks) with two halvening steps that double the per-block rate.

Integer per-block rates sum to slightly less than 500,000 tWARP; when the schedule completes, the final accrual tops up to the VAULT_MINT_CAP exactly. After startBlock + SCHEDULE_BLOCKS, no further vault mint occurs.

VI. Rewards & claiming

Eligible supply = token totalSupply minus the configured LP pool balance (if any). A wallet’s reward balance is its tWARP balanceOf, except the excluded pool address always counts as zero.

A holder’s pending rewards grow when the global index increases while they hold eligible tWARP. Transfers update who earns going forward; accrual is lazy — calling claim() or accrueRewards applies all mints since the last global update.

If eligible supply is temporarily zero (e.g. all circulating tokens sit in the excluded pool), the vault defers minting for that window rather than dividing by zero; backlog can accrue when eligible supply returns.

VII. LP pool exclusion

Before enableTWARP(), the admin may set setExcludedPool(pool) to a Uniswap (or other) LP token holder address. Tokens in that pool do not count toward eligible supply and cannot earn rewards. This is intended so emissions reach self-custody holders rather than being stranded in the pair contract.

If no pool is configured, eligible supply equals total supply for reward purposes.

VIII. Launch sequence

1. Deploy ProofOfTime and TimeVault.
2. TimeVault.setNativeToken(token)
3. Optional: TimeVault.setExcludedPool(lp) (before start).
4. ProofOfTime.gatherTWARP() — 1M tWARP to deployer.
5. ProofOfTime.setMintManager(vault)
6. TimeVault.enableTWARP() — starts the clock (irreversible).

Until step 6, startBlock is zero and the schedule is inactive. See live parameters on Contracts and App.

IX. Immutability

• No public mint on the token; vault is the only minter after setup.
• No vault admin function to withdraw user principal or redirect emissions.
• Schedule rates and caps are constants in contract code.
• enableTWARP() cannot be undone; halvening boundaries are fixed at deployment.
• Claims are permissionless once rewards are accrued.

X. Risks & disclaimer

This document describes intended smart-contract behavior. It is not financial advice. Participants should verify contract addresses on Contracts, review published contract source before interacting, and understand Ethereum risks: smart-contract bugs, wallet loss, gas costs, MEV, and market volatility.

Admin keys used before launch can misconfigure wiring or start the schedule early; after enableTWARP(), emissions follow code, not discretion. Third-party interfaces, RPC providers, and oracles (if any) are outside the core contract trust model.