Splits Protocol

Splits create immutable, self-executing agreements for distributing incoming funds. Key mechanisms include:

• Percent Splits: Automatically route a percentage of incoming value to each recipient.
• Waterfall Splits: Distribute funds in a specific priority order until a recipient's cap is met.
• Recurring Splits: Enable continuous, automated payouts for subscriptions or salaries.

As a primitive, Splits integrate seamlessly into other smart contracts and applications. This enables:

• Treasury Management: DAOs can use a Split as their primary treasury to automate fund allocation.
• Royalty Enforcement: NFT marketplaces can route creator royalties directly through a Split contract.
• Modular Stacks: Developers can embed Splits into their dApps for features like affiliate payouts or protocol fee distribution without rebuilding the logic.

The protocol is designed for efficiency and user sovereignty.

• Single Transaction Distribution: Funds are distributed to all recipients in one on-chain transaction, minimizing gas costs compared to manual, individual transfers.
• Direct Custody: Funds are never held by a central intermediary; recipients can withdraw their allocated share at any time from the immutable Split contract.
• Transparent Ledger: All distribution logic and historical transactions are verifiable on-chain.

Splits support complex recipient structures beyond simple addresses.

• Nested Splits: A recipient can be another Split contract, enabling hierarchical or organizational structures (e.g., a Split paying into a team Split, which then pays individual members).
• Contract & EOA Support: Recipients can be any Ethereum address, including Externally Owned Accounts (wallets) and smart contracts.
• Immutable Logic: Once deployed, the recipient list and distribution percentages cannot be altered, ensuring trustlessness.

A split's distribution logic is immutable once deployed. This eliminates centralization risk but means errors are permanent. Some implementations use proxy patterns for upgrades, introducing a trust assumption in the proxy admin. Key considerations:

• Audit the immutable logic of the core split contract.
• Verify proxy admin controls if applicable; a malicious admin could upgrade to a malicious implementation.
• Understand that recipient addresses and shares cannot be changed post-deployment in standard designs.

Value allocated to a split is not automatically forwarded. It is held in the split contract's escrow until a distribute function is called. This creates two key operational aspects:

• No loss of funds: Funds are safu in the contract, accessible only to valid recipients.
• Claiming gas costs: Recipients or an external caller must pay gas to trigger distribution, which can be a UX hurdle.
• Passive accumulation: Funds can accrue over time from multiple sources before a distribution event.

Managing split participants involves specific security constraints:

• Permanent commitments: In most designs, recipients and their shares are set at creation and cannot be altered, requiring a new split for any changes.
• Revocable streams: Some advanced implementations integrate with streaming protocols (e.g., Superfluid), where distributions are continuous and can be revoked by the payer, adding a different trust dynamic.
• Access control: Ensure the split creator correctly set recipient addresses; a typo can permanently divert funds.

Applications building on top of splits must account for several edge cases:

• Handling ETH vs. ERC-20: Split contracts typically handle native ETH and ERC-20 tokens separately. Integrators must use the correct function (distributeETH vs. distributeToken).
• Accounting for decimals: Mismatches in token decimals between the asset and the split's internal accounting can cause rounding errors or failed transactions.
• Frontend simulation: UIs must accurately simulate distribution amounts off-chain, which requires correctly parsing the split's stored share allocations.

The on-chain, transparent nature of splits has real-world consequences:

• Transparent ledger: All distributions are permanently recorded on-chain, creating a clear audit trail for tax authorities.
• Income recognition: Recipients may need to recognize income at the time funds are escrowed in the split, not when they claim them, depending on jurisdiction.
• Legal entity abstraction: A split is not a legal entity. Parties should have off-chain agreements (e.g., a partnership contract) governing the on-chain split to resolve disputes.

A distribution logic that prioritizes payouts to recipients in a specific, pre-defined order. Funds are allocated to the first recipient until a target amount is met, then "waterfall" down to the next. This is crucial for modeling tranched payments, debt repayment, or ensuring key stakeholders are paid first.

• Example: A project might allocate revenue first to investors until a 2x return is achieved, then to the founding team, and finally to a community treasury.

The core smart contract instance created by the Splits Protocol. It holds the configuration for a specific group of recipients and their allocation percentages. Once deployed, any ETH or ERC-20 tokens sent to this contract's address are automatically split according to its rules.

• Key Property: Each split has a unique, deterministic address on-chain.
• Use Case: A DAO treasury, a creator collective revenue pool, or a royalty distribution setup.

An on-chain address (EOA or smart contract) designated to receive a portion of funds distributed by a Split Contract. Recipients are defined with a specific allocation share, represented in basis points (e.g., 5000 for 50%).

• Types: Can be individuals, multisigs, other Split contracts (enabling nested splits), or protocol treasuries.
• Distinction: The protocol differentiates between active recipients (who can trigger distributions) and passive recipients.

The two primary actions for moving funds out of a Split Contract.

• Distribute: An active recipient calls this function to trigger the proportional payout of a specific token to all recipients. This pays the gas cost on behalf of the group.
• Withdraw: An individual recipient can call this to claim their accrued, un-distributed share of funds, paying their own gas. This provides flexibility and avoids reliance on others to initiate distribution.

The percentage share of funds a recipient is entitled to, defined within a Split Contract. Allocations are expressed in basis points (bps), where 10,000 bps equals 100%. The sum of all allocations in a split must equal 10,000 bps.

• Example: A split with three recipients might have allocations of 3000 bps (30%), 5000 bps (50%), and 2000 bps (20%).
• Immutable: For many split implementations, these allocations are fixed at contract creation.