01 / Coins and recipients
A community coin launched through BITTIPS has its own name, ticker, artwork, description and mint. Its Twitch recipient is a separate identity. A coin can direct its support allocation to a streamer without using that streamer’s name or portrait as its artwork.
Many different coins can share one recipient. Fees must still be attributed per mint. When support from several coins funds a single Bits delivery, each contributing allocation needs its own ledger entry. A shared recipient does not merge the coins, balances or trading markets.
A community-created coin is not an endorsement by the recipient. Before public launches, recipient verification, impersonation handling and an opt-out process need to be in place.
02 / Creating a coin
Enter your coin name, ticker, description and artwork, choose a verified Twitch recipient and optionally set your first buy. Your coin identity stays independent of the recipient profile.
Select Review & launch to verify your wallet and prepare the coin. Review the first-buy cap and token amount, then approve Launch coin in Phantom. Creation, locked creator-fee routing and the optional first buy execute atomically. Trading fees are included in the buy cap; account rent and network fees are additional. The coin appears on Explore after finalization.
03 / Fee allocation and costs
The split applies to collected creator fees, not total trading volume: 80% is allocated to the linked Twitch recipient’s support budget and 20% to the BITTIPS buyback-and-burn budget. A coin’s market cap is not money held by the treasury.
Accrued fees, claimed fees, allocated budgets and delivered support are separate figures. A random treasury deposit is not automatically creator-fee revenue. Claims need the source mint, source transaction and recipient attribution.
The 80% is a spending budget, not a promise that 80% reaches a streamer as cash. Network, conversion, card and Bits purchase costs affect the result. Card, conversion and Bits purchase costs are charged to the recipient’s 80% allocation. Buyback-specific execution costs still need their own disclosed policy. The protocol must record each cost explicitly and never count it as delivered support.
04 / From fees to bits: reconciliation
1. Claim creator fees. Verify the on-chain transaction and its source mint. Split the received amount into recipient-support and buyback allocations using integer base units.
2. Fund the card. Index successful incoming transfers to the permanent card address and reconcile the provider’s settled credit separately. An invoice created or paid on-chain does not by itself prove that the card has been credited.
3. Buy Bits. Match the approved card purchase with its purchased Bits quantity, currency and costs. Authorized purchases are available immediately; the original card settlement status is retained in transaction details. Merchant text alone cannot prove the Bits amount or final recipient. Refunds and reversals must adjust the ledger.
4. Send the Bits. Match recipient-specific delivery evidence to a reduction in Bits inventory. Assign the delivery to the coin budgets that funded it. Buying Bits and sending them are different events; never count both as support delivered.
5. Buy back and burn. A swap proves token acquisition; a burn transaction proves destruction. Record both signatures, the BITTIPS mint, amounts and costs. The worker combines the exact-output purchase and burn in one atomic transaction; activation awaits the BITTIPS mint.
05 / Treasury and transaction history
The Payments and Capital flow pages request the treasury’s native SOL balance and latest 25 signatures from Solana mainnet at finalized commitment. The server caches snapshots for up to 60 seconds and displays the retrieval time. SPL tokens and fiat card balances are not included in native SOL.
Unknown or unavailable balances display a dash, not zero. Card balance comes from a timestamped SolCard snapshot. Recorded recipient allocations and buyback reserves come from the verified fee journal. They are separate from wallet and card balances; an empty journal means no claims have been indexed. Wallet signatures are presented as unclassified activity, not assumed fee claims or payouts.
The homepage fee total comes from verified claims in the journal. Unavailable data is never replaced with sample balances, trades, gifts or charts.
06 / Twitch identity and status
Explore lists the newest finalized coins and supports search by name, ticker, recipient or mint. Only finalized registered coins are listed. Market reporting comes from DexScreener when a matching market is available.
Twitch profile lookup resolves a handle to Twitch’s stable user ID and checks the current stream status. Renaming a handle must not redirect existing coin allocations to a different person. If live badges are added later, they must come from Twitch’s Get Streams API and carry a freshness timestamp; fetch failures must display unknown rather than offline.
One streamer can receive support from many coins. Stream category and live status belong to that recipient, not to the coin. The profile-check action is ready; The hosted environment needs its own Twitch credentials; a supported delivery workflow is still required.
07 / SolCard integration
SolCard documents an MCP connection for reading cards, balances, card activity and deposit invoices. It uses account authorization. The published tools do not provide a general-purpose merchant-checkout or money-transfer operation.
An assistant connected to SolCard is not automatically a persistent backend integration for BITTIPS. Production syncing needs authorized access, a supported server-side integration, stable event IDs, retry handling and deduplication. The read-adapter boundary, duplicate-safe event store, and deposit/purchase matching rules are implemented. SolCard also advertises an institutional API through an inquiry process; the local reporting worker now has a separate read-only OAuth flow, encrypted credentials, retry handling and a validated provider mapping.
Public receipts should expose only relevant amounts, currencies, statuses, references and allocation evidence. Full card numbers, CVC, access tokens and unrelated account activity must stay out of the public site.
08 / What the backend does today
Working: direct coin creation, uploaded artwork, atomic first buys and read-only Solana treasury reporting. The backend also has stable recipient and coin tables, exact 80/20 allocation, and an append-only fee-claim journal with duplicate protection. Twitch profile lookup uses configured server-side application credentials. Wallet connection does not grant the server permission to spend funds.
Implemented with activation gates: wallet-signed pump.fun launches, finalized fee indexing, registered-coin market data and encrypted hosted SolCard reporting. Automatic claims include graduated AMM fee sweeping. The worker checks every five minutes and claims above 0.2 SOL. The 80% card funding batches at 0.39 SOL; the 20% is reserved until BITTIP_MINT is configured, then used for an atomic buyback and burn. Bits purchases can be matched to settled card charges, allocated per coin and reconciled against confirmed recipient deliveries.
The fee-claim journal is fed by the configured finalized pump distribution indexer. Card-address transfers and Twitch merchant charges are reported separately. The Bits journal records purchase matches, per-coin inventory and confirmed recipient deliveries separately. Repeated submissions cannot double-count inventory; corrections preserve the original audit record. Public delivery totals include confirmed deliveries and exclude reversed records.
Official references
BITTIPS