Self-Custody with Multi-Party Computation as a Safe signer

[dagacha]

Hello SAFE DAO community! I am David, a builder of ownable and decentralized off-chain systems using Autonolas. For relevant context, the Autonolas DAO is a Safe guardian and Autonolas tech makes heavy use of Safes.

Today I would like to hear from the community if there is an appetite for a hybrid-custody solution that I have in mind. The basic idea of this self-custody solution is to be able to have full control over your digital assets (i.e. your secret key) and retain some fallback to allow for account recovery (in case you lose access to your signing device/wallet).

This hybrid-custody design that I would like to hear feedback on aims to serve retail crypto users, who in general:

• Want to have control of their crypto assets
• Do not want to give ownership to their assets to a centralized exchange
• Want to have some protection from key loss
• One of the signers can be a hardware key but it is optional

Proposed Hybrid-Custody Solution Features

We consider a retail user who is one of the signers of a Safe multisig (e.g. a DAO treasury manager) that wants extra protection on their individual signing key. We build on top of a Threshold Signing Scheme (TSS) with a 2-out of-3 threshold, as depicted in the accompanying diagram (for a Safe multisg user U_2 with address addr_2).

As shown in the diagram, the retail user owns a main device and a secondary device (e.g. smartphone app and PC browser extension respectively), and uses each device to store a key share. The retail user is willing to use a third-party custody provider who would provide the fallback functionality in case of loss of one of the key shares.

The workflow is as follows:

1. The user opens an account at the custody provider
2. The user authorizes the custody provider, the users’ smartphone and the users’ laptop to create a signing key. This could control, for example, an Ethereum address to be used as part of a Safe multisig.
3. As a result of that, three private key shares are created (cf. diagram):

• S_C (stored at the custody provider)
• S_D (stored at the user’s smartphone)
• S_M (stored at the user’s PC browser)

4. The user can confirm/execute Safe multisig transactions if it has access to both personal devices or if it has access to one their personal devices and the custody provider
5. If the user loses one device, they can transfer the funds to a new ETH address and their individual address needs to be updated in the Safe multisig

What is beautiful about this is that all of the above, even if it requires coordination among several parties, can be achieved asynchronously, i.e.l the devices/custodian do not need to be online at the same time. More concretely, by leveraging Autonolas technology, an autonomous service:

• Coordinates the parties in the TSS key generation phase
• Makes the TSS key generation and signing phases asynchronous
• Coordinates the parties in the transaction approval process (although the user can sign w/o using the service by establishing a secure connection between their signing devices)

One could envision the above workflow being displayed and operated from the user’s side from a single website, with integration with the custodian (similar to the Safe Webapp).

Call to Action

I would love to hear from you if you find this interesting, or if you have any questions.

[MetaGuardian]

Biggest question from me is how you would get buy-in from a custodian to integrate this service i.e. what’s in it for the custodian who generates a key for this setup?

Traditionally, custodians like a walled-garden type model, where they lock you into a platform in return for all the value coming via implementation/subscription/volume fees. A key challenge for hybrid custody is getting custodians into new business models that make them migrate from typical platform lock-in.

Would like if there was section in here detailing the value that would flow between Safe <> Autonolas <> Custodian. And where fees would be incorporated for Autonolas and/or the custodian.

[dagacha]

Thanks @MetaGuardian for your constructive reply.

@MetaGuardian

Traditionally, custodians like a walled-garden type model, where they lock you into a platform in return for all the value coming via implementation/subscription/volume fees. A key challenge for hybrid custody is getting custodians into new business models that make them migrate from typical platform lock-in.

Good point. On the flipside we believe custodians will need to evolve if they want to serve DAOs. In this regard, we have seen some positive signals in the conversations we’ve had with custodians about this in the last few weeks.

@MetaGuardian

Would like if there was section in here detailing the value that would flow between Safe <> Autonolas <> Custodian. And where fees would be incorporated for Autonolas and/or the custodian.

Good question. A preliminary answer follows.

Let me first point out that the Autonolas decentralized off-chain service is to coordinate the different actors in the system (i.e. devices, custodian, users) and interact with the SAFE protocol. The Autonolas service is decentralized because in particular it is run by a set of (independent) operators. This service has an owner that is responsible for registering the service and paying the operators.

A potential value flow, based on a subscription model, is the following:

• Custodian gets paid by the user on a subscription basis.
• Autonolas service owner is paid by the Custodian on a bulk basis (e.g. based on number of registered users or daily transaction volume).
• Operators of the Autonolas service are paid by the Autonolas service owner.

A potential value flow, based on per transaction fees, is the following:

• Custodian gets paid by the user on a per transaction basis for transactions where the custodian is required.
• Autonolas service owner is paid by the user on a per transaction basis.
• Operators of the Autonolas service are paid by the Autonolas service owner.

In both cases SAFE DAO wins indirectly if smarter self-custody for SAFE brings more users/transactions to SAFE. There may be other possibilities of course.

[lukas]

As far as I understand the “hybrid” part is all off-chain, right? I.e. this would technically be a Safe that is controlled by a private key that is split into 3 key shares with a 2-oo-3 TSS threshold? In that case this is interesting concept for better private key security, but not necessarily something that is enabled by the Safe Protocol itself as there is no on-chain component to it. So sounds more similar to systems like Fireblocks or Coinbase MPC with the difference that the user has the majority of the shares, not the custodian?

