A schedule layer for tokens

01 Abstract

Crypto markets still treat “tokens are locked” as a social claim. Teams post screenshots. Spreadsheets stand in for contracts. Holders cannot independently verify amount, beneficiary, or unlock time. Launchpads often lock liquidity. Developer wallets remain liquid. Duplicate tickers make a tweet an unreliable identifier. The contract address is the only one that matters, and it is rarely paired with a page that reads a vault.

Phanterium is an immutable ERC-20 vault on Robinhood Chain. A creator deposits tokens under a schedule. After the transaction confirms, nobody can cancel, shorten, or redirect the position. Only the named beneficiary can claim, and only when the clock allows. Every position has a public proof URL that reads live state. When that URL is shared, the card unfurls the same fields.

Robinhood Chain is an EVM L2 with ETH as gas. Finality is fast enough that a lock can feel like a receipt rather than a multi-block wait. Protocol fees are ETH. Fifteen percent of each create fee pays referrals. The rest buys the Phanterium token on the open market and burns it. There is no emission schedule.

02 Introduction

Token distribution is a time problem. A team that intends not to sell still has to prove it. Investors who accepted a cliff still have to receive only what has accrued. A community that was told “dev locked” still has to check. Existing rails solve this on other networks: Streamflow on Solana, Sablier on several EVM chains. Robinhood Chain needed a native one that treats public proof and clear ETH-gas economics as product, not as an afterthought port.

Phanterium is that rail. The first job is narrow on purpose: seal an amount, publish a page, let anyone verify without permission. Vesting, streams, airdrops, escrow, and staking extend the same surface without weakening the rule that existing vault principal cannot be moved by an admin.

This litepaper is a product and protocol description, including how fees fund token buybacks. It is not a securities offering and not investment advice. A buyback tracks fees actually collected. It is not a price target.

03 The problem

On a new chain, pads ship quickly. Liquidity lock is often included. Wallet lock is not. Three failures repeat.

Unlocked developer supply

An LP lock stops a pool from being pulled. It does not stop tokens sitting in a deployer wallet from hitting the market. Holders who equate “LP locked” with “team locked” are reading the wrong primitive. If a pad sent 100% of supply into LP, the remaining risk is the dev buy. That balance needs its own vault.

Proof as theater

Duplicate tickers are common. A tweet is not an identifier. A PNG of a dashboard is not state. Without a URL that reads a contract, “team locked until Q3” is unverifiable and therefore cheap to fake. The market then discounts all such claims, including honest ones.

Manual transfers do not scale

Team, investors, payroll, and community drops need schedules. Ad-hoc sends create operational error and no public record. Cliff-then-linear release is a known pattern. It should exist as a contract, not as a calendar reminder.

04 Design principles

The vault is designed around five constraints.

1. Immutability after write. A position that can be cancelled by the creator is not proof of anything. Phanterium does not offer that path on vault principal.
2. Pull, then hold. Tokens leave the creator at creation. A lock that left tokens in the deployer wallet would be a promise, not a position.
3. Beneficiary exclusivity. Only the address set at creation can claim. Visibility is public. Control is not.
4. Proof as a default. If holders cannot open a page without signing in, the lock exists only for the creator. Every position publishes.
5. Fees cannot seize principal. Protocol revenue is charged at creation in ETH. It never sits in the locked balance and cannot be claimed out of it.

05 Position model

A position is a fixed tuple written once. The contract stores token, beneficiary, creator, credited amount, claimed amount, start, cliff, and end. Credited amount is what the vault actually received. For tokens that take a transfer fee, that may be less than the amount the caller intended. The position is never credited more than arrived.

Indexes exist by creator, beneficiary, and token so a wallet or a contract address can list its positions without an off-chain indexer. The explorer and proof pages can read the same arrays.

06 Schedules

Two shapes cover the jobs that matter on day one.

Hard lock

Cliff equals end. Nothing is claimable until the unlock timestamp. Then the remaining credited amount can be claimed in full. This is the anti-dump primitive: a public, dated commitment over a specific balance.

Linear vest

After the cliff, released amount grows every second between start and end:

released(t) = amount × (t − start) / (end − start)

Before the cliff, released is zero even if t has passed start. At or after end, released is the full amount. Claim pays the difference between released and claimed. Repeat claims are allowed. A vest whose start is already in the past is rejected at creation so a proof page cannot advertise a lock while most of the bag is already liquid.

A schedule that would already be fully unlocked at confirm is also rejected. A lock that is already over is not proof of anything.

07 Lifecycle

The path is short on purpose.

1. The creator approves the ERC-20 spend and sends the ETH fee with the create call.
2. lock takes the fee from msg.value, pulls the token into the vault, writes the position, and emits Locked and FeePaid.
3. The proof page and share card read that record.
4. When the schedule allows, the beneficiary calls claim. Tokens move to that address. Claimed is emitted. Claimable of zero reverts.

There is no pause on existing principal, no upgrade hook that rewrites a position, and no admin function that changes beneficiary. Reentrancy on claim is blocked. If protocol parameters ever change, they apply only to future creates.

