How the split actually pays.
Split uses ordinary Bags SOL fee-share v2. It does not take a platform fee, it does not hold a key for you, and it does not pay several X Money accounts from one coin.
The pools
On a new SOL config, Bags registers the wallet that pays for configuration as the deployer. That wallet receives 2,500 bps, 25%, of the gross claimers pool. The percentages you assign still total 10,000 bps and divide only the remaining 75%. Do not withhold 2,500 bps inside the form. A partner share, which Split does not attach, would come out of the platform pool instead.
Default mode charges a 2% trading fee. Before migration, half of that fee is the platform pool and half is the claimers pool. Of the claimers half, the deployer keeps a quarter and the X accounts divide the rest. After migration, 25% of the fee is compounded back into the pool and the platform and claimers pools are each 37.5%. Other modes change the rate and the compounding. Bags rounds each percentage down in lamports. The numbers on the launch screen are that estimate, not a quote.
SOL recipients and cash
An X handle in SOL mode resolves to a Bags wallet. That wallet claims SOL. It is not the same thing as the Phantom or Solflare wallet that signs the launch, unless Bags happens to return that address.
BagsPay cash is separate. One coin can name one X Money, Cash App, or Venmo handle, and the Bags payout wallet must be the only fee claimer at 10,000 bps. Split exposes that as its own mode and refuses to pretend it divides cash. Bags cannot verify that an X account has X Money turned on. Conversion and the public order discount come out of the payout. The deployer share still stays in SOL with the config payer. Bags may also reject the cash handle unless the API key's user owns the token.
A null payout response means the coin has no cash handle. It does not mean the fees are zero, and it does not mean the mint is missing. A mint with no Bags launch record is a different result: fee figures are left blank.
What you sign
Metadata reservation does not spend SOL. After that, your wallet signs lookup-table transactions when there are more than 15 recipients, then the config, then the launch. More than 15 recipients follow the Bags SDK threshold. Transactions are shown for review before the wallet opens. Existing Bags or sponsor signatures are left in place. If you reject one, later transactions are not sent. If a blockhash expires, that step is rebuilt. A Jito tip is added only when Bags returns a bundle and you enter an amount.
Claims are the same idea. Recipient claims do not withdraw deployer SOL. Deployer claims do not withdraw recipient SOL, and a deployer vault withdrawal is wallet-wide even when you start from one coin. Bags still has no request that pays several X Money accounts from one claim. The claim page can continue with a separate route: a live NEAR Intents quote from native SOL into Base USDC, a SOL deposit you sign, then one Peer Cash order per X handle that your Base wallet signs. Relay does not list a Solana chain. The cash-out estimate is not a locked price, the historical ETA is not a guarantee, and an optional receipt-inbox link is not proof that X Money is enabled. Only a Peer order state of delivered means that payout finished. Split does not hold the SOL or the USDC.
The cash sheet lets an operator write down several handles and paper shares. It stays blocked. The only cash transaction Split will ask Bags to build is the documented one-handle config, and only after the connected wallet reviews it.
Operator setup
The server needs BAGS_API_KEY. It is read only on the server and is never put in a public environment variable. Without it, every Bags call fails with a clear configuration error. SOLANA_RPC_URL and NEXT_PUBLIC_SOLANA_RPC_URL default to the public mainnet endpoint. A dedicated RPC is a better place to send transactions you have signed. Split rate-limits its own routes and outbound Bags calls, and it caches short-lived reads. That cache is per server process.