On THORChain, LPs are required to stake a combination of RUNE and an external asset. This is similar to Uniswap V1 where users were required to provide an asset alongside ETH, and only ETH. This was updated with Uniswap v2 to permit users to stake anything alongside ETH, but this is unlikely to be the case with THORChain. THORChain is an app-specific chain, and therefore requires its only security model. At a high-level, this security model depends on the co-provision of RUNE as part of its security guarantee, and there are no candidate designs to improve this on the horizon.
This leaves many potential LPs for the network with a dilemma, though. Some LPs will hold a lot of external assets, like BTC, and want to earn THORChain's unique yield on it, but will be unwilling to take on the price risk of RUNE. Other LPs will hold a lot of RUNE and not want to sell it for other assets which they feel have less upside potential.
There are currently 2 options that LPs of external assets have:
provide liquidity asymmetrically
provide capital through a centralised matchmaker
Providing liquidity asymmetrically involves adding *only* an external asset to a pool, and not RUNE. This sounds compelling at first, but really this simply performs a swap on the backend for you. It takes half your BTC, switches it for RUNE, and deposits both for you.
This will psychologically be enough for some, but most will recognise that they are indeed taking on RUNE price exposure.
The second option is to provide capital via a centralised matchmaker. The main candidate here is Nine Realms Capital. Nine Realms works with institutions who want to deposit large amounts of external capital on THORChain to earn the significant yield, but don't want the RUNE price exposure. Nine Realms uses funds granted by the THORChain team from its treasury to place alongside these external assets.
I'm generally in favour of this because it'll help bootstrap the network, but there are issues and limitations in both the short- and long-term. This service will only be available to large players, for instance – this leaves the entirety of smaller LPs without the service. It's also limited to the amount of RUNE that Nine Realms has, and can get access to from the treasury. I'm not sure what the plan is for Nine Realms' funding longer term, but it's not conceivable that the network will become overly dependent on this single, centralised node for attracting and maintaining large chunks of its most-prized asset – liquidity.
Vanir Agents
The latter issue of Nine Realms become an overly dominant capital node is real. However it might not be that big of a deal because if the issue surfaced, the community would likely rise up to create a decentralised alternative if it felt necessary.
I'm more focused on the other opportunity – how do we ensure that non-institutional capital is able to provide assets, be they RUNE or other, such that the economic potential of the network is fully realised?
This post is a genuine call for potential technical solutions. I do have the beginnings of one, which I'm excited about, but it may not be feasible or the simplest fix. But it's the seed of a solution, so I thought I'd share anyway. If you have feedback on this solution or a better solution of your own, please reach out or just lambast me publicly on Twitter lol.
In a nutshell, my solution utilises the recently released Autonomous Economic Agent (AEA) Framework, originally developed by Fetch.AI out of Cambridge, UK. The AEA framework is the first framework created for natively deploying multi-agent systems in crypto. What's a multi-agent system? Multi-agent systems are networks of machine agents which, uniquely, are able to coordinate between themselves to achieve their own goals. Simply put, they're *machine* social networks. Machine social networks which are crafted to exist within and serve their creators by performing specific roles, and honing their abilities based on feedback from their peers.
If you're interested to learn more about the AEA Framework check out this site. I built the site recently to celebrate the framework launching its v1, and to give it its own identity still related, but separate from Fetch.
How Might Vanir Agents Actually Work?
Here's a high-level sketch—
LPs run their own agents — this could be done by a developer themselves, or via a hosted solution, which is likely how the solution would fund itself sustainably.
RUNE LPs seed their agents with RUNE. The agent registers itself as a RUNEProviderService, along with the LP's parameters. Parameters include, amount of RUNE available, external assets it can be pooled with, timing and other parameters under which the agent would pull RUNE out etc.
External LPs seed their agents with other assets, and register themselves as TKNProviderService, along with the same parameters as above.
Agents communicate via Fetch's search & discovery medium, the OEF. When 2 agents with coinciding parameters discover one another, they spin up a multi-sig wallet which deposits RUNE alongside TKN.
Either agent can remove their position assuming the conditions are within the initial parameters set during service registration. If those conditions are not met, liquidity cannot be removed.- Once removed the contract is dissolved.
At that point the agent can re-register funds or just hold them, according to its principal's wishes.
The main advantages of this solution are that it can be deployed at very little cost. It's also beneficial in that it could enable LPs to maximise yield on all assets, even down to relatively small units. This is mostly dependent on the costs incurred by the external asset's chain.
Further down the line you could easily see this being extended to allow users to rebalance their LP positions autonomously based on projections of pool yield, and even to allow individuals to run sophisticated arbitrage bots. These 2 could be even lower cost than the LP matching agents described above, because they could operate entirely within THORChain's upcoming synth-land.
If you think this idea has legs and are interested to get involved with capital or labour, reach out. Ultimately, implementation will require solid Python engineering and I would assume Cosmos SDK, too. Familiarity with the AEA, Midgard and THORChain architecture all pluses.