--- title: "Splits v2 is live" date: "2024-05-07" canonical: "https://splits.org/changelog/v2-launch/" --- # Splits v2 is live We’re delighted to announce Splits v2, the second generation of our flagship smart contract for routing internet-native payments. In the [two years](https://splits.org/blog/splits-2-year/) since Splits went live on Ethereum mainnet, we’ve learned so much from our users and their feedback. The ecosystem has evolved into a vibrant [multichain](https://splits.org/blog/multichain/) multiscape, and Splits is evolving too. Splits v2, audited by [Zach Obront](https://github.com/zobront/audits), is more flexible and robust than its predecessor. We redesigned our architecture from the ground up, decoupling the splitter logic from token storage and removing a number of legacy limitations. Devs will be able to customize the experience they offer to end users based on specific business needs, instead of the “one size fits all” mindset of Splits v1. Today we’re introducing the results of our redesign: `SplitsWarehouse`, `PullSplit`, and `PushSplit`. - `SplitsWarehouse` is a generic token wrapper built on [ERC6909](https://eips.ethereum.org/EIPS/eip-6909) that can hold any native or ERC20 token on behalf of any recipient for any pull-flow payment. Think wETH but it wraps every token and is deployed to the same address on every chain. The contract is immutable and non-upgradeable. - `PullSplit` is the next iteration of our existing splitters, built on top of the new `SplitsWarehouse`. As with v1, distributions follow the pull-flow with the new `SplitsWarehouse` replacing `SplitMain` as the place where funds are held on behalf of recipients. As always, pull-flow payments offer a robust, consistent, and efficient onchain experience, particularly for users receiving from multiple splits. - `PushSplit` is a separate splitter implementation that pushes funds to end-recipients on distribution. It uses a generous gas-limit and falls back to depositing funds into `SplitWarehouse` for failed transfers, mitigating the costs adversarial recipients can impose on their peers. Our new modular architecture has two big benefits: - `SplitsWarehouse` can be used by any third-party developers to make easy, secure, and efficient pull-flow payments without having to build out their own accounting, notification, and withdrawal UI. - We can offer and iterate on multiple splitter implementations in parallel to target different use-cases with different UX trade-offs for integrating developers. The new contracts include some additional upgrades… **Warehouse:** - Pull-flow distributions and recipient holdings are recognized by [6909](https://eips.ethereum.org/EIPS/eip-6909)\-compliant wallets. - Third-party withdrawals may be paused or incentivized. - Recipients may program revenue with additional logic via approvals and operators. **Splitters:** - Mutable Split owners now have full smart wallet capabilities, able to execute transactions and sign messages. (No change to the security model.) - Mutable Splits are deterministically deployed via `CREATE2`, allowing for counterfactuals and better cross-chain UX. - Recipient restrictions have been relaxed for better integrating DevEx: 1) You can deploy multiple immutable Splits with the same recipients. 2) Splits may have one or even zero recipients. 3) Recipient allocations may sum to arbitrary totals. Overall, the new setup addresses a number of problems that arose over the past two years — from end users being confused by balance distribution, to the lack of ability to incentivize withdraws, and various other quirks and edge cases that frustrated the people who ran into them. In the past it was hard to respond to feedback quickly, because to fix anything we had to deploy an entirely new system. Well, here’s that new system! Now you can design the payment flow that fits your precise use-case, unencumbered by defaults that don’t suit your situation. ## Kick the tires We hope you’re intrigued. As always, [split.new](https://split.new/) is here for your convenience. Check out the Splits [app](https://app.splits.org/), the [docs](https://docs.splits.org/), our [SDK](https://docs.splits.org/sdk), or dive straight into the [contracts repo](https://github.com/0xSplits/splits-contracts-monorepo/blob/main/packages/splits-v2/README.md). If you’re a developer building something that relies on any kind of pull-flow, reach out via [Farcaster](https://warpcast.com/~/channel/splits) or [Discord](https://chat.splits.org/). We’d love to chat. Lastly, we’re also working on a new team-based smart account system, which will make it easy for onchain teams to manage their earnings across all chains at once. The MVP will use multisig wallets and passkeys to allow teams to operate safely cross chain without worrying about bridging funds between networks. Interested? [Let’s talk](https://warpcast.com/abram/0x0349e2cb)! Or [drop your info in this form](https://forms.gle/XshLbsFn23zKXrKn9). ## Commemorative mint As you may have gathered, we love the energy on Farcaster. We decided to celebrate v2 by experimenting with a community collaboration. Using [Bountycaster](https://www.bountycaster.xyz/), we found graphic designer Rih, AKA [@lambchop](https://warpcast.com/lambchop). She explored how to visually communicate the function of Splits — one income stream becoming multiple so that builders and creators can easily share the fruits of their labor. Riham created an "oddly satisfying" animation that uses our logo to illustrate oscillating oneness and twoness — which is appropriate as we debut the second generation of the Splits smart contract suite. Naturally we used [Splits partner Zora](https://splits.org/blog/zora-integration/) to create the commemorative mint. [Pick up your edition here](https://zora.co/collect/base:0xf5a2df6525c1a1e0c9a909379a4c9783b852d573/1?referrer=0x1340787efF0633E84a2A813c374421Bf04519163): ![](https://storage.ghost.io/c/ec/10/ec1004a4-54fe-4879-9efd-9a3fe755a821/content/images/2024/05/v2.gif)