Op-Ed: THORChain’s Security Design Probably Needs to Change

Publisher’s Note: THORChain University remains ambivalent to the opinions and claims made in this and all of its published op-ed articles. In publishing, we simply seek to provide community members a platform to formally introduce and justify compelling stances regarding the THORChain blockchain.

THORChain’s about to-be released App Layer will compete with its base layer swap pools for its security budget, which will change the underlying assumptions of TC’s Incentive Pendulum (IP). I will argue that the introduction of Secured Assets to THORChain breaks the logic of its IP as well as its incentive design.

In other words, it is my position that TC needs to rethink two key elements of its design from the ground up: the Incentive Pendulum and its general Security Design.

Security Design

The fundamental issue all cross-chain protocols must solve is how to custody the exogenous assets (assets not native to the home chain, i.e. THORChain) of strangers in a trust-minimized way. TC does this by requiring its validators (i.e. nodes) to buy and bond RUNE, which would lose its value should the validators go rogue and steal the exogenous capital. In theory, the Economic Security Design (ESD) of TC is such that validators should always stand to lose more than they would gain if they were to break bad.

This principle was instantiated in TC’s initial ESD by targeting a 2:1 ratio of Bonded RUNE to exogenous capital. Thus, nodes would stand to lose 50% of their capital should they steal the exogenous capital. This is very “economically secure” but also very capital inefficient.

So capital inefficient, in fact, that the network found that, in order to scale, it needed to adjust the ESD in order to onboard more capital in the pools to grow. It did this by allowing RUNE holders to bond their RUNE to nodes run by others.

This was not an insignificant change to TC’s ESD. The initial design, and foundational assumption of TC’s ESD was that Node Operators (NOs) would be risking their own capital to secure the network. However, with the introduction of Bond Providers (BPs), this was no longer necessarily the case. By accepting the bonds of others, NOs continue to secure the network, but no longer are necessarily risking their own capital. Even keeping the 2:1 ratio of the initial design, if NOs only put up half of the bonded RUNE it de facto changes the ratio to 1:1 as far as the NOs are concerned — half as secure as the initial design.

But neither is this so cut and dried as it might seem. Large BPs would not simply trust anon NOs with large amounts of capital. Many NOs are doxxed to their BPs, restoring some of the security of the initial design. Even if a NO might be risking less capital directly themselves, they are beholden to people who know their identity and likely have some legal agreements worked out.

The matter is further complicated by the fact that some individual Node Operators (NOs) run multiple nodes (validators). Taken together with the fact that NOs are no longer only risking their own capital, TC finds itself in the position that a relatively small number of individuals control a lot more node votes (and TSS keys) in the protocol than they do bonded RUNE. Again, with NOs being doxxed to their BPs, this isn’t necessarily an issue — but it is worth keeping in mind. The potential danger is if a handful of NOs conspire together, they could have enough keys to steal the exogenous assets from the protocol and still come out ahead, despite losing the value of their personally bonded RUNE.

The big takeaway here, though, is that the fundamental ESD of TC has always rested philosophically on self-interest. TC has never optimistically trusted NOs to be good actors. Instead, it has always trusted them to act in their personal self-interest, designing the system in such a way that there would never be an incentive for them to steal the exogenous assets from the protocol, as they would always lose more than they stood to gain by doing so. This is what is meant by “Economic Security” in TC — that in theory, the NOs would always have more value at stake than the amount of exogenous capital in the protocol.

This ratio is enforced at the protocol level by limiting new deposits of exogenous capital when the network is underbonded. Thus, we can say that TC has a Security Budget, which is spent when there are too many exogenous assets in the protocol relative to the amount of bonded RUNE. When this happens, in order for new exogenous assets to be deposited into the protocol, there must first be an increase in the bond.

THORChain’s Incentive Pendulum

TC is premised upon positive incentives. Its design assumes that protocol participants are rational actors seeking return on their capital. There are three main classes of TC participants that earn a return on their capital in the protocol: Liquidity Providers (LPs) depositing into the swap pools, BPs/NOs securing the network, and arbitrageurs profiting by keeping the token prices correct in the pools. Whereas the latter are self-sufficient, TC needed to incentivize liquidity provision and bond provision.

The value of the TC base layer is that users of the protocol are willing to pay Liquidity Fees (LFs) to the protocol in order to swap between native, L1 assets in a permissionless, non-custodial, and trust-minimized manner. The LFs the protocol collects are then in turn distributed to the LPs and BPs as a reward for loaning their capital to the protocol. There were also Block Rewards initially, but they’re not really that relevant to the discussion at hand.

