How SPLIT works.
SPLIT is programmable revenue routing for token launches. It lets a project define who participates in token revenue, how much each participant receives, and where those funds belong.
The simple version: a token generates revenue, SPLIT applies a predefined allocation, and the resulting shares are routed to the configured recipients.
Core concepts
The protocol model has three parts: a revenue source, a split configuration, and a set of recipients. Keeping those parts separate makes the system easier to understand and lets future integrations change how revenue enters without changing the way allocations are displayed or calculated.
Revenue source
The source that produces value for the token. This may include creator fees, trading fees, or another supported revenue stream.
Split configuration
The permanent rule that maps the full revenue amount across a set of recipients.
Public receipt
The human-readable record showing the token, recipients, wallet addresses, and allocation percentages.
Recipients
A recipient is any destination included in the allocation. It has a label, a wallet address, and a share represented in basis points. Labels are descriptive rather than restrictive: a recipient might be a creator, holder rewards pool, community treasury, charity, OTC counterparty, liquidity operation, artist, or buyback wallet.
Allocation rules
SPLIT represents percentages as basis points. One basis point equals 0.01%, and 10,000 basis points equals 100%. Integer basis points avoid floating-point ambiguity and map cleanly to future on-chain instructions.
Creator 4,000 bps 40% Holders 2,500 bps 25% Charity 1,500 bps 15% OTC pair 1,000 bps 10% Treasury 1,000 bps 10% ──────────────────────────── Total 10,000 bps 100%
Exactly 100%
A configuration cannot be finalized while it is underallocated or overallocated.
One to ten recipients
The upper bound keeps public receipts readable and transaction construction predictable.
Explicit wallets
Every recipient must resolve to a destination address before the split can be reviewed.
Locked configuration
The recipient list and basis-point values are intended to become immutable when finalized.
Rounding and precision
Values entered as percentages are converted to basis points. A share of 12.34% becomes 1,234 basis points. Because the total is checked as integers, the validation result is deterministic: it either equals 10,000 or it does not.
Creating a split
The configurator is organized into three stages so that identity, economics, and confirmation remain separate.
- 1
Describe the token
Enter the token name, ticker, description, image, and optional project links. This metadata gives the public split page its identity.
- 2
Define recipients
Add each recipient label and wallet address, then set its percentage. The live routing diagram and segmented bar update as shares change.
- 3
Review the agreement
Confirm the complete list, exact percentages, and 100% total before finalization. This is the point to catch incorrect addresses or misunderstood allocations.
A permanent split should be treated like a financial configuration. Labels help humans understand the route, but the wallet address is the actual destination.
Public split receipts
Every finalized configuration is designed to have a public URL. This page acts as the canonical, shareable explanation of the token's revenue routing.
A receipt presents the token identity, lock status, total allocation, routing diagram, recipient addresses, percentage shares, and any recorded revenue totals. It can also generate a social image so teams can publish the allocation alongside a launch announcement.
What a receipt proves
- The complete allocation totals 100%.
- Each recipient and destination wallet is visible.
- The token has one stable reference page for its economics.
What a receipt does not prove by itself
A visual receipt is an interface layer. On-chain verification depends on the underlying protocol adapter, indexed account state, and transaction history. SPLIT keeps these concerns separate so the product can display the same clear model while the data source advances.
Architecture
The application is built around a protocol adapter rather than coupling interface components directly to a particular program or launch platform. The UI requests actions and data through a stable interface.
interface SplitProtocolAdapter {
createToken(input): Promise<TokenResult>
createSplit(input): Promise<SplitConfiguration>
getSplit(mint): Promise<SplitConfiguration | null>
getProtocolStats(): Promise<ProtocolStats>
getDistributions(mint): Promise<Distribution[]>
}This boundary is important. A Pump fee-sharing adapter, a direct Solana program adapter, or another launch integration can satisfy the same product contract. Pages such as Create, Explore, and the public receipt do not need to be rewritten when the data source changes.
Current status
The current configurator is a product preview. It validates allocations, generates a split configuration, and demonstrates the public receipt experience, but it does not submit a Solana transaction or request a wallet signature.
Production activation requires a live protocol adapter, indexed split accounts, wallet transaction construction, error recovery, and independent security review. The interface intentionally makes no explorer links or transaction claims before those systems are connected.