From creator fees to clear receipts SplicePaid: a fair share, a clear record. A creator project rarely belongs to one person. There may be a designer, a developer, a community team and a treasury, all doing different work around the same launch. Deciding how funds should be shared is only the beginning. Someone still has to check the addresses, calculate the amounts, approve the payment and leave a record that everyone can inspect. SplicePaid brings those steps into one Solana workspace. It connects token creation on Raydium LaunchLab, creator fee collection, saved allocation plans and wallet-signed SOL payments. The idea is straightforward: make the route from a source of funds to its recipients visible, and make the resulting payment easier to verify. Start with the launch The launch flow asks for the token details and metadata needed to prepare a Raydium LaunchLab transaction. The connected wallet reviews and signs that transaction. The supported creation flow does not include an initial token purchase. Network fees and account rent still apply, and the wallet remains the place where the user approves the action. Creating a token is not a promise of trading activity or creator income. Available fees depend on actual activity and the relevant protocol configuration. SplicePaid treats the launch, fee collection and eventual payout as separate actions, each with its own transaction review. That separation helps keep the current state understandable at every step. Collect what is available When LaunchLab creator fees are available for the connected wallet, the collection flow prepares a claim from its aggregated creator vault. Those fees arrive as wrapped SOL. The workspace also provides a separate conversion step for turning an entered amount of available wrapped SOL into native SOL before a SOL payout. For supported migrated pools, creator fee collection is a separate pool action. The connected wallet must be the pool creator. The amounts and protocol deductions are determined on-chain, so the transaction deserves the same review as any other wallet action. An available claim, a completed claim and a spendable SOL balance are different states. Give the split a shape A split plan records who should receive a payment and how the total should be allocated. Each recipient has a label, a Solana wallet address and a percentage. The current plan supports one to six distinct recipient wallets, with the percentages adding up to exactly 100 percent. A label makes the plan readable; the wallet address determines the destination. For example, a team might choose an illustrative 50 percent, 30 percent and 20 percent allocation for three recipients. Those percentages describe its own intended distribution. They are not a recommended allocation, a return projection or a promise that money has already moved. Saving that plan records an intention. It does not authorize automatic withdrawals or execute a payout. Review, then sign To make a payment, the user enters a SOL total against the saved plan. SplicePaid calculates the recipient amounts in lamports, Solana's smallest native unit, so the transfers can account for the full entered amount. The wallet must hold enough SOL for the payout and its network fee. Very small totals can be rejected when a recipient's share would round to zero. The user then reviews the proposed payment and signs with the connected wallet. The supported split sends the recipient transfers together in one transaction. Until that transaction succeeds, the saved allocation remains a plan rather than proof of payment. A submitted signature can also remain pending while the chain processes it; submission alone is not completion. Leave a record people can check A public receipt follows verification of a successful payment. The verification checks the expected signer, recipient addresses, transferred amounts and payment memo against the recorded intent. That makes the receipt useful for a collaborator who wants to understand what happened without reconstructing the calculation from messages or screenshots. SplicePaid's connector mark expresses the same idea: one source, distinct paths and visible endpoints. The instrument-like interface keeps the controls and connections in view. It is a practical way to approach creator payments: decide the split, review the transaction, sign deliberately and share a record grounded in the completed transfer.