--- robots: noindex, nofollow --- __TBD:__ _Consider other vulnerabilities from https://hackmd.io/CcGwhpVVTXi4nX_MzGZtnQ_ _Particularly:_ * _Correlation_ * _Centralization_ * _Social Engineering_ _They're somewhat outside of the scope of MPOC/MPOF, but some of them may highlight increased vulnerabilities. Possibly add new sections on "Centralization" and "Socialization" after the MPOC/MPOF Balance_ ------- # #SmartCustody: The Dangers of DAO Treasury Management ###### tags: `article / in process` DAO treasuries are huge. By current count, the biggest ones contain approximately [$10B in assets](https://open-orgs.info/). Obviously, those assets need to be managed responsibly. Unfortunately, current management methodologies are quite simplistic — usually just requiring a quorum of single signatures to release funds. This could easily result in billion-dollar mistakes. What follows is a analysis of some of the threats faced by current DAO treasury management methodologies, made with Blockchain Commons' [#SmartCustody system](https://www.smartcustody.com/), which uses simple procedures and an adversary-focused risk-analysis model to identify dangers in cryptocurrency custodianship. Accompanying that is a discussion of possible solutions for making access to DAO treasuries independent, resilient, and open. ## The Problems with Treasury Access Contract actions in Ethereum are usually enabled when a quorum of single-signature keys authenticate the action. This is clearly intended to improve the resilience of the funds, but feeling that funds are safe because of such a contract can create false security and encourage irresponsible key management. This can be made worse by the fact that DAO treasury management usually omits a wide variety of #SmartCustody practices: they've thus kicked the problem of treasury-fund resilience down the road, erasing the possibility of Single Points of Failure or Compromise, but leaving larger scale vulnerability intact. ### Minimal Point of Compromise (MPOC) We generally talk about Single Points of Compromise, where the theft of a single secret can result in the loss of funds. With a multi-key scenario like a DAO, we instead have to ask: is there a reasonable way that sufficient keys could be stolen to compromise the funds? This is the Minimal Point of Compromise (MPOC). The possibility of a MPOC tends to be exacerbated by governance decisions in DAOs: **Lack of Offline Keys.** Private keys don't have to be networked, but they probably will be if some specific means isn't used to convince members to do otherwise — which generally requires making it easy to have a key offline and still have it be usable. Most DAOs don't have requirements or supporting architecture for maintaining keys offline. **Lack of Partitioning.** Some DAOs are created by friends and acquaintances. Even when they're not, DAO members tend to move through the same communities. For example, consider Bitcoin 2021 in Miama, Florida: how many DAO members might have been there, dwelling in the same physical locations, using the same Wifi? When people are connected, socially or physically, then their keys aren't partitioned, which makes those keys more prone to networked or social attacks. _Having keys online, particularly those keys that belong to people who might be identified as a group, can make a DAO treasury vulnerable to a MPOC._ ### Minimal Points of Failure (MPOF) Similarly, though we usually discuss Single Points of Failure, there may also be some possible (even likely) way that sufficient keys could be lost to result in the loss of the funds. This is the Minimal Point of Failure (MPOF). The possibility of a MPOF tends to be exacerbated by inattention to single points of failure, which can multiply: **Lack of Estate Planning.** One of the biggest problems can be a long-term one: the death, incapacitation, or departure of members. Digital assets are still new enough that little work has been done in resolving this issue. Though this might not be a problem if one member passes, over time it can multiply. **Lack of Oversight.** Cryptocurrencies are built around the fact that members do not want any sort of centralized authority. But this can result in a lack of functionality that might otherwise have been carried out by such an authority. That includes oversight. One way to resolve the issue of slow lossage of keys over time is through administrative functionality that regularly checks for key access. Without that sort of oversight, you never know when you might suddenly drop from sufficient keys to achieve quorum to insufficient keys to do so. _Not considering how keys can be lost over time, and not monitoring that potential lossage, can make a DAO treasury vulnerable to a MPOF._ ### Balancing MPOC and MPOF MPOC and MPOF lie in balance: if you create a contract that is not subject to MPOC, then it is in more danger from MPOF, and vice-versa. Consider a simple contract with 10 key holders that has a threshold of 2 for usage of treasury funds. Clearly, that's a very low number that is very prone to compromise (either internally or externally), as it only requires two people to collude or two keys to be stolen. However, you're probably never going to lose the funds due to key-lossage, as that would require nine keys to go awry. The flipside has the opposite problem: if 8 signatures are required to use funds, then there's little problem with collusion or theft, but if three people lose their keys, or die, or otherwise drop out, then the funds are lost. The problem of drop-outs in particular can increase as a DAO ages. A DAO thus needs carefully designed policies that walk the line between MPOC and MPOF in the best way possible. ## Solutions: Phase One — The Quick Fixes Blockchain Commons focuses on supporting responsible key management by enabling independence, privacy, resilience, and openness in the design of digital-asset wallets. Our [Gordian system](https://github.com/BlockchainCommons/Gordian) is at the heart of that; it details a wallet architecture, best practices, and principles focused on these goals. Similarly, our [#SmartCustody system](https://www.smartcustody.com/) details adversaries and suggests procedures and risk-management processes that can further secure digital wealth. We're not interested in analyzing smart contracts (though we have sonme confidence in Gnosis), and we're not creating new ones. Instead we suggest the use of Gordian and #SmartCustody methodologies that largely focus on different ways of thinking. Though, our methodologies are currently focused on Bitcoin, their techniques are equally applicable to Ethereum — and apps and docs could be updated with an appropriate amount of effort. The following four points offer what we consider some quick fixes for the dangers of DAO Treasury Management: **Consider Signature Design.** Though Ethereum doesn't have a true multisig, its use of single-signature quorum in contracts is similar. As a result, Blockchain Commons' article on ["Designing Multisigs for Independence & Resilience"](https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Multisig.md) could be easily applied to Ethereum designs. **Keep Keys Offline.** Moving keys offline and then providing great usability for them is a core element of Blockchain Commons' Gordian system, which demonstrates how to use airgaps to maximize security. We currently have two reference apps that demonstrate this functionality. Users can store keys offline and use them for signatures with [Gordian Cosigner](https://github.com/BlockchainCommons/GordianCosigner-iOS); or users can convert keys to QR codes, store them on offline in [Gordian QRTool](https://github.com/BlockchainCommons/GordianQRTool-iOS), and then move them online as needed. The QRTool functionality could immediately be used with Ethereum, while Cosigner would require expansion for Ethereum usage, as it's currently focused on Bitcoin. **Derive Keys Offline.** Keeping a master-key offline and only moving derived keys online is another simple way to improve security. An app to do so would be another benefit for DAO users. **Use SSKR for Recovery.** One of the trickiest problems for responsible key management is solving the issue of death/incapacitation (or even just departure). Blockchain Commons suggests [Sharded Secret Key Reconstruction(SSKR)](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-011-sskr.md) as one option. It allows someone to shard a key, currently using Shamir's Secret Sharing, and to give out those shares. Our reference apps even convert shares to QR codes, which allows then to be encoded in Gordian QRTool, as a simple way to have friends and family store your shares. Within a DAO, there might be a desire to keep shares divvied up among other members of the DAO, to maximize the ability for the DAO to restore itself if needed, but that becomes a much more complex issue of governance that goes beyond the technology. Fundamentally, these quick fixes require little more than changes in thinking about key management. ## Solutions: Phase Two — Further Development Going beyond some of the simpler solutions, Blockchain Commons' complete Gordian architecture demonstrates how to use airgaps, torgaps, and autonomous multisigs to take the next step. All of these functions, briefly outlined in the [Gordian architecture overview](https://github.com/BlockchainCommons/Gordian) could offer even more security to DAOs, but they would require more fundamental work than just the quick fixes of phase 1. ## Prioritizing the Solution Blockchain Commons is focused on responsible key management. A number of its techniques, architectures, and references could offer strong support to DAO treasuries, which currently have vulnerabilities that may not be fully considered. Since the main focus of Blockchain Commons thus far has been on Bitcoin, adapting these policies (and especially references and documents) to Ethereum would take effort, but much less so than creating something from scratch. If there's interest and desire in prioritizing this work, please contact us at team@blockchaincommons.com ### Why Blockchain Commons? Blockchain Commons has spent more than three years working on responsible key management techniques, much of that in conjunction with an array wallet developers in the [Airgapped Wallet Community](https://github.com/BlockchainCommons/Airgapped-Wallet-Community). Our [#SmartCustody book](https://www.smartcustody.com/) is a well-received and well-reviewed discussion of risk management, while we've also built resilience into our [Gordian architecture](https://github.com/BlockchainCommons/Gordian). We continue to work on digital-asset resilience in a number of ways, such as our recent [design-of-multisig article](https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Multisig.md) and in interoperable specifications such as [LifeHash](https://github.com/BlockchainCommons/bc-lifehash). Blockchain Commons was founded by Christopher Allen, the co-author of the IETF TLS protocol that is today used to secure most web sites on the internet, including financial operations from banking to e-commerce. He is also the co-author of the [W3C DID standard](https://www.w3.org/2019/did-wg/PublStatus) for decentralized identity, which is now in [CR (Candidate Recommendation) stage](https://www.w3.org/2020/Process-20200915/#transition-cr). Together these two standards span 20 years of security and privacy experience, which has also included work with Blockstream, Certicom, and Blackphone.