# Rethinking Counterparty Risk in Multi-Party Computation By [Abraham Litwin-Logan](https://paragraph.com/@abeisr) · 2024-10-07 --- **Rethinking Counterparty Risk in Multi-Party Computation** In the rapidly evolving landscape of digital asset custody, Multi-Party Computation (MPC) has emerged as the standard to secure cryptographic keys by distributing them across multiple parties. The idea is simple but powerful: no single party can unilaterally control or access the assets, reducing the risk of theft or unauthorized transactions. However, as MPC becomes more widely adopted, it’s crucial to examine the real-world implications of its implementation, particularly the counterparty risks that have arisen from the mainstream architectures of MPC at the institutional custody level. While, some attention has been given to industry incidents such as the Liminal-Wazir case in 2024 that resulted in a $230m+ loss and the Fireblocks lawsuit with StakeHound in 2021 arising from a $75m+ loss, little analysis of the underlying MPC models that safeguard hundreds of billions of dollars in crypto assets has been undertaken. **The Market Standard** The key infrastructure of leading MPC-based digital asset custody platforms fall into two buckets: 1. Majority Control (e.g. 2/3 setup where the client holds 1 key shard and the _service provider_ holds the other 2 key shards ← 2 of the 3 keys are required to transact) 2. Shared Control (e.g. 2/2 setup where the client holds 1 key shard and the service provider holds 1 key shard ← both keys are required to transact) Both of these models suffer from an enormous amount of intrinsic counterparty risk. That being said, before we get into why each model results in the endangerment of client funds; it’s important to keep in mind that we must focus more on what might happen in a disaster scenario rather than what happens during day-to-day operations. **Why?** Because, security is not only about preventing bad things from happening; but it’s also about ensuring that if bad things happen; those things aren’t THAT bad. But, back to key infrastructure… **The first model** (majority control) is effectively custodial (since the _service provider_ has sufficient key material to transact on a client's behalf) and accordingly creates two points of counterparty risk. 1. Risk of asset loss Since the _service provider_ holds sufficient key material to transact on a clients behalf; if their systems are entirely penetrated; an attacker would be able to transact on a clients behalf. In other words, a full penetration could and likely would result in an attacker being able to move client assets despite not compromising the clients key material. 2. Risk of asset recovery Since the client does not hold enough key material to unilaterally transact, an attacker that has successfully penetrated the _service providers_ system could delete the providers key material rendering the clients key shards ineffectual and the assets held in the wallet unrecoverable. **The second model** (shared control) while not custodial (or self-custodial) has one critical point of counterparty risk. If the _service provider_ is penetrated or offline, the attacker can render the assets in the wallet unrecoverable as both the client key shard AND the service provider key shard (which is now controlled by the attacker) are required in order to transact Service providers use different methods to protect against such breaches, but high levels of counterparty risk are still clear from an architectural perspective. **Centralized Relay Servers: Another; Achilles' Heel of MPC Solutions** Another critical but often overlooked risk in mainstream MPC solutions is the reliance on centralized relay servers to coordinate the signing process. These servers are tasked with relaying the communication between user devices, ensuring that transactions are signed and executed reliably. However, this centralization introduces a significant point of failure. If the relay server is penetrated or taken offline, MPC communication is brought to a standstill and clients are unable to easily transact. Although this is a temporary and less concerning attack vector compared to the key-related attacks previously discussed, even brief downtime can be catastrophic in the fast-moving crypto industry. **Moving Towards Decentralization: Reducing Counterparty Risk** At Tholos, we’ve taken a different approach. From day one, we’ve been deeply worried about systems that have too much control and accordingly have architected our solution to empower the clients rather than us as a service provider. On key infrastructure, we use a vastly divergent model from the leading approach. Clients choose between our standard model (where clients choose how many key shards to generate AND hold the **totality** of key shards themselves) and our flex model (where clients choose how many key shards to generate AND hold the **majority of key shards themselves**). Consequently, neither of the aforementioned key-related attack vectors is applicable to either of our models. In the standard model, we don’t have any key material so naturally we can never transact on your behalf; and equally we can never block you from transacting. In the flex model, we don’t have enough key material to transact on your behalf (we retain threshold - 1 key shards), and consequently since clients hold the majority of shards, we can never block them from transacting. **Our model eliminates the primary counterparty risk associated with mainstream _service provider_ models and offers true security and autonomy.** Yet, we can do even better. Currently, we also use relay servers to facilitate the MPC signing process and while we use best practices including end-to-end encryption we’d eventually like to get to a place where clients are able to trustlessly coordinate the MPC signing process. To accomplish this, we will be launching the Tholos node network (titled “Proof of Relay"). This node network will enable the decentralized coordination and relaying of the MPC signing process and ensure business continuity even in the event of a breach or attack. Interestingly, this _proof of relay_ system unlocks a number of fascinating use-cases beyond the coordination of MPC signing process; from relaying sensitive encrypted information to enabling the coordination of DePin sensors, but I'll save getting into the weeds there for another article. **The Future of MPC and Digital Asset Security** As the digital asset landscape matures, it is imperative to critically assess the inherent counterparty risks posed by mainstream MPC solutions. While MPC offers robust security against unauthorized access, the traditional models of majority and shared control introduce significant vulnerabilities that could compromise client assets in catastrophic scenarios. At Tholos, our commitment to client autonomy and security drives us to innovate beyond these conventional models. By empowering clients to retain control of their key material and by minimizing our own influence, we reduce the counterparty risks that plague other MPC solutions. The future of MPC lies in decentralization and client empowerment; and Tholos is excited to be leading the way in redefining secure digital asset custody. --- *Originally published on [Abraham Litwin-Logan](https://paragraph.com/@abeisr/rethinking-counterparty-risk-in-multi-party-computation)*