How it works

Four moving parts. Only one of them holds money, and it is the one nobody has a key to.

1. The vault

Every handle has a vault: a program-derived address seeded from a hash of the handle. It is derived, not generated, so it has no private key — there is nothing to steal or lose.

vault = PDA("v", sha256("handle:v1:someone"))

Anyone can compute it. Nobody can sign for it. It holds lamports and looks like an ordinary wallet to pump.fun, which is exactly what makes it usable as a creator address.

2. The launch

A token is created on pump.fun with the vault as its creator. From that moment every creator fee the token earns belongs to an address the launcher cannot touch.

The vault must be rent-exempt before pump.fun references it, or the runtime rejects the launch. The launch path handles that.

3. Proving who you are

The claim terminal is an ordinary website using Telegram's Login Widget.

It is deliberately not a Mini App. Telegram's blockchain guidelines require Mini Apps to use TON exclusively and list tokens on other chains as not permitted. Regular bots with no Mini App component are exempt, so the bot only ever links to the site.

Telegram signs the login with a key derived from the bot token. The Signer verifies that signature, checks the username matches the handle being claimed, and only then issues an attestation: a 128-byte payload naming the program, the handle hash, the destination wallet, the Telegram ID, a nonce, and an expiry — signed with the attester key.

The attestation says this Telegram account may send this vault's balance to this wallet. It cannot say how much.

4. The withdrawal

The transaction carries the attestation twice: once in an ed25519 precompile instruction that Solana itself verifies, and once as the payload the program reads.

The program checks, through the Instructions sysvar, that the precompile instruction's own declared offsets are self-contained and that the bytes the precompile verified are byte-for-byte the payload it is about to act on. Without that check, an attacker could have Solana verify one message while the program acts on another.

Then it drains the vault to the bound wallet.

Binding

The first successful claim writes the destination into the vault's state. After that, an attestation naming a different wallet is rejected — even a perfectly valid one. Changing the destination needs the current wallet to sign, a fresh login, and a 48-hour delay.

This is what makes a compromised Signer survivable: it could authorise new claims for handles that have never claimed, but it cannot move money that already has a destination.

Paying for gas

The recipient's most likely wallet is one they made minutes ago to receive this. It holds zero SOL — and the fee payer must hold something. Measured: an empty wallet claiming for itself fails outright.

So a gas sponsor pays the fee. It adds no trust:

  • the recipient still signs for themselves
  • the program pays only the wallet named in the attestation
  • the sponsor key can only pay fees; it has no authority over any vault
  • it pays only for attestations the Signer issued, once each, only for wallets that genuinely cannot pay, and only as fee payer

After the first claim the wallet holds SOL and funds itself. Sponsorship is a bootstrap, not a subsidy.