How debubblepop works

debubblepop is a Solana protocol for splitting SPL tokens across multiple wallets without creating visible links between them on bubble map visualizers.

You sign one transaction. Your tokens enter a program-owned vault. A relayer distributes them to your recipients on a delay you set. The recipients receive tokens without your wallet ever appearing as the sender. Bubble map tools that cluster wallets by direct transactions see no connection between you and the receiving wallets.

When you send tokens from wallet A to wallet B, that transaction is permanently visible on-chain. Tools like Bubblemaps cluster wallets by these direct transfers — both the token itself and the gas token used to fund the transfer.

If you split a token purchase across multiple wallets you control, every transfer creates an edge on the visual map. Anyone viewing the token's holders sees a connected cluster. Your wallets are now publicly linked.

This breaks privacy for anyone who:

• Holds positions across multiple wallets for operational security
• Distributes tokens to teammates, contributors, or stakeholders
• Manages treasuries with segmented authority
• Wants holding privacy from competitors, exes, family, anyone

Three steps from the user perspective.

Deposit. You connect your wallet, pick the token, list up to four recipient addresses with amounts and individual delays, then sign one transaction. Your tokens move from your wallet into a vault owned by the debubblepop program. A small fee in SOL covers protocol operation.

Schedule. The deposit transaction creates an on-chain distribution record containing each recipient's address, amount, and scheduled execution time. The protocol's relayer picks up this record by watching for new distribution events.

Receive. At each scheduled time, the relayer submits a transaction that transfers tokens from the program vault directly to that recipient's wallet. The recipient receives tokens. Your wallet appears nowhere in the transaction. No direct edge exists between sender and recipient in the token's transfer graph.

Step-by-step user flow.

1. Visit debubblepop.fun and click Launch app.
2. Connect a Solana wallet (Phantom, Solflare, Backpack supported).
3. The form opens. Pick which token you want to split from the dropdown — populated from your wallet's SPL token balances. Or paste a mint address manually.
4. Add up to four recipient wallet addresses. For each, set the amount and a delay (0 to 60 seconds). Different delays for each recipient is recommended.
5. Review the summary — total tokens, SOL fee, expected completion window — then click Split.
6. Approve the transaction in your wallet.
7. The status panel opens. Each recipient row shows progress: pending → scheduled with countdown → executed.
8. Once all recipients are executed, you'll see a link to verify the distribution on Bubblemaps for the token mint. On mainnet tokens, the bubble map will show your recipients as isolated holders with no connection to your wallet.

The debubblepop program is deployed at 9xQLUYcCDAEGVoRgmsSo1SMUBY3USSwnkipUHXh9izED on Solana. It exposes eight instructions. The three that matter for users are deposit, execute, and close_distribution.

When you call deposit, the program does three things atomically: pulls your tokens into a program-owned vault account (one per token mint, shared across all users of that token), creates a distribution record with your recipients and amounts, and collects the protocol fee.

The recipients are stored in the distribution record but no on-chain transfer to them happens yet. Each recipient slot has its own scheduled time based on the delay you chose.

An off-chain relayer watches the program for new distribution events. When a scheduled time arrives, the relayer submits an execute transaction. The program verifies the schedule and recipient, then transfers tokens directly from the vault to the recipient. The relayer signs the transaction but the program PDA signs the transfer itself — using its own program-derived authority, not the user's signature.

The result on-chain: the only transactions involving your wallet are the original deposit (to the program) and any prior history. The transactions involving your recipients show transfers from the program vault. Bubblemaps' clustering algorithm follows direct edges between wallets. Since no direct edge exists between your wallet and any recipient, no cluster is drawn.

The relayer never holds your tokens. The program never sends tokens to the relayer. The program only sends tokens to addresses you specified in the original deposit. If the relayer goes offline, your tokens remain in the program vault and can be reclaimed once all schedules pass (this is the role of close_distribution, which returns the unused state account rent to you).

Honest scope of the privacy provided.

What is protected

• Bubblemaps default view shows no edge between sender and recipients for the token
• Solscan and other explorers don't link the wallets through the token's transfer graph
• Common chain analysis tools that cluster by direct gas-token and same-token transfers don't connect them
• Recipient wallets fund their own gas, no SOL flows from sender

What is not protected

• Anyone reading the program's account state can see your distribution record (depositor address, recipient addresses, amounts, schedule). This data is public on-chain.
• Manual cross-referencing of timestamps and amounts between your deposit and recipient receipts can reconstruct the relationship for a sufficiently motivated analyst.
• Off-chain identification (KYC ties, IP addresses, behavioral patterns across other transactions) is outside the protocol's scope.
• If your recipient wallets ever interact with your main wallet later — sending each other tokens or SOL — that edge is permanent and links them.

debubblepop breaks bubble map clustering. It does not provide cryptographic privacy. For full unlinkability you would need a zero-knowledge mixing primitive, which debubblepop does not currently use. Future versions may add this.

The protocol fee is 0.01 SOL per distribution, paid by the depositor in the same transaction as the token transfer. This fee covers protocol operation and is not refundable.

The depositor also pays:

• Network transaction fee for the deposit (around 5000 lamports / 0.000005 SOL)
• Rent for the distribution state account (around 0.002 SOL, returned when the distribution is closed after all recipients execute)

The relayer covers:

• Network fees for each of the four execute transactions
• Rent for creating new recipient associated token accounts when they don't already exist (around 0.002 SOL per first-time recipient)

Recipients pay nothing.

• Maximum 4 recipients per distribution
• Maximum 60 seconds delay per recipient
• Standard SPL Token program tokens only (Token-2022 not yet supported)
• Solana only

These limits exist for cost and complexity reasons. They are not fundamental to the design. Future versions may relax them.

Direct facts for builders, auditors, and the technically curious.

Phases. No dates, just sequence.

debubblepop is experimental software. The protocol is currently on Solana devnet for testing. Use at your own risk. The protocol breaks bubble map clustering on default views; it does not provide full chain-analysis-grade privacy. Nothing in this documentation constitutes financial, legal, or tax advice.