To determine how much of these LFs go to the LPs relative to the BPs, THORChain implemented an algorithm called the Incentive Pendulum (IP). In the original design of TC, there was only one source of exogenous capital in the protocol: the constant product swap pools (LPs), half of which are endogenous RUNE and half exogenous L1 assets of other chains. Thus, to maintain the 2:1 ratio, the protocol strove to have twice as much bonded RUNE as there were exogenous assets in the pools. If the protocol was underbonded — i.e. bonded RUNE had fallen below the 2:1 ratio, then a greater share of the yield would go to the BPs, encouraging more participants to bond RUNE. On the other hand, if TC was overbonded, more yield would go to the LPs, encouraging more actors to deposit into the pools.

This was a more or less successful model for the first three and a half years of the network.

A key point here is that when the network’s security budget is at capacity, the IP funnels most of the yield to the BPs in an attempt to increase the economic security. Thus, if the security budget is maxxed out, LPs aren’t getting much yield.

We see here that at the time of this writing, BPs are receiving almost 80% of TC’s earnings, while LPs earn only a quarter of that.

Enter Secured Assets

Secured Assets (SAs) are about to be launched, and are fundamental to the functioning of TC’s new App Layer. Users will deposit native tokens, say BTC, into TC’s Asgard vaults and will receive a token native to the TC blockchain that is redeemable 1:1 for the underlying assets — these are SAs. They will be comparable to wBTC on ETH (except non-KYC, permissionless, and held far more securely than a 2/3 multisig). SAs introduce a second source of exogenous assets to the TC Protocol (we’re ignoring Trade Assets).

Thus, TC validators must now secure both SAs and the Swap Pools and this has non-trivial implications on the assumptions behind the IP.

As Rujira/App Layer becomes proven, I expect it to have an essentially limitless appetite for SAs — in particular BTC backed loans. This means that TC’s security budget will always be at capacity, which in turn means that under current logic the IP will perpetually favor BPs over LPs.

Secured Assets and LPs compete for Security Budget

It is my contention that the introduction of SAs breaks the assumptions underpinning the current design of the IP. Namely, the current IP logic assumes that all exogenous assets secured by the nodes are in the swap pools and SAs clearly make this no longer the case.

If my assumption that the App Layer will have a limitless appetite for SAs holds, then LPs will be forever stuck receiving little yield (with current IP design).

Put more simply, a high adoption rate of SAs will starve TC swap pool LPs of yield — undermining the core value proposition of TC itself. If people aren’t incentivized to LP, they won’t. No LP pools; no TC. This is especially concerning, because unlike BPs, LPs also have to contend with IL, which reduces their yield even further.

Taking the other side

Let’s now examine how I might be wrong.

Probably the largest reason I could be wrong is that the App Layer will be generating a new source of revenue for TC. In most cases, half of the fees the App Layer collects will be funneled to TC and then distributed per the IP. If the App Layer revenue is significant enough, LPs could still earn a good return on their capital because even though they’re getting a small slice of the pie, the pie itself is much larger and they end up coming out ahead.

Another strong counterpoint is that currently the protocol owns a big chunk of the pools (Protocol Owned Liquidity/POL) and is yield-insensitive. This capital isn’t going anywhere. Most non-POL LPs are suffering from extreme IL due to synth leverage, and will be made whole far quicker by the RUNE price improving rather than by earning yield. Thus, current LPs aren’t really affected by low LP yields.

Lastly, one mustn’t forget that an increasing RUNE price naturally grows the security budget/cap. This creates a virtuous cycle: a higher RUNE price creates more space for exogenous assets to be added to the protocol, they in turn generate more yield for TC, this yield directly buys more RUNE off the market and leads to a higher RUNE price, repeat. RUNE price appreciation alone could go a long way towards solving security budget concerns.

Answering these challenges

I’ll address the second of these arguments first. I agree and grant that current LPs are essentially indifferent to yield right now, but do not expect this to remain the case going forward. In particular, TC is about to add several new chains and these new pools will not have the characteristics I point out above.

If we want these new chains to be able to provide good swap quotes, their pools will need to have sufficient depth to do so. But if there is little yield to incentivize participants to deposit into these pools, they likely won’t. Additionally, as current DLPs recover their position through a (hopefully) rising RUNE price, they will once again become sensitive to yields — no longer being held hostage by IL.

This illustrates the larger point I am trying to make: there’s not currently enough yield to incentivize both LPs and BPs to the extent that is necessary. Keeping the IP as is (and security budget maxxed out) will starve the new pools of yield. Should yield be shunted to LPs, failing to incentivize new BPs enough will stunt the expansion of the security cap and prevent the network from onboarding new exogenous capital, choking both the App Layer and the pools.

Returning to the first point, it is beyond my ability to determine whether or not the App Layer will generate enough revenue to compensate LPs for being stuck receiving a small portion of TC earnings. But my gut is skeptical, especially since collateralized BTC loans have a huge demand, but don’t pay much.

But perhaps capital inefficient apps such as Lending will be compensated with capital efficient ones like Perpetual Futures. Again, it’s beyond my ability to reason about. My guess though is that en toto, SAs won’t be economically productive enough to compensate for their competition with LPs for security cap space.

