Alternative options

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.