Institutional Custody in the Crypto World
May 22, 2018
After a decade of research and development, the cryptocurrency world has reached a tipping point where it has to prove its legitimacy to the “real world,” and go from a niche/weird ideology to become the backbone of our society. Despite its cryptopunk and Libertarian-inspired roots, cryptocurrencies need the nod from large financial institutions in order to truly achieve mass adoption. There are still two main problems that plague the industry:
- More advanced financial instruments to faciliate efficient trading
Traditional Financial Custody
Before understanding custody in Crypto, it’s important to understand how custody is traditionally done.
Custodians existed for almost as long as the concept of money itself. When new money is minted, naturally somebody would have to take possession and safeguard the fortune. However, the concept of custody in finance may not be as straightforward as it seems. For example, some of the biggest custodian banks in the world are NOT the biggest holding companies of cosolidated assets (i.e. BNY Mellon, State Street). Contrary to popular belief, custodian banks actually do not hold the underlyings. The obvious reasoning is they want to expose themselves to minimum amount of risk. In fact, custodian banks function more as a record-keeping entity than a safe-keeping one. To understand this distinction, it is important to talk about the functions of a custodian bank and its limited role in our traditional financial system.
Typically, custodian banks act purely as intermediaries. They access the underlying FMUs, or “financial market utilities,” through a direct or indirect memebership structure. They can be seen as the user interface layer on top of the actual holding entities, executing instructions from their clients. Custodian banks usually offer the following services.
- Transfer agent/record keeper: record principles and security holdings of clients, record credit/debit to client’s accounts (not the actual execution)
- Admin/asset services: taxes, corporate actions/proxy votes, reporting of total valuations, recent transactions...
- Banking services: advance short-term shortfall of funds (usually intraday/overnight credit extensions), sometimes sweep arrangement and short-term investment products
- Collateral processing: repurchase, reverse repurchase transactions, lending/borrowing, derivative transactions, verify credit exposure.
Balance sheet & Risk Profile
Underlyings are never reflected on a custodian bank’s balance sheet, thus alleviates it from taking on principle risk in the form of credit risk. In other words, the balance sheet is liability-driven rather than asset-driven. The only things typically reflected on the balance sheet are cash deposits from clients.
Risk Profiles of a custodian bank are relatively simple. It largely depends on if they engage in short term credit business. Nevertheless, generally the risks include:
- Operational risk: erroneous reporting, internal threats, legal/compliance/fiduciary risk
- Credit/market/liquidity risk: if exposure to investment products like credit extensions, there will always be counterparty risk. Custodian banks typically mitigate such risks by collateralizing with high-quality liquid assets (gov assets, foreign sovereign debt etc)
Custodian banks deal exclusively with central counterparties. These include national banks, settlement systems, and securities depositories (CSDs/ICSDs).
CSDs and ICSDs are the actual entities that hold physical security certificates. They also hold a list of owners (official registrar of shares) on behalf of issuers. In addition, they maintain a record for all ownership changes of the underlyings. CSDs operate with a membership model. Since the barrier of entry (regulatory, mostly) is high, the industry of custodian banks remains necessary.
With cryptocurrencies, almost all functions of a traditional custodian bank become obsolete, or can be replaced by an app (i.e. nice website showing underlying assets of a crypto fund). One of the promises of cryptocurrencies is to simplify cross-border transactions and settlements — and it has. However, the fundamental problem of safekeeping still exist. In other words, we still need a crypto equivalence of CSDs. Companies in the space seem to tackle this problem with a traditional mindset:
- Don’t worry, give me your private key (Xapo, Coinbase, almost everyone => eventually Amazon KMS??)
- You go through me, I charge you a fee.. forever (Bitgo multi-sig)
These approaches may end up being what institutions want (Xapo holds ~$1B(?!!) crypto). I have no idea. But it seems really backwards to me. In this new age of trustlessness and decentralization, does it not feel wrong that custody is still done in a centralized manner? To me, the ultimate solution may be boiled down to two elements:
- Internal control: we have 5 people in our company/fund, we want to not have to trust that one millennial to hold the key (and possibly run away with it)
- Security with obscurity: I want people to know that I have a secure system, but I do not want to disclose what that looks like
Internal control is tricky, but there are already many startups and security companies tackling the issue. The standard practice is to split the key up using standard threshold signatures (Schnorr, BLS, take your pick). Of course, different companies do it differently. I generally believe that the more humans involved, and the more tedious the process is, the more secure the system tend to be.
Here’s roughly how a typical cryptofund or crypto holding company can achieve basic internal control with BLS:
- Each stakeholder generates own private key, derive a company master key contribution and a verification vector
- Publish or exchange the verification vector
- Privately, stakeholders exchange their key contribution and validate against the corresponding shared verification vector
- Combine any m of n contributions to achieve company master key. The order or m selection should not matter here
The above method will obviously not guarantee the security of an individual stakeholder’s private key. I’d highly recommend either use a HSM or come up with your own elaborative scheme.
Security with Obscurity
“Security + obscurity” seems to be what every security company strives for. A responsible company should have a secret process to secure assets/tokens. However, the company also naturally cannot disclose the above process. In order for LPs or outside investors to place capital in the company, they REALLY want the proof that there’s a security protocol in place. Right now, pretty much all the investors in the space simply choose to trust the companies/funds to safe keep their money. What can go wrong? Well… how different is this from the thousands of customers trusting their Bitcoins to Mark and Mt. Gox? Some describe cryptofunds as escrows that charge 2–20. To me, the analogy would only hold true if you replace “escrows” with “slot machines.”
This problem smells distinctly like a zero knowledge problem to me.
Zero knowledge is complicated. When it comes to zk, there are a few factors we need to consider:
- proof size
- trusted setup
- how fast is it to verify
Projects like ZCash picks the trusted setup because smaller proof size and faster verification speed are crucial for the cryptocurrency to be usable. They go through a rigorous trusted setup ceremony (later improved MPC) in order to generate entropy for SNARK params (proving/verifying keys). These public parameters are basically used to determine which point to check for the two polynomials (Read more about how zk-SNARKs work). Stark, on the other hand, is not really usable (for now) due to its large proof size. Bulletproof eliminates the trusted setup process as well, however, the verifying process is still linear. Arguably, that property really limits the “knowledge” in the ZK proof of knowledge (what type of proofs it can handle/applications it can support before becoming impractical). Bulletproof is an amazing and totally suitable addition to cryptocurrencies though!
An example proof for custody (6/8) can be seen as the following:
- There exist n shareholders, m participated whereas m ≤ n & m > 5/8n
- h(S1, V1) … (Sn, Vn), for each there exists h(Si, Vi) = hi where S represents the nonce, V represents the verification
- k(c1…c6) = k(c2…c7) =… where key generation can be proven such that any 6 participants would yield the same result
Suppose you agree with the presumption that decentralized custody (dCustody for short) will help us sleep better at night. We then must tackle another problem: Consensus. Yes, cryptocurrency solved the consensus problem. However, it’s quite hard to apply the same solution to every problem. Most of the time, “blockchain” is simply not necessary. I’d argue this is one of the few instances that consensus does matter.
I see a few ways to architect the consensus layer of dCustody:
- Completely open system, most similar Bitcoin or zCash: Create a layer on top that manages the data and proofs. I would say this approach seems the easiest to start, but hardest to finish.
- Open system, with modifications (a little enterprisy, decent amount of consensus): Create a “pure” chain for the sole purpose of time-stamping events of the companies adopting the chain. Events include keeping track of proofs described above, but also anything they want third party auditors to audit. There are quite a few ways to achieve this type of “enterprise” public chain — Nakamoto Consensus, or some sort of multi-chain setup where everyone merge mines all the chains.
- Closed system (super enterprisy, some consensus): EOS style consensus, or even ripple style consensus would suffice. But it would function more as like a B2B company than a “blockchain” company.
- Closed system (no consensus): this is always an option: charge a memebership fee like traditional CSDs. Bad idea because… it kind of defeats the purpose of this thought exercise.
There are still millions of problems to think through, for example:
- Permission/revokability of stakeholders participating in the organization key generation scheme: People come and leave the organization all the time. Should there be a permission layer? My view is to always avoid adding “smart contract” capabilities to a chain unless absolutely necessary because… complexity is ALWAYS bad in engineering.
- Incentive structure for the different consensus protocols discussed above. If mining is a necessity, who mines? Who pays the developers? The easiest/most handwavey solution is obviously “let’s just do an ICO,” but I would avoid it as much as possible. I think even the more complex “governance token” approaches are better.
- Zero Knowledge magic