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.

By the end of 2025 there will be ~500 well-funded Layer 1 Blockchains, ~120 well-funded Layer 2/3 Blockchains, and ~100+ App-chains.

Fragmented across these hundreds of chains lies ~2,000,000+ tokens and somewhere around ~10,000 dApps.

The growth in the number of blockchains hasn’t been steady.

Rather the chart looks something like this:

Why are so many chains being launched? Why are more chains being launched than ever before?

The answer is pretty simple; the incentives to launch a new network are enormous.

• valuations for nascent networks are sky-high,

• there is clear market demand for L1/L2 tokens (32 of the top 50 tokens are L1 or L2 tokens), and;

• in the longterm, significant value should accrue to the underlying infrastructure that is expected to serve as a base-layer for the future apps that will onboard our industry’s first billion users.

These reasons combined with easyish access to funding has made the pitch for new networks pretty straightforward. Plus, the easyish access to funding also makes sense; you don’t need to displace Ethereum to score a massive exit, if you can become the 15th most valuable chain that’s still hugely valuable from an investment return perspective).

Will this trend continue?

I think that most investors (and certainly most users) would agree that there are too many competing L1s and L2s. That being said, I think that I would take the contrarian position here in that if we presume that blockchain-based applications will be massive in the future; the rails of which these applications are based on will be wildly valuable.

As a result, the enormous potential value of a winner L1 or L2 justifies intense and innumerable competition.

That does not mean that there are too few chains competing at this current moment. In reality, it could very well be that the market is overheated (from a # of new chain perspective as of August 2024) and that a lull in new chain launches should be expected; but in the longrun I think that this graph continues to exponentially unfold.

Let’s not forget that once Crypto transcends more deeply into the mainstream the competition to win parts of the stack will become even more intense as traditional non-crypto firms vie for market share - and what part of the stack is more important than the underlying blockchains enabling all on-chain activity? Probably nothing.

Even if this future does not play out and competition amongst L1s and L2s subside with clear winners emerging, the # of new chains will still only continue to increase. Why? appchains.

Over the last 24 months we’ve seen numerous examples of products with product market fit decide to launch appchains. The reasons are clear:

• having wildly fluctuating costs to interact with a dApp (as a result of fluctuating gas fees) is terrible UX

• with appchains, projects can tailor chain infrastructure to specific needs

• for projects with massive scale; their usage is so significant that it drives the costs of using the chain up for everyone thus resulting in a poor experience for their customers (and other users of the chain)

From dYdX chain being launched in order to decentralize dYdX, to the Ronin Network built to reduce network congestion, or Zora launching their own appchain when they found high gas costs on Ethereum to be “a systemic inhibitor to adoption, across the board from DeFi to gaming to NFTs, appchains have emerged as a solution to critical issues ranging from scalability to decentralization.

This trend will continue.

Even ignoring the clear functionality advantages of migrating successful operations on a general purpose blockchain to an appchain; the business incentives are obvious.

Simply, why control part of the stack (the app) when you can control most of the stack (the app+underlying chain). This becomes even more compelling when launching your own chain only takes a couple of clicks.

So how does this all intersect with custody?

In short, new chains have new tokens, and users (whether they are teams, investors, or individuals) want to securely hold and use the new tokens on the new chains.

Usually, there are a decent number of options for an individual to hold new tokens on a new chain, BUT normally there are NO good options for a group to hold new tokens on a new chain.

On large chains with significant traction (e.g. Ethereum or Solana) most groups serious about securely holding assets have two options; Multisigs or MPC custody products. But, new chains typically don’t benefit from access to either option.

Multisigs are chain specific instances and don’t automatically port over to each new chain and MPC custody products require massive amounts of manual work to add support for new networks.

Since, multisigs are chain specific, distinct multisig contracts have to be launched on every chain. This is problematic across EVM and non-EVM chains, because while EVM chains can use the Safe Contract (which is considered very secure) they will struggle from extremely poor UX.

In many cases, there will be no UI to interact with and as a result only highly-technical participants will be able to leverage the chains multisig. Or there will be a UI built by someone on top of the smart contract, but this is still lacking as you are forced to trust the creator of the front-end and the experience will be highly fragmented with teams being forced to use a seperate app just for that particular chain.

The other option is institutional custody products. But, here the technical constraints of existing platforms and business incentives disfavor expedient support for new networks.

Simply, adding support for new networks is highly complex (particularly for outdated systems) and the large institutional custody players don’t have strong incentives to undergo such rigorous technical challenges when they can just wait for a chain to emerge as successful and add support then.

Let’s double-click on the complexity of adding support for new chains:

Digital asset custody companies broadly face two technical challenges when it comes to adding support for new blockchains

1. blockchain-specific infrastructure

2. data ingestion

Virtually all custody companies and most multi-chain companies in crypto develop their infrastructure in a chain-specific manner. What does this mean? It means that these platforms develop an infrastructure to support a particular chain then launch support for that chain (e.g. Phantom Wallet building out support for Solana and then many months later building out support for Ethereum). Eventually they develop a new architecture to support another chain and then launch support for that chain…

This results in infrastructure overlap, weak reliability, and lethargic support for new networks.

The secondary challenge is data ingestion. Access to fast, reliable, and reasonably priced data on very popular chains is a pain. Most providers boast two of the three characteristics (fast, reliable, or reasonably priced).

These issues are amplified 10x on emerging chains. Some new chains don’t even have any data provider options forcing organizations that want to pull chain-specific data to run their own nodes or query RPC nodes. Running nodes on all the chains a custody company wants to support is not scalable and querying RPC nodes typically requires chain-specific development which lengthens implementation timelines significantly.

As a result of the aforementioned, mainstream custody players will only add support for a new chain if that chain pays them a large fee (usually $500k-$1m) or if that chain is extremely hyped (e.g. Monad).

This leaves an ocean of underserved networks that don’t want to be gorged on exorbitant implementation fees and/or haven’t benefited from enormous attention pre-launch. Yet, would love a solution that doesn’t suffer from the devastating UX of multisigs and has the security advantages of multi-party wallets.

In Short:

There are more new networks than ever before and the # of new networks will only continue to grow. The existing suite of custody solutions can’t efficiently support these new networks. The amalgamation of these two realities leaves a wide gap in the market for a newer player to solve the network custody scalability issue and offer wide-ranging support for assets across hundreds of chains.

The solution:

Tholos ;) But before we get there, let’s talk about what a solution looks like in a bit broader of a sense…