[TJ_C]

You can use a Fireblocks MPC wallet as a Safe signer today. I just tested it out and it works flawlessly. At the end of the day, the MPC wallet is just viewed by the blockchain as an EOA. Here’s some notes I put together on it:

One of the key values of using an on-chain smart contract wallet multi-sig like Gnosis Safe is that approvals/signatures required can be reflected on-chain. This is helpful in scenarios where a Web3 project, such as a DAO, would like to give confidence to its users that they are engaging in security best practices, and that not a single person / owner has full control over the projects funds. OAs vs. Smart Contract Accounts](https://docs.gnosis-safe.io/introduction/the-programmable-account/eoas-vs.-contract-accounts)

It is a very simple process to integrate Fireblocks vaults as part of a Gnosis-Safe multi-sig where the flow would be: Fireblocks → Gnosis-Safe

Steps required:

1. Connect your Fireblocks vault to the Gnosis-Safe dapp via WalletConnect
2. Whitelist the Gnosis Safe proxy deployer smart contract address (current ones are listed here)
3. Identify the m of n addresses within your Fireblocks workspace (or elsewhere) that should be a part of this multi-sig
4. Deploy your Gnosis-Safe smart contract
5. Within Fireblocks, whitelist the address of your Gnosis-Safe as an “external” address NOTE: tagging it as a “contract” does not allow you to use the basic transfer capability within Fireblocks. Therefore, you would be unable to fund the gnosis-safe wallet unless specifying it as an “external” whitelisted address.

What does a gnosis-safe multi-sig transaction look like in Fireblocks?

1. EIP-712 personal message (RAW) to approve spending
2. First Signature (CONTRACT_CALL) to Gnosis-Safe smart contract
3. Any additional required multi-sig CONTRACT_CALL transactions identical as step #2 except initiated from their respective wallets. If both of these addresses are part of the same Fireblocks workspace, you will need to change your WalletConnect configuration to connect to vault #2 to provide approval initiation via the Gnosis-Safe dapp.

[dagacha]

Hi @lukas thanks for your reply.

@lukas

As far as I understand the “hybrid” part is all off-chain, right?

For the most part is indeed off-chain, but there are on-chain elements too. In particular Autonolas off-chain services are by default secured on-chain through an independent Safe multisig.

@lukas

I.e. this would technically be a Safe that is controlled by a private key that is split into 3 key shares with a 2-oo-3 TSS threshold?

Yes, for the individual signers of the multisig who sign up for this solution.

@lukas

In that case this is interesting concept for better private key security, but not necessarily something that is enabled by the Safe Protocol itself as there is no on-chain component to it. So sounds more similar to systems like Fireblocks or Coinbase MPC with the difference that the user has the majority of the shares, not the custodian?

This can effectively be thought of as a Coinbase-MPC like solution that is natively integrated with the SAFE protocol, where the user has the majority of the key shares. One could envision this solution being distributed as a Safe app and hence its primary users would be Safe users that are part of a Safe multisig but want their individual secret keys to be protected.

[dagacha]

Thanks, very useful info!

I would expect that in the Fireblocks MPC wallet case most of the shares reside with the custodian. Do you know if this the case?

With the solution that I had in mind you would obtain a similar experience to the one you describe, but that is decentralized and open source and the user never loses control of their assets.

[MetaGuardian]

I never knew this! Is there a public link to this article?

[TJ_C]

Correct, all of the key shares (3 in our MPC-CMP implementation) reside with the user as Fireblocks is a self-custodial wallet technology provider. User maintains full control over their private keys, Fireblocks is simply creating the technical infrastructure for the MPC to execute on in a distributed and trustless manner.

This is the original research paper: UC Non-Interactive, Proactive, Threshold ECDSA with Identifiable Aborts

And this is the implementation reference for the above research paper: Fireblocks Multi-Party (EC)DSA, ver 1.2.pdf - Google Drive

And this is a high level description of the MPC-CMP algorithim: Introducing MPC-CMP - 8X Faster MPC Wallet Signing - Fireblocks

[dagacha]

Thanks for sharing Fireblocks’ MPC wallet solution with that much level of detail

Is the code available open source by any chance?

[TJ_C]

Not currently, only the research and reference implementation I provided above are public today.

[ebarbieri]

Hi TJ_C,
Thanks for this, exactly what I was looking for. I’m currently setting up my FB MPC as per these steps. I had the Safe deployed before I even connected with the FB Vault (both in Base Sepolia).

1. I’ve connected the Vault to the FB Vault. Currently displaying within FB Web3 access.
2. Where does this whitelisting take place ?
3. I created a wallet for the asset ETH_TEST5 and added this wallet as a Signer in the Safe - is this correct ?
4. As mentioned before the Safe was deployed before I connected to FB
5. I’ve whitested the Safe address as external.

Now I’m prompting a transfer from the Safe (transferring ETH Base Sepolia as test). The transaction signature pops up in for one of the wallet signers (currently 1:2 rule), my CB wallet connected to the app.safe.global - But no signature is prompting in the FB Vault (which is what I want to ultimately test).

What am I missing ? Many thanks in advance !