Before starting this project, we surveyed what Mirror, OpenZeppelin, Foundation and others had built and focused on optimizations around a few key areas: composability, gas efficiency & fairness, and onchain-ness. Below we highlight some key differences between 0xSplits and other implementations of splitter contracts.
- 0xSplits can receive from solidity's
callwith capped gas
- 0xSplits handles ERC20s & recursive Splits
- 0xSplits can withdraw to contracts that use more than 30k gas in
- 0xSplits can withdraw to contracts/accounts that don't have direct access to
the private keys using
- 0xSplits can be mutable and modified by EOAs or other SCs
Gas-efficiency & fairness
- 0xSplits is significantly more gas efficient for users in multiple Splits, since withdrawals exist on the user/account level instead of the Split level (i.e. a user does not need to withdraw for each Split they receive from)
- 0xSplits generates significantly less dust (i.e. funds trapped because of gas costs to distribute) since distribution costs come out of the Split's balance
- 0xSplits are progressive or flat depending on the Distributor Fee (vs regressive for other splitters)
- All 0xSplits data lives onchain with no infrastructure dependencies or potential for censorship
- 0xSplits contracts are non-upgradable, meaning both the protocol and each Split is unstoppable and will continue to operate for as long as the network does
There are a number of constraints with our current design that are worth highlighting.
Very large groups: Splits are designed for groups of people less than ~500 (see gas estimates). 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.
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.