I think that there are four vital elements to solving custody on emerging networks and multi-chain custody writ large:

1. key infrastructure

2. blockchain agnostic infrastructure

3. a solution to the data problem

4. unified design

On key infrastructure, MPC is the right solution.

Single-signer wallets don’t work (single point of failure) and multisigs don’t work (inherently limited to one chain).

MPC does not have a single point of failure AND is blockchain agnostic. Other solutions (e.g. HSMs) are overly complex and have massive barriers to entry.

So the solution must be MPC-based AND said MPC solution has to support for the two primary signing schemes in crypto; ECDSA and EdDSA.

For better or for worse; MPC is extremely complicated, and while there has been significant progress made in the creation of MPC as a service solutions, this is a small drop in the bucket. The reality is that there is a tremendous amount of highly-specialized development required to securely implement these solutions.

On blockchain agnostic infrastructure, a deeply modular architecture is necessary.

While there is immense overlap between most blockchains there are also critical differences between many chain models. As a result of this, the right solution needs to have a highly generalist infrastructure with pre-built frameworks to accommodate variations in network configurations between different blockchains.

This requires significant upfront work, but if done properly provides the payoff of being able to add support for new chains much more reliably and much more quickly.

On the data problem, a blockchain agnostic approach to data ingestion is needed.

I think this is the hardest part in solving this gap in the market. As I discussed previously, data ingestion in this context is really tough.

