Custody: BFT Policy Checking + Threshold Signatures

"Not Your Keys, Not Your Coins" - that’s what self-custody advocates for. But how does this change when "coins" are worth hundreds of millions in USD and "your" refers to a company or team rather than a single person?

In this article we'll describe some of the issues we’ve encountered through years of investing and the custody solution we're currently working on called Silo.

Silo protects assets and can transfer them across Bitcoin, Ethereum, Solana, and more. Before signing any transaction, it checks policies in a byzantine fault-tolerant way (BFT), and it uses threshold signatures to keep private keys split across independent servers.

Common Issues with Custody

Throughout the years, we’ve worked with a variety of custody solutions, and if you’re looking for the one to best fit your needs, check our previous article surveying various options. Here, we want to highlight the problems that custody solutions are trying to solve.

Problem 1. Storing keys.

Without a doubt, the major issue with custody is where and how to store private keys. Cold storage is highly secure but slow to use. Hot wallets are good but only when the amount of money is reasonable. We’re focused on what we call warm storage, i.e. private keys with large amounts of money to be used promptly. Or, said in another way, we want to apply modern algorithms and software to get the best of the two worlds: the flexibility to move funds with agility like in hot wallets and the ability to (feel confident to) store large amount of money like in cold ones.

Common solutions include threshold signatures and multi-signature schemes that distribute trust across machines, people, or even institutions. Specialized, secure hardware devices alone could also be a valuable option. However, as teams grow, keys may need to be reshuffled or backed up/duplicated on multiple devices.

Based on our experience, we think that a custody solution should clearly separate people from machines while providing both with strong authentication mechanisms. We also need the ability to sign transactions without human interaction. Therefore, we chose threshold cryptography among machines only. (That being said, we’re well aware that in other use cases humans are required, so a solution should be flexible enough to account for both the case where threshold is used among machines only and/or shares are split among machines and humans.)

Problem 2. Checking destination addresses.

Addresses on the blockchain are problematic because they are completely meaningless and error prone, very much like IP addresses. For websites, as a solution people use DNS names instead of IP addresses, but on the blockchain, we’re still stuck with hex and base58 strings.

Therefore, a custody solution has to handle a “contact list” of valid and approved addresses, much like a banking application. Since this solution is straightforward, contact lists are becoming popular in consumer wallets.

What’s less straightforward are the policies around contact lists. Adding and updating entries should require multiple people in the team to check and validate the new addresses to make sure that the error of one person doesn’t result in unauthorized transactions.

We’ve seen this multiple times, and not just for recipient addresses. For example, the list of valid token assets (e.g., ERC20) needs constant updating, and in analogy to contact lists, we want multiple people in the team to cross-check the address of a new token.

Problem 3. Supporting multiple blockchains.

We trade across many blockchains (and we’re also very active in cross-chain technology!), so it shouldn’t come as a surprise that one of the major issues we’ve encountered has been a wide spectrum of blockchain support. The issue isn’t anyone’s fault. Since we always want to be among the first to trade on a new chain, it’s unlikely that the chain is already supported by products out there.

Thankfully, we’re seeing an increasing number of EVM-compatible chains, or chains based on Cosmos. Hopefully, this problem will get better and better with time.

In our solution, deploying a new EVM-compatible chain only requires configuration changes, similar to how easy is to add a new chain to Metamask.

Our Custody Solution: Silo

Silo is a custody solution that protects and transfers digital assets. It’s built upon threshold signatures and byzantine fault-tolerant policy checking. Think: Metamask on steroids.

In Metamask, a private key is stored on your laptop/phone or on your hardware wallet. In Silo, private keys are split across multiple servers. By using threshold signatures, Silo can sign transactions without ever revealing the full private key on any of the servers.

While Metamask lets you sign arbitrary transactions, which is good for ease-of-use, Silo requires you to explicitly allow any transaction you ever want to make. Before signing a transaction, Silo checks it against its policies. To be more precise, there isn't just one server checking policy but rather a coalition of servers that independently run all checks and reach an agreement on whether the transaction is allowed or not. This is called byzantine fault-tolerant policy checking.

Silo is a custody solution for institutions, designed for security. Before moving forward, it's probably worth clarifying what Silo is not.

Silo is not a trading system. In fact, Silo can transfer assets on multiple blockchains, but it's not designed to achieve high throughput as might be needed for trading. Silo just guarantees that if a transfer complies with policies, it will eventually make it into the blockchain (with this said, Silo is still pretty fast—we send transactions in seconds, just not in milliseconds.)

Silo is not a consumer wallet. Silo is designed to enforce policies and block anything that wasn't previously authorized. It's great for security and for repeated operations like transfers from/to the same places, e.g. our trading accounts, but it’s not optimal for consumers that may want to perform a variety of different transactions.

Why Silo? Open Source + Private Blockchain

The use of threshold signatures is not new to Silo. In fact it's implemented by many “MPC-as-a-Service” providers. What is new with Silo is that we designed it to be open source from the very beginning to give a more complete solution to the custody problem.

In other custody solutions, private keys are typically split "half with you, half on the cloud", where the cloud is the service provider. To sign a transaction, you have to interact with the provider (whether via an app or an api), and in principle the provider can't sign transactions without you. This approach has advantages, like helping simplify compliance.

But this introduces a dependency on the provider that we don't want. Brought to an extreme, we circle back to the original motto "not your keys, not your coins". We really want our keys to be ours and only ours, no exceptions. But how can we even trust the teams building and running Silo internally?

Note that this is not an idealistic discussion of "you can never trust anyone." This is really rooted in the difference between blockchain and other worlds. Think of it like granting a provider full access to your bank account. If anything goes bad, even in the worst case scenario in which the provider drains all your money, you can still appeal to your bank and perhaps recover the funds. Not on the blockchain. A private key, once known, can be used anytime and anywhere. Funds can be moved and locked forever out of your control.

Open source provides half of the solution, and blockchain provides the second half. Silo will be built in the open and, hopefully, validated by the community as a whole. Silo itself is a private blockchain, designed to be run by independent teams inside a company. Therefore no individual or team has direct access to any private key, nor should any given team or individual be able to sign an unauthorized transaction by themselves.

While this goal is still aspirational, we're making good progress. We have a working version of Silo with plans to open source it in the next few months. Internally, Silo runs on 4 validators with 3 required for consensus, so it can tolerate a server that is down or misbehaving. It holds our private keys and allows the transfer of assets on multiple blockchains including Bitcoin, other UTXO, Ethereum, many EVMs, Solana, and Terra. Silo as an internal blockchain is built with the Cosmos SDK. We will share more details in future posts.

In summary, we have worked with a variety of custody solutions and decided to build our own solution - Silo - and it will soon be open sourced.

Silo protects assets and can transfer them across Bitcoin, Ethereum, Solana, and more. Before signing any transaction, it checks policies in a byzantine fault-tolerant way, and it uses threshold signatures to keep private keys split across independent servers.

If you’re interested in self custody or are actively looking for a solution, reach out to us: we’re always happy to discuss the topic (@_conorpp, @0x0ece, @nsuri_, @nickraystalder, @hoos97). If you want to talk about careers at Jump, we’d love to hear from you.