We recognize that the contracts within the Splits ecosystem may not always be the right mechanism for your specific needs. Here are some of the tradeoffs made during development and a few other options that may be better suited for you.

Before starting this project, we surveyed what Mirror, OpenZeppelin, Foundation and others had built, and we focused on optimizations around a few key areas: composability, gas efficiency & fairness, and onchain-ness. Below we highlight some key differences between Splits and other splitter contracts.

Advantages#

Composability#

• Splits can receive from Solidity's send and transfer, or from call with capped gas
• Splits handles ERC20s & recursive Splits
• Splits can withdraw to contracts that use more than 30k gas in receive()
• Splits can withdraw to contracts/accounts that don't have direct access to the private keys
• Splits can be mutable and modified by other accounts, including smart contracts with custom logic

Gas-efficiency & fairness#

• Splits is significantly more gas efficient for users in multiple Splits, since withdrawals exist on the account level instead of the Split level (i.e., a person does not withdraw for each Split they receive from)
• Splits generates significantly less dust (funds trapped because of high gas costs) since distribution costs come out of the Split's balance, making distribution costs borne by ownership
• Splits costs are progressive or flat depending on the distributor fee (vs regressive for other splitters)

Onchain-ness#

• All Splits data live onchain with no infrastructure dependencies or potential for censorship
• Splits contracts are non-upgradable, meaning both the protocol and each Split is unstoppable and will continue to operate for as long as the network (chain) does

Constraints#

There are a number of constraints with the v1 design of Splits that are worth highlighting.

• Very large groups: Splits are designed for groups of people less than ~500. While you can stack Splits multiple layers deep (i.e. Splits that point to other Splits), you will need significant funds flowing through the top-level Split to justify the total gas cost of distribution. The larger the group, the more you should consider a rebasing token or DAO.
• Single-use: Splits are most gas-efficient when reused multiple times. If the payout is expected to arrive in a single lump sum, something like disperse.app via a multisig or trusted party may be more efficient from a gas perspective.
• Rebasing tokens: While held in a Split or user balance, rebasing tokens will cause accounting issues within your Splits.
• Fee-on-transfer: ERC20s flowing through Splits that have a "fee-on-transfer" will cause accounting problems within your Splits.