At Tholos, we’ve spent a-lot of time considering different solutions to this problem and our solution has been a blockchain agnostic data ingestion and transaction execution framework that enables us to directly interact with RPC nodes across any chain.

But, to put it lightly that’s not the easiest thing to build..

On unified design, an aggregated approach to multi-chain asset management is vital.

This is probably the easiest part of the problem, but might be the most critical (since it’s customer-facing).

One of the key value propositions of such a solution is being able to easily and securely manage assets on emerging chains AND across chains. Thus, it’s extremely important to be able to present a unified user experience that makes interacting across chains much more akin to a Web2 fintech company than the switching between dozens of wallets which crypto-natives have become accustomed to.

Tholos

We’ve iterated through different models and learned massive lessons. Fortunately, we made some good decisions at the inception of Tholos and adopted the right key infrastructure, built our architecture in a blockchain agnostic fashion, and designed our platform in a unified fashion.

The data problem was more of a learning lesson. At first, we implemented different data-related API solutions but struggled with inconsistent reliability and lackluster network support. We had a patchwork of half a dozen API solutions which did the job, but this made adding support for new networks highly manual.

In-line with our vision of rapid support for nascent networks, we knew we needed a better solution and this resulted in the narrowing down of our use of our external general-purpose data ingestion providers and our implementation of a network agnostic data ingestion API that enables us to ingest data and submit transactions on any chain.

This has resulted in the fulfillment of the four elements and our transformed capability to add rapid support for new chains.

Now, we can add support for EVM chains in 24 hours, Cosmos-based chains in 48 hours and non-EVM chains in two weeks.

In short, we think there’s a massive opportunity amplified by compelling network effects to shape a GTM around being the first mover on many new chains and leveraging said first-mover advantage to develop a wide array of crosschain support hitting an inflection point through our breadth of crosschain support.

As crypto continues to become more fragmented, Tholos will become the go-to multi-signer wallet for native crosschain custody across the multi-chain landscape.

But, on the other hand, being a remote company enables you to access a much larger pool of talent…which is: game-changing.

I kind of think that in most companies it looks something like:

by being remote, you can get 40-50% better talent, but be 15-25% less productive and 50-70% less tight-knit

Further, I think you should prioritize each metric in the following manner:

1. quality of talent > 2. productivity > 3. tight-knit

Thus, the tradeoff for going remote seems very much worth it. UNLESS, you can recruit the best talent and also get them all in the same place → if we’re being honest this usually means you either have a ton of $$ or having a genuinely excellent network that just all happens to live in the same place.

Presuming you aren’t in the unlikely position of having the latter, I think the former is more interesting to consider:

My conclusion is for startups where cash is super tight (say in broad strokes Pre-Series C) running a remote company is optimal, but when cash is in relative abundance (~Series C+), you should probably look to recruit the best AND make the additional investment to have the whole team work in-person.

In short, nascent blockchains require institutional custody platforms to adopt their networks for institutional adoption to occur, but said platforms only integrate new networks with institutional adoption (or a strong expectation that institutional adoption will occur).

In a bit more detail:

My sense is that most nascent blockchains require a level of institutional interest in order for sustained adoption to occur. Retail usage is ultra-important, but institutions are the ones that generally make the big-ticket investments in infrastructure, consistent volumes, etc that take a new network from being a fad to a real ecosystem.

Yet, the way in which custody infrastructure is composed makes swift institutional adoption of new blockchains improbable.

The trouble is that, in order to attract institutional interest; institutions MUST have a way in which they can securely hold their investments in an emerging network. Herein, lies a core area in which budding networks seem to historically underweight.

Generally, institutions (VCs, family offices, hedge funds, etc) are unlikely to allocate capital to an emerging network if there's no way in which to custody assets in a manner that is suited for institutions. Frankly, this logic makes sense → the last thing an asset manager wants is to explain to their investors how they lost all of their $$ because of a poor custody setup. While, these managers seek returns; at the end of the day they care most about keeping their jobs, and losing assets because you didn’t have proper security measures in place = being fired.

