More ETH, more problems (but not for long)

Recently we discussed the hassle of securing team funds onchain across a variety of multisig accounts and a variety of different networks. Here are some of the concrete problems that Splits has encountered.

How much money do we actually have onchain? This fundamental question is a surprisingly big issue. The answer is scattered across two dozen different accounts, so we have to assemble the full picture piece by piece, like a torn-up treasure map. We love the flexibility and security of our hand-rolled multisig system, but keeping track of both individual and aggregate balances is a pain without a unified dashboard that displays all onchain funds in one place.

Footguns abound when your setup is retrofitted for multichain (rather than designed to be multichain-first). Unlike a real gun, you don't realize that you're handling a dangerous weapon until after the bullet enters your foot.

For example, when we received Optimism Retroactive Public Goods Funding, we accidentally maneuvered into a corner:

• We knew it was possible to deploy our multisig on Optimism to the same address that it had on Ethereum. We assumed that sending OP to that address would ✨just work✨ (in a bout of misplaced optimism, ironically).
• Oops, the accompanying UI doesn't accommodate this scenario. It gave us a scary warning and won't execute transactions. Okay, so, how do we extract the funds? We're devs, this shouldn't be too hard, right?
• Oh no, the CLI tool doesn't work with hardware wallets 🫠 (at the time, anyway). Fortunately one of our initial signers was a hot wallet capable of executing transactions, and that was enough.
• Having a large sum in a low-security account felt uncomfy, so we used the signer that did work to upgrade to 2-of-4 multisig.
• Now the next time we use that account, we'll need two signers… which means simultaneously loading both private keys onto the same machine and into the same program? Security experts avert your eyes.

In a less dramatic but more frequent dilemma, we found ourselves mixing personal and business signers. Also uncomfy, for both accounting and legal reasons. But doing it the right way was a pain logistically. A specific headache: future deployments on other chains at an address that was initiated with personal signers. If you create an account with personal owners 0xA, 0xB and then update it to business signers 0xC, 0xD, when you go to deploy on a new chain at that address, it gets initialized to owners 0xA, 0xB (the personal signers).

Each signer needs ETH for gas. On every chain. Provisioning those funds isn't the world’s biggest inconvenience, but it adds to the hassle stack.

We could go on, but you get the idea. The pain points above stood out the most.

Out with 1337, in with 4337#

Enough complaining, what's the solution? Smart accounts, as we keep telling you — but how? ERC 4337, a standard for Ethereum account abstraction (AKA smart accounts), provides a good start.

In a podcast interview, coauthor Kristof Gazso of Pimlico explained the impetus for 4337: "How can we relieve Ethereum of this very hard-coded way that defines accounts? How can we make them more flexible, modular, interoperable, powerful?" In our view, this initiative succeeded.

4337 lays the groundwork for a new product that can tick all the boxes:

• Multichain ✔️
• Multisig ✔️
• Passkeys ✔️ (from Chrome to iOS/macOS to Yubikeys — more on this in the future)
• Paymasters for gas fees ✔️
• Keystore rollups ✔️

Because ERC 4337 is a standard, increasingly embraced by the whole industry, we don't have to roll our own or reinvent the wheel. Some level of interoperability / account portability is built in. So Splits can just focus on building killer UX for onchain teams 😌

Alchemy has a great series called "You Could Have Invented Account Abstraction" dissecting 4337, if you want to delve into the guts of the standard.

As ZeroDev CEO Derek Chiang wrote, any account abstraction implementation "would naturally evolve towards something like 4337 if they need to solve the problem that 4337 sets out to solve, which is to build a decentralized, censorship-resistant mempool for smart account transactions."

The standard is a product of its constraints, including an insistence on user sovereignty, which was a prerequisite for Splits to participate.

4337 may not be perfect, and it's still being battle-tested. Nonetheless, it's exciting to see the community rally around solving the problems that slow down onchain teams. Splits is eager help advance the UX standards for the internet of value alongside builders we admire.