Your first round
measure, check, sign, record.

01Before you start

• Your own RPC endpoint is set and Test the endpoint answers (how).
• A Helius key is set if the token has many holders.
• You have signing tooling for the funding wallet that can take instructions as JSON (below).
• Your fee is set, if you charge one (Your fee).

02The round

1. Create the projectProjects → New project: name, snapshot mint, the asset you send (mint, symbol, decimals), the funding wallet, the minimum per holder, method, dust and remainder rules. With By tier, fill the tier editor and press Read from mint for the snapshot token decimals (Tiers).
2. Add your exclusionsExclusions → Your list: your treasury and team wallets, any burn address you know. Leave detection on.
3. Choose the snapshotIn the run panel, SNAPSHOT: Current slot, or Time-weighted if you have been recording balance samples during the window (how).
4. Dry runEnter the amount the project funds → Dry run. Read who gets what, the estimated network fee, the transactions to sign, Your fee, and what the exclusions removed. Nothing has moved.
5. Check the exclusionsExports → Exclusions · CSV. Look at it before funding anything. A holder who should not be there, or a missing one, is fixed here, not after payment.
6. CommitPress the action button (for example Distribute) → Commit it. SLUICE records the round as prepared. Nothing has moved yet.
7. Fund and sign from your own walletTake the unsigned batches (Rounds → Copy the unpaid batches) and sign and send them with the funding wallet (how). Your fee is its own batch, the last one.
8. Attach the signaturesRounds → the round → paste each Signature, pick its Batch number, Attach and confirm. SLUICE reads the transaction from the chain and marks the batch paid only when it is finalized and its transfers match the batch exactly. A mismatching signature is refused; one the endpoint cannot return yet waits for Ask the chain.
9. Export the audit bundleExports → Audit bundle · JSON. Keep it; it is the durable record of the round: snapshot, exclusions, plan and how to check them.

03Signing the batches

SLUICE never signs and never sends. Each batch is a list of Solana instructions in JSON: the Compute Budget instructions first (SetComputeUnitLimit and, when the priority fee is above 0, SetComputeUnitPrice), then the SPL TransferChecked transfers, with the creation of a missing token account before its transfer. Each instruction carries the program ID, the accounts (with signer and writable flags) and the instruction data in base64 (lib/core/distribute/solana_instruction.dart). There is no blockhash in it: you add a recent blockhash, build the transaction, sign with the funding wallet and send it, using tooling you control, for example a small script with a Solana SDK, or a multisig.

SLUICE ships no signing tool and no wallet connector: the batches are prepared unsigned for the funding wallet, and you sign them with tooling you control. A batch holds up to 18 transfers, or up to 8 when each also creates a token account (Settings → Transaction packing). If you raise the account-creating batch size, raise Compute units per transaction too.

04Recipients without a token account

For direct transfers, SLUICE creates a recipient's token account inside the same transaction as the transfer. The funding wallet pays the rent, about 0.002 SOL per new account; the dry run includes it in the network cost estimate and counts the recipients who need one.

05Token-2022 tokens

The token program is read from the mint, so Token-2022 needs no setting. Two extensions matter: with a transfer fee every recipient receives less than the amount shown (the fee goes to the mint's fee authority, not to you), and with a transfer hook a transfer can fail for reasons SLUICE cannot see, and a failed transfer reverts the whole batch it is in, so use smaller batches in Settings. Both are warned about in the dry run.