We recognize that the contracts within the 0xSplits ecosystem may not always be the right mechanism for your specific needs. This section discusses the tradeoffs made during development and various other options that may be better suited for you.

Before starting this project, we surveyed what Mirror (opens in a new tab), OpenZeppelin (opens in a new tab), Foundation (opens in a new tab) 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 splitter contracts.



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

Gas-efficiency & fairness

  • 0xSplits 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)
  • 0xSplits 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
  • 0xSplits costs 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 the v1 design 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 (opens in a new tab) 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.