Roadmap

What is live, what is next, and what is deliberately not being built yet.

Anything under Live has a script in the repository that demonstrates it against a real cluster. Anything under Next does not exist yet, and is described here as a plan rather than a feature.

Live on Solana mainnet

Launch a token on pump.fun whose creator fees go to a Telegram handle
Fee splits from 50% to 100%, frozen on-chain by pump.fun so nobody can change them afterwards -- not the launcher, not us
Claim by proving your Telegram account, with the network fee covered if your wallet is empty
A public board of every launch, the handle it pays, and whether the split is locked

Telegram Stars rewards

Rewarding recipients and launchers in Stars, Telegram's own currency.

Worth being precise about the obstacle, because it is not effort. Paying out in Stars means somebody takes custody of the SOL, sells it, and buys Stars -- which is the one thing Handle is built to avoid. Right now nobody can move your money, including us; a Stars payout rail would change that.

So this waits for a route that does not require custody, or for it to be built as an explicitly separate, opt-in product with its own disclosure. It is on the roadmap because it is wanted, not because the path is clear.

Robinhood and Pons routes

Extending fee routing beyond pump.fun.

Pons was examined in detail and is not ready to carry Handle's main promise: its launch factory has no renounce, and the owner override sits behind a three-day timelock. A Pons launch can therefore never honestly display as Locked -- the fees can always be redirected, just slowly. Supporting it means either showing a weaker badge beside the Solana one, or waiting for a contract that can be renounced.

Robinhood's chain is the more interesting target and has not been assessed yet.

Other social handles

X, Discord, GitHub and others, using the same vault design.

Nothing in the program is Telegram-specific: a vault is keyed to a hash of a handle, and the only Telegram-shaped part is the login that proves ownership. Each new network needs a verification path of the same standard -- a signature from the platform itself, not a screenshot or an API call we trust.

Also planned

Withdraw as USDC -- swapped inside the same non-custodial transaction, so choosing how you get paid never means handing anyone custody
Notifications -- the bot tells a handle when fees have arrived, instead of hoping they check
Group and channel claims, not only personal handles
A keeper that pushes accrued fees into vaults on a schedule, batched so gas never exceeds the fee on a quiet token

Not planned

Anything that requires holding your money. The design's whole value is that the vault has no private key. Any feature that would need custody gets built as something separate and clearly labelled, or not at all.