Security model

The vault program has exactly these instructions: create a vault, claim (attested), claim SPL tokens (attested), bind and freeze a payout address (attested), forward to the bound address (permissionless), request, cancel and finalize a wallet rebind, rotate attestors (timelocked), and pause claims. There is no withdraw, sweep or close instruction, for us or anyone else.

• Vault funds only leave through a claim or a forward, and both only pay the streamer's bound wallet.
• Pausing stops claims; it never moves funds. Deposits keep arriving while paused.
• The protocol treasury receives its share through pump.fun distributions only. It holds no authority over vaults.
• Our servers hold no user funds and no platform tokens (they are revoked immediately after login).

Why it is needed

A Solana program cannot check a Twitch or Kick login, and it cannot read who owns a pump.fun profile. So when a streamer claims or binds a payout address, our backend confirms the proof and signs a 244-byte message: “the owner of this platform account may pay this vault to this wallet, once, before this time”. The program verifies that signature through Solana's built-in Ed25519 program before it releases anything.

How the key is protected

• KMS. On mainnet the attestor key is an Ed25519 key inside a cloud KMS (hardware-backed). It never leaves the HSM and is used for nothing else. The devnet key is kept in a server environment variable; the DEMO key is generated in memory and changes on every server start.
• Rotation timelock. Changing the attestor set takes a proposal, a public event and a 48-hour wait before it can be accepted.
• Public log. Every attestation we issue is published at /trust/attestations with its message hash, vault and time, so misuse would be visible.
• Bound wallet. Once a payout address is bound (by a first claim or a payout binding), a vault only pays that wallet. Changing it takes 72 hours and can be cancelled by the current wallet. A leaked attestor key cannot redirect money from a bound vault.
• Large-claim delay. First claims above a threshold wait in a public pending state, giving time to cancel a fraudulent one.
• Short-lived and single-use. Each attestation expires 5 minutes after issue and carries the vault's current nonce, which the claim increments.

Planned for v2: two independent attestors (ours and one run by a separate party), both required to sign.

No login needed. Your payouts go only to an address you published yourself. A vault's payout address can be bound in five ways (four for Twitch and Kick, two for pump.fun); the full rules are in How streamers get paid.

Evidence

Every observation is stored as a public evidence record: source, URL, time, a hash of the raw snippet, a short text excerpt and the address. Its SHA-256 (the evidence hash) is written into the binding attestation, so the on-chain binding points at exactly what we saw. We read channel descriptions and stream titles only through the official Twitch and Kick APIs, tip pages only when linked from that description, and never scrape. pump.fun has no official public API; we read public profiles through the same endpoints its own website uses (details in For integrators).

pump.fun: signature from the profile wallet

• Who may sign. Only the wallet that owns the pump.fun profile (its canonical_svm_wallet). We re-read the profile when the signature arrives, not just when the message was issued, so a profile that changed hands in between is refused.
• What is signed. A plain-text Sign-In With Solana message that names our domain, the profile and the payout wallet. Changing any of them breaks the signature, so a signature cannot be replayed to bind another wallet.
• Replay. Each message carries a random nonce, is valid for 10 minutes and is accepted once. At most 20 messages per network per hour.
• No transaction. Signing a message cannot move funds or approve anything. Wallets show it as a message, not a transaction.

Freeze

• Published addresses are re-checked about every 6 hours. If the address disappears or changes, or the source fails 3 times in a row, the binding freezes at once.
• A freeze stops payouts and nothing else: funds stay in the vault and the bound address does not change.
• Our attestor can freeze a binding (attestation kind 4) but can never redirect one: the program rejects a freeze whose recipient is not the address already bound.
• Unfreezing takes the same address seen on 2 checks at least 24 hours apart, or explicit proof (Reclaim, profile-wallet signature, code, login).

Auto-forward limits

• forward(vault) is permissionless and has no recipient argument: it can only pay the bound wallet, and only while the binding is active and not frozen.
• Per-vault rate limit: at most 50 SOL per rolling 24 hours, with a minimum interval between forwards. Anything above waits or is claimed explicitly by the streamer.
• First bindings of vaults holding more than 25 SOL wait 24 hours in public; wallet changes wait 72 hours.

What protects the program itself, beyond its instruction set. Each item shows where it stands today; the program is not deployed yet.

A fixed 244-byte binary message (layout v2), little-endian. The domain tag STRMFEES:ATTEST\0 is deliberately brand-neutral so that renaming the product does not change the protocol. The program compares every byte.

user_id is a 32-byte field (with its real length in user_id_len) because the three platforms identify accounts differently. Twitch and Kick use numeric IDs, written as decimal ASCII (up to 20 digits). pump.fun identifies a profile by a UUID; we write it as its 32 lowercase hex characters without dashes, so d0d0a1c3-4f2b-4e6d-8a1f-00000000c001 becomes d0d0a1c34f2b4e6d8a1f00000000c001. The same bytes are the last seed of the vault address.

A claim transaction carries the attestation like this:

0..n  pump_fees.distribute_creator_fees_v2   (coins with pending fees, optional)
n+1   Ed25519Program verify                 (attestor pubkey, 244-byte message, signature)
n+2   vault.claim(amount)                   (reads the instructions sysvar, checks the message)

These properties are tested before any deployment and must hold on every version of the program:

• Nothing except a valid attested claim, or a forward to the bound wallet, can move lamports out of a vault or take it below rent.
• A replayed attestation fails (the nonce must equal the vault's current nonce).
• An expired attestation fails, and so does one for the wrong cluster or the wrong program.
• An attestation for vault A cannot release funds from vault B.
• Once a wallet is bound, a claim or forward to any other recipient fails.
• A freeze attestation can only name the wallet already bound; the attestor cannot redirect a bound vault.
• A forward never exceeds the per-vault rate limit and never runs while the binding is frozen.
• Pausing claims never moves or locks deposits.

pump.fun's global admin can reset a coin's fee-sharing config through its community-takeover process. After a reset, new creator fees may no longer reach the streamer's vault. We cannot prevent it; we detect it. The indexer watches ResetFeeSharingConfigEvent and the coin page shows “fee split reset by pump.fun”. Everything already distributed stays in the vault.

Before mainnet we will decide whether to screen payout wallets against public sanctions lists when issuing an attestation. If we do, a blocked wallet simply cannot receive an attestation; the funds stay in the vault and the streamer can claim to another wallet.

Found a vulnerability in the site, the attestation service or the program? Report it privately first, with steps to reproduce. We will confirm within 72 hours and credit you publicly if you want.