Regarding my last point about RUNE price, I don’t disagree, but hopefully TC has learned its lesson about assuming the RUNE price will go up the way we want it to.

THORChain must evolve

If my assumptions above prove correct, TC must reimagine how it distributes yield (the IP), as well as how it secures exogenous capital.

Rethinking the IP

Currently, the IP is shaped by how “economically secure” the network is, i.e. the ratio of bonded RUNE to exogenous capital in TC’s Asgard vaults. This made sense when the only source of exogenous capital was the swap pools, but breaks down with the introduction of SAs. TC will need to sufficiently reward its LPs even if the security budget is more or less constantly at cap due to SAs.

To me, it seems inevitable that the logic of the IP will have to move away from the economic security of the network being its primary input and determinant.

I’m told it’s a big lift from a development perspective, but I think one possible solution would be the following: to build out a framework that adjusts yield on a per pool basis. In doing so, we could avert yield from the pools that are primarily POL and/or heavily synthed, while still encouraging LPs to deposit in the pools of new chains.

Frankly though, I’m not sure what the new design should look like, only that TC will probably need to come up with one. With that said, should TC create a Cold Vault (discussed below), the IP might be able to stay as-is.

New Security Design

In the short term, TC will almost certainly address its security cap issue by relaxing its stance on aiming for a 2:1 bond to exogenous capital ratio to 1:1 instead. This will create plenty of space in the security budget for capital for new chains and SAs on the App Layer. It would also have the benefit of funneling more yield to the pools. There is a chance that this change alone will be sufficient to address TC’s security budget issue. I further think this is probably fine from an Economic Security perspective.

However, if my assumption that there will be essentially limitless demand for SAs holds, then this ratio relaxation only kicks the can down the road, rather than truly solving it. If I end up being correct, SAs will eventually fill up the security cap and we’ll be right back where we started. Thus, I am convinced a significant change in TC’s security design will be necessary to accommodate the App Layer.

Offline Cold Vaults for Secured Assets

One TC community member came up with an idea that potentially could solve this issue once and for all:

Inspired by the the previous design and to meet the needs of Rujira to scale TVL in the future I propose a modification to the original cold vaults idea here:

https://gitlab.com/thorchain/thornode/-/issues/1561

The idea is similar, except it would leverage Vultisig plugins and the node set to generate a giant 1+X/3 offline vault, it will not have any self imposed economic limits, allowing TVL to scale infinitely without limit, but securely.

As an example we will say this offline cold vault will be a (60/90 threshold) multisig, X is the amount of offline keys required to sign off, for this example it will be 6, so 54 thorchain keys and 36 offline keys.

The Offline Guardians (OGs) will be a formed from a mimir (67%) controlled whitelisted set of 36 thorchain addresses. The Offline Guardians will be required via vultisig plugin to sign a transaction every churn as proof liveness and will hold 36 keys to the cold vaults

The Offline Guardians would have an income stream of for example 1%, but set by mimir to ensure they are not over or underpaid.

The Offline Guardians set can only be updated with signoff from both the whitelist mimir (67% of NOs) and 6 other OGs. After 2 churns of failing to sign a liveness tx, any failing Offline Guardians will be replaced with new ones.

Any transactions out of the cold vaults will also take ~2 churns, In the first churn a mimir will be voted, after the second churn a NOs tx will be staged ready for Offline Guardians signoff via Vultisig.

The Thorchain NOs will hold 54 keys, meaning they control the majority of the keys, therefore the Offline Guardians cannot collude.

The 54 NOs cold vault keys will be sharded and distributed exactly the same way as Hot Asgard vault keys shares (hopefully leverages much of the same codebase/logic)

Even If the entire thorchain set of NOs were compromised, or a 0 day exploit abused, the assets are unable to be drained.

Just like a CEX, we only need enough in the hot vaults to process withdrawals smoothly.

This will give Secured Assets greater than CEX like security, and with DEX like transparent onchain verifiable proof-of-reserves and solvency.

Were this plan (or a version of it) to be adopted, I think it would comprehensively solve TC’s security budget issue. Some amount of SAs would stay “hot” in the Asgard vaults, while the rest are stored in the Cold Vault.

TC’s economic security assumptions (and maybe even the IP) could otherwise stay pretty much unchanged by simply not factoring the assets in the Cold Vault.

Custodying exogenous assets in a decentralized manner is no small feat. I think this Cold Vault proposal offers a great compromise of scalability, security, and decentralization. I imagine TC will eventually have little choice but to move towards something like it.

Conclusion

In summary, hopefully I have convinced you that the introduction of SAs will break the logic of the IP, requiring some kind of a meaningful change to be implemented eventually. Luckily, relaxing the ratio to 1:1 will buy us time, but only so much. I think it would behoove us to get ahead of this while we still can.