Why

We have multiple team members that need to execute onchain transactions on behalf of the company. This includes things like deploying contracts, creating and collecting NFTs, transferring and bridging assets, testing the app, and more. We need to do this in a way that doesn’t put funds at risk, yet still gives team members autonomy.

Our first attempt at this system cobbled together existing tools; however, it’s proving problematic as we grow—it’s difficult to use day-to-day, it doesn’t work well across multiple chains, and it requires regular upkeep (e.g., ensuring specific wallets have enough funds, moving excess funds from Ops to Treasury, etc), all of which detract from our day-to-day focus on Things that Matter.

As we’ve rethought our team’s wallet strategy, we’ve realized we’re not the only team facing this issue. Every team with revenue and expenses across multiple chains faces this issue. That number is growing by the day, particularly within the Splits and Farcaster communities, as the crypto economy continues to develop and more and more L2s come online. Finally, recent advances in the UX for public-private key pairs (passkeys) and new Ethereum improvements (4337 + 4844 + 7212) have the potential to significantly enhance the overall onchain experience without compromising on sovereignty and security.

What

Smart contracts for an easy to use system for teams to create, use, and manage wallets across chains.

How

Our contracts will allow our users to seamlessly and securely operate a tiered system of multichain multisigs. This means minimizing the user friction to synchronize state (e.g. owner, implementation, signers) across networks without degrading the underlying security model. We will lean into passkeys for everyday UX while securing the overall system with EOAs (ideally hardware wallets) to mitigate passkey limitations on sovereignty (e.g. reliance on domain access). Finally, a team paymaster will allow any account to operate on any chain without managing gas.

Unfortunately, no existing 4337 smart accounts satisfy these needs, so we must design our own.

User requirements

Users can:

• Operate with consistent addresses across networks
  • Juggling different addresses on different chains is operationally painful and error prone
• Hold funds in multiple accounts with different security and accessibility considerations
  • Generally speaking, we imagine a “Treasury” (m-of-n multisig) with n “Operating Accounts” (1-of-n multisigs), each with an accompanying name, purpose, accounting rules, and set of signers. “Who has what signing privileges over which funds?” Automations between the Treasury and Operating Accounts allow target balances and diversification strategies to be maintained without manual intervention, providing easy accessibility for day-to-day operations while limiting downside from malicious interactions.
• Access funds for day-to-day operations via passkeys (secp256r1)
  • We believe passkeys offer 10x better signing UX than EOAs (chrome passkey > mm hot wallet; yubikey > ledger)
• Backstop the entire system with a single set of EOA (secp256k1) signers
  • While passkeys offer great day-to-day UX, their domain lock-in makes them fragile and unsuitable for root trust considerations. In the ideal case, this is rarely or perhaps even never used. “Break glass in case of emergency.”
• Update an account’s state across all existing (and future) networks with one valid signature. Implementation updates should be structured to prevent permanent account loss from rogue signers on low threshold accounts.
  • Manually synchronizing state across chains is operationally painful and error prone
  • Losing the funds in a 1-of-n multisig due to a rogue actor is unfortunate but acceptable; permanent loss of the address is not

System architecture

We believe the above structure allows us to optimally balance the usability of passkeys with the portability of EOAs. Generally speaking, the passkey-based Treasury and Operating Accounts should be able to handle all day-to-day operations. For high-risk operations and in case of emergency, a set of EOAs (ideally hardware wallets) retains custody.