---
robots: noindex, nofollow
---

# SmartCustody for Ethereum
###### tags: `article / in process`

This proposal offers a methodology for adopting aspects of Blockchain Commons' Smart Custody to improve the security of Ethereum wallets.

## Problem Statement

Ethereum accounts are typically controlled by a single private key. They come in two types.

EOAs (Externally Owned Accounts) use traditional key pairs: the account is defined by an address derived from a single public key, and the related private key gives full access to the account. EOAs form the majority of Ethereum accounts.

Contract accounts have public addresses that are indistinguishable from those of EOAs, but instead of being controlled by a key, they are controlled by a smart contract. A contract account may or may not have an associated private key used to control the contract, but if it does, it is usually a single private key (the gnosis multiple signature smart contract being an obvious exception).

The problem with this setup is that having a single private key to control everything means that you probably have a Single Point of Failure (unless you take individual actions to improve the resilience of your key) and you definitely have a Single Point of Compromise: if someone steals your key, they have access to everything.

Even beyond these technological limitations, there isn't much attention paid to the _idea_ of Smart Custody on the Ethereum network. Your single Ethereum account will typically contain your Ethereum assets and your token assets (such as NFTs), your single sign-on authentication for services, and may even be what you use to control Contract Accounts!

One theft, and you lose everything.

Meanwhile, contract accounts can create problems all their own, since their authentication is usually algorithmic (e.g., looking up a key on a list) rather than cryptographic (e.g. an ECDH or Schorr operation). This has proven a prime vector for attacks, resulting in huge losses.