The reason that custody platforms don’t just support new networks out of the gate is that these platforms must manually implement support for each specific network meaning that said platforms will only add support for a new network if customer demand warrants it.

Since a new network usually doesn't yet have customer demand, such networks are in a "no mans land" wherein the only way to attain swift support on custody platforms and consequently speedy institutional adoption is to have VERY significant excitement pre-launch as custody platforms will have a strong sense that there will be customer demand for a particular network.

Yet, for networks that don't have huge followings pre-launch they're often stuck in between a rock and a hard place.

They can't attain institutional adoption because they don't have the custody infrastructure needed for adoption and the custody platforms don't want to build out the infrastructure since there is no institutional adoption.

I think the solution looks like programs offered by custody platforms like Tholos, that offer new networks an easy way to offer institutional custody from day one with an upfront investment that is returned over time based off of that network’s success.

Sure, there is an initial investment needed on behalf of the network, but my (biased) view is that this is one of the better things to allocate capital towards (making it easier for institutions to adopt your network).

Me:

As of writing this, I am 22 years old and live in NYC (though I will be moving to Toronto soon). I grew up living in a number of different places (primarily in North America), but now consider myself a Canadian and view Toronto as my “home.”

I did my undergrad at University College London where I studied British Law and graduated with an LLB (Bachelor of Laws). Following my time at UCL I spent two years at Columbia Law School where I studied American Law and graduated with a JD (Juris Doctor) in 2023.

While, my motivation for studying law was distinct from virtually all of my classmates, I found the experience at both schools very rewarding.

Somewhat interestingly, I first came across crypto when I was 14-15 years old but regrettably I did not spend any time learning anything about it.

My first real foray into blockchain was in 2019 when I learned of and consequently became very interested in blockchain-oriented use cases relating to commercial real estate (particularly surrounding unlocking liquidity in a historically ultra-illiquid asset class).

After spending some time researching this particular use-case, I came to the conclusion that you could create liquid and compelling secondary markets for individual assets (e.g. an apartment building), but you couldn’t do so legally.

Doing so legally would effectively nullify virtually all of the advantages obtained through the use of blockchain. This realization put a temporary end to my interest in blockchain.

That was until 2021. In 2021, a close friend of mine had very quickly become very interested in crypto (starting with Bitcoin and then NFTs).

Fundamentally, I was skeptical of Bitcoin (and still am <-- although in a different way than I was in the past) and I was also doubtful of NFTs. But, the exciting potential associated with Ethereum and smart contracts, quickly overcame my initial skepticism.

From there, I’ve become obsessed with crypto and crypto has grown to become the primary thing I spend my time on.

With that friend and others, we launched a DAO [ReidarDAO] in 2021 which focused (primarily) on the collection of digital assets and later the next year I co-founded a business [Coterie Capital] that offered automated DAO creation and bespoke smart contract work.

During my two years at Columbia, I served on the board of Blockchain@CU (Columbia University’s Blockchain Club), co-founded the Columbia Law Blockchain Club, led a social life, and managed to maintain a somewhat decent attendance record to my classes at law school.

Now, i’m the founder of Tholos. Tholos is an MPC-based digital asset custody platform built for Funds, Businesses, and DAOs enabling these organizations to securely hold digital assets and easily interact with Web3.

Tholos is the natural evolution of my history in the crypto-space.

I personally experienced the pains of managing digital assets as an organization through ReidarDAO, worked with a number of diverse organizations that equally suffered from the same pain-point while building Coterie, and met numerous people spanning the industry that have greatly contributed to my knowledge and understanding of the space through my time contributing to Blockchain@CU and CLBC.

Now, my time is devoted to creating an ultra-functional, secure, and seamless platform equipping organizations to better manage crypto-assets → Tholos

The Blog:

I’m hoping to write and share content here semi-frequently on a number of different topics (with a focus on blockchain + crypto).

Historically, i’ve struggled to motivate myself to frequently write, but let’s see what happens.

To be clear, the contents of this blog are solely my opinion and do not reflect the opinions of any business or organization I have an affiliation with.