Weekly Dev Update #70

THORChain Weekly Dev Update for Week 70, 17–23 Nov; Midgard V0.7, Single-sided Liquidity, Tunable Incentive Pendulum, THORNode improvements, RUNEData.info V2, RUNEStake.info V2.3

THORChain

Published in

THORChain

5 min readNov 23, 2020

Summary

The team worked on Chaosnet stability, testnet fixes, and multi-chain tweaks. Midgard was also updated. There are a lot of breaking changes to Multichain now, from events, endpoints and even transaction memos. Developers building on Multichain should track the change log and be prepared to adapt.

Single-sided Liquidity Provision

It is possible today to add liquidity from one side (such as BTCB), but this feature was unwound in order to support liquidity tokens (the liquidity tokens are minted and sent to the user’s thor address). For the case the member does not wish to set up a THORChain wallet or hold RUNE explicitly, they can add from one side. Instead of sending liquidity tokens, the member is allocated liquidity units (internally-accounted and not transferable). They can then “redeem” their liquidity from a secondary transaction later. Note, this does not circumvent paying slip-based fees on entry or exit, and mathematically it is equivalent to doing a swap (before/after). Slip-based fees are necessary to prevent gaming the pool price, and in order to ensure the pool stays 50:50. This is important for security reasons, which is the entire value proposition of THORChain — being able to secure external assets across different chains.

Tunable Incentive Pendulum

Gauntlet was first to identify several months ago that nodes are paid significantly more than LPs in “Steady State”, despite nodes contributing the same amount of capital as LPs. As an example, for 100m RUNE, nodes will bond 67m RUNE, and LPs will supply 33m RUNE to the pools, AND, 33m RUNE worth of assets. So in fact, LPs supply the same amount of “capital” as nodes (67 vs 33 + 33). The THORChain whitepaper argues that nodes have a fixed cost that LPs don’t incur, but LPs incur an impermanent loss (cost) that nodes don’t. The team deferred any adjustment to this to until after reviewing real-world data from Chaosnet. After 3 months, it is clear that the network is always Overbonded (except during the initial rush during the first few weeks). Thus the Incentive Pendulum is paying too much to Nodes. To address this, the team have now added a Tunable Incentive Pendulum, that can be tuned to pay anything from a 50:50 to 67:33 split in steady state, with a single parameter. The next net will launch at 50:50 and will only be adjusted if the network flips to become underbonded most of the time. This will now see more payments to LPs.

The boundary conditions are firm, if 100% is bonded, then 100% should be paid to LPs. If 50% is bonded and 50% is pooled, then the system is about to become categorically insecure, so 100% should be paid to nodes. The curve simply adjust how much is paid in “steady state” (33% pooled).

Multichain Has Diverged Significantly

It is important to remind community developers that there have been significant improvements and optimisations made to the state machine, and a number of wide-spread all-encompassing changes will break interfaces, Midgard, bots and more. A change log will be provided, but devs should allocate at least a day to re-deploy their interface to Multichain.

Releases

Midgard V0.7.0 and V0.7.1 was released with some bug fixes and optimisations. Midgard should be much faster now.

https://gitlab.com/thorchain/midgard/-/releases

THORNode

Some changes made to the Bitcoin testnet to optimise for Bitcoin fee handling (always a pandora’s box). Some changes to the endpoints to remove unused ones, and rename some to be more appropriate. Another big