08 Why Robinhood Chain

Phanterium is written for Robinhood Chain’s EVM model: ETH for gas and for protocol lock fees, and a public explorer anyone can open.

ETH as gas and fee

Users already know how to fund an EVM wallet. Gas is ETH. The lock fee is also ETH, paid as msg.value at create time no separate fee-token approve.

Fast finality

Robinhood Chain finalizes quickly. The preview a user signed is the position that appears. Proof pages do not wait extra blocks to know the vault already holds the tokens. That matters when the lock itself is the public signal, posted next to a contract address within minutes of a create.

Flat create cost

Denominating the protocol fee in ETH keeps the create path simple: one asset for gas and fee. Predictable create cost is part of making proof a habit rather than a trade.

09 Public proof

A lock that only the creator can see is a private diary. Phanterium publishes every position at a stable path. The page shows amount, token, beneficiary, countdown, claimed, and claimable, read from the contract. No account is required to view it.

Sharing that URL is the distribution layer. When it is posted, the open-graph card is rendered from the same fields, including unlock time and share of total supply. Investors stop asking for screenshots. Duplicate tickers stop hiding behind a PNG. The operational rule for the market is: if it is not on the proof page, it is not locked.

An explorer lists activity by lock id, wallet, token, and transaction so a holder who was never sent a link can still search.

10 Modules

Locks and vesting are the core. Adjacent modules reuse the same rule: they must not create an admin path over vault principal that already exists.

11 Fee design

Phanterium charges a flat ETH fee at lock creation, currently 0.0019 ETH (about $5), plus network gas. A split create is 0.0034 ETH (about $9) flat, charged once. Referral commission is fifteen percent of that fee, paid to the referral pool; the rest goes to the platform treasury. The fee never enters totalLocked.

Later modules may price per recipient, per streamed dollar, or per reward. None of those fees can move tokens that are already locked. Protocol revenue is not a backdoor into the vault.

Users pay ETH. Fifteen percent of the create fee is referral commission. The remaining eighty-five percent is reserved for buyback of the Phanterium token, described next. The fee still never enters the locked balance.

12 Token economy

The Phanterium token exists so protocol usage has a sink. Locks, vests, and the other modules charge ETH. That ETH is the only demand the protocol itself creates. Nothing is minted to pay holders, and nothing is emitted on a schedule.

Each create fee is split once, at collection.

The path is mechanical.

1. A creator locks or vests and pays the flat ETH fee, 0.0019 ETH, or 0.0034 ETH on a split.
2. Fifteen percent of that fee is reserved for the referral pool.
3. The remaining eighty-five percent stays with the protocol treasury.
4. Treasury ETH is used to buy the Phanterium token on the open market.
5. The tokens acquired in that buy are burned. They leave circulating supply.

Buy size follows fee volume. A week with more locks buys more. A quiet week buys less. The burn does not invent demand the product did not earn, and it does not set a price. Holding the token is not a claim on someone else’s locked balance, not a vote that can cancel a position, and not a yield.

13 Security

The vault is intentionally small. Positions are immutable after write. Claim is non-reentrant. Token amounts use a width that fits real supplies without wasting storage. External token calls require a successful return; fee-on-transfer tokens are credited by balance delta, not by the amount the caller specified.

Minimum duration and “end must be in the future” exist so a confirmed lock is actually a lock. Start-in-the-past is rejected for vests that would otherwise present as locked while already largely claimable.

Treasury is set at initialize and is not rotatable in this implementation. New deploys put the locker behind a UUPS proxy, so the owner key can replace the logic. Users should still treat unaudited bytecode with caution and should verify the canonical deployment they are asked to approve.

14 Trust boundaries

Phanterium trusts the chain’s clock, the ERC-20 it received, and the user’s wallet. It does not trust the token’s future mint, tax, blacklist, or upgrade. A lock covers the deposited balance. It does not cap total supply. It does not make a honeypot sellable. It does not freeze a malicious admin on the token contract.

The interface never asks for a signature that is not approve, create, claim, or an equivalent module action. Canonical domain only. Pages that impersonate Phanterium to run “airdrop checkers” are outside the protocol and should be treated as hostile.

Software, not a custodian beyond the contract. Not investment advice. A public proof page is evidence of a schedule, not of a project’s quality.

15 What this is not

• Not a launchpad, AMM, or chart.
• Not an LP lock. That is the pad.
• Not a custodian beyond the smart contract.
• Not a guarantee that a token is safe.
• Not an emissions token. The protocol does not mint supply to pay users. Retained fees buy the Phanterium token and burn it.

The job stays narrow: time-lock a balance, publish the proof, let holders verify without asking permission.

16 Closing

Markets discount claims they cannot check. Phanterium makes the check cheap: a URL, a vault, a clock. Robinhood Chain makes the act of writing that vault cheap and final. Together they turn “dev locked” from a caption into a position.

Operational detail lives in the product documentation. To open a position, launch the app on Robinhood Chain.