> [@ChristopherA]These are a class of problems sometimes called ["Ambient Authority"](https://en.wikipedia.org/wiki/Ambient_authority) and there exist solutions to address them, such as limiting scope of keys (DIDs), single use keys (Bitcoin), etc. However, these solutions are not part of the current Ethereum wallet architecture.

Overall, Ethereum needs better models for security and for key resilience. This proposal suggests a starting place.

> TBD, integrate any other adversaries of note from #SC for NFTs https://hackmd.io/CcGwhpVVTXi4nX_MzGZtnQ

## Basic Proposal

The first step for improving the resilience of Ethereum keys is to replicate a successful methodology from Bitcoin: key partition. Where Ethereum uses an account based on the same address for _everything_, Bitcoin instead uses different addresses, and thus different keys, for each individual transaction.

On Ethereum, we can do this by defining a variety of _proof purposes_, each of which is a different use of the network, and each of which will then be managed by a different key pair. Proof purposes for Ethereum keys that will be partitioned include:

1. Single Sign-on
2. Ethereum Assets
3. Other Assets
4. Smart Contract Control

Currently, it is possible to do this manually: a user aware of the resilience and security issues implicit in Ethereum could generate a variety of key pairs by hand and diligently maintain the discipline to use each key only for its intended purpose. But, this approach will not be practical for most users. What's needed to make key partitioning work for Ethereum is wallet support.

### Wallet Design

The solution simply requires the development of xpub-based extended wallets for Ethereum, where addresses, and thus accounts, are defined by xpubs (and the related xprvs), each of which includes not just an address, but also a chain code and a seed fingerprint, which together define how the address is descended from a foundational seed. Ethereum addresses are actually already created in this way, the chain code is just currently thrown out, and only a single derivation path is used.

New xpub-based Ethereum wallets would go a step further by descending a level deeper in the hierarchy defined by the Ethereum seed. This would open up a whole tree of possible addresses, each used for a different proof purpose.

An ideal wallet design would follow Smart Custody procedures by not even maintaining the foundational seed in the wallet, but instead storing it in an offline or closely-held device and revealing new xpubs (and xprvs) to the wallet through airgapped technologies such as QR codes of Blockchain Commons' Uniform Resources. This would be what we define as a _cool_ wallet, and could be additionally protected by Blockchain Commons Smart Custody designs such as SSKR, which supports seed sharding.

### Wallet Connect Design

One of the best tools that we have to advance Ethereum's account design is [WalletConnect](https://walletconnect.com/). Wallet Connect has already begun improving Ethereum resilience by partitioning activities, supporting signing that is separate from the apps that are assembling the transactions.

We hope to leverage Wallet Connect 2 to support xpub-based accounts and perhaps even to help in the development of Wallet Connect 3, to provide wider interoperability for those accounts.

### Development Path

The following development path is currently planned for initial deployment of xpub-based wallets on Ethereum:

1. Sketch out proof-purpose structure.
2. Implement an extended wallet for NFTs using Polygon as a Testbed.
* Blockchain Commons incorporates Wallet Connect 2 into Seed Tool.
* Blockchain Commons creates prototypes that use Wallet Connect 2 with xpub-based addresses.
* Bitmark implements multi-account lookup display tool for xpub-based addresses.
3. Test for both ERC 721 and 1155.
4. If initial tests succeed, continue to extend development to other proof purposes and to the actual Ethereum network.
5. Extend interoperability of new account design with Wallet Connect 3.

## Potential Challenges

There are a number of potential challenges for this new design, all of which would need to be resolved as an xpub-based wallet was rolled out.

1. ***Backward compatibility would need to be maintained.*** Moving to an xpub-based wallet is a major architectural change, so careful work will be needed to ensure compatibility with existing Ethereum uses. This will likely require saving the 0th child of any new hierarchical level for auth purposes and might include other backward-looking mechanics.
2. ***Contracts would need to be reviewed for compatibility.*** The biggest challenge will be ensuring that popular legacy smart contracts such as ERC 721 and 1155 work with this new hierarchical design, since defining different proof purposes for NFTs will be one of the immediate wins. In particular, we need to investigate if payment for moving an NFT can come from a different address than where it's being moved to; if not, we may end up needing to move things twice, which may be cost-prohibitive given current gas prices on Ethereum. (Overall, this could be a deal breaker for a fully partitioned design.)
3. ***Chain code uses would need to be reviewed.*** Chain codes used in [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) have to be used carefully to avoid compromise of data, which is the reason for the existence of hardened paths. Overall, security reviews would be required to ensure that nothing untoward is being exposed by a design for extended Ethereum addresses and that hardened paths are being used appropriately.
4. ***Key-hierarchy methods would need to be reviewed.*** Overall, the methodology of chain codes and derivation as defined in [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) (with [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) and [SLIP44](https://github.com/satoshilabs/slips/blob/master/slip-0044.md)) needs to be carefully considered. It has the advantage of being well-understood on Bitcoin and allowing the use of well-tested existing libraries such as [libwally](https://github.com/ElementsProject/libwally-core); it also already has some limited usage on Ethereum. However, even the designer of BIP32 has expressed some regrets in how it's defined. If we're forced to move away from full legacy compatability, that might be an opportunity to consider new styles of key generation, the simplest of which is PBKDF, but which might also include some simple homomorphic approaches.
5. **Other chain compatibility needs to be considered.** The BIP32 methodology does not work for 25519 curve–based wallets such as Cosmos and Tezos, because only a limited number of BIP32-based private keys (around 1 in 8) can generate valid public keys on that curve. In addition, supporting "hardened" vs "non-hardened" derivations, as defined in BIP-32, does not seem to be possible on 25519 without hacks. If compatibility is required for other chains, this might be another reason to reconsider existing key-hierarchy methods.

## Conclusion

Partitioned wallets can provide a notable increase in the resilience and security of Ethereum wallets. There are challenges to making this transition, mainly revolving around ensuring compatibilities with existing wallets and contracts, but also in verifying that we are producing the best new specification possible.

### Future Development

Ethereum is still in a period of rapid advancement. We hope to use future advances to further develop this methodology, particularly as cryptography is better integrated into smart contracts, supporting more resilient contract accounts and allowing for the creation of SSKR-focused smart contracts for holding accounts of this sort.