Protocol security

Here is an overview of what steps we've taken to ensure funds flowing through the system are safe and secure.

1. Audits: the contracts have been audited by several different groups. Splits v1 was audited by Macro in February 2022. You can read their report here. Splits v1 has safely distributed over $40M since launch in 2022. In April 2023, Swapper, Oracle, Diversifier, and Pass-Through-Wallet went through a Sherlock security review with obront.eth as the Lead Watson. You can read that report here. Neither audit discovered any high vulnerabilities, and all vulnerabilities discovered were addresses prior to deployment.
2. Non-custodial, non-upgradable, and open source: all the contracts within the Splits ecosystem are non-custodial, meaning no entity has any privileged access over the system, as well as non-upgradable, meaning the contracts can never be altered. The contracts, as they are deployed, will operate for as long as the underlying network (e.g., blockchain) operates. The protocol is open source and decentralized, with no owner, upgradability, or special privileges.
3. Pull-based model: all the contracts within the Splits ecosystem follow a pull-based model, meaning that a transaction must be submitted in order to withdraw (or pull) funds out of a contract. The pull-based model is widely considered best practice since it is both more safe and more secure than a push-based model. You can read more about pull- vs. push-based models here and here.
4. Minimal, modular tools: we strongly believe in the Unix philosophy, which posits that minimal, modular, and reusable tools are better suited to solving complex problems than a monolithic contract or system. This approach reduces attack surface area while increasing flexibility, adaptability, and ease of third-party integrations.
5. Permissionless transactions: unless there's a strong reason for a transaction to only be callable by a specific account (e.g., editing a Split), all transactions in the system are permissionless and therefore able to be executed by any account. For example, distributing and withdrawing balances are both permissionless because the outcome of performing that function is not dependent on the caller—in both cases, the outcome is known regardless of who initiates the call.

We are continually assessing security best practices. Please feel free to reach out if you have any ideas or suggestions.