ThorChain: Pooled Bonds Attracting Node Operators

    Pooled bonds are designed to make it more achievable to reach the minimum required bond for becoming a validator. In this dashboard we will look at if this goal has been reached.

    Loading...
    Loading...
    Loading...

    ThorChain Network

    Purpose

    ThorChain has been created to provide native cross chain liquidity. You can swap native assets across blockchains without needing to wrap / bridge or give surrender custody of your funds.

    It’s as close as you can get to a CEX in DeFi.

    Network Security Model

    In order for this to work liquidity providers need to deposit their liquidity into wallets belonging to ThorChain vaults which live natively on the supported chains. Those vaults are controlled by the ThorChain nodes (or in practise a subset of them).

    In order to ensure Nodes cannot make a profit by stealing the funds in the vault they need to bond a large amount of $RUNE before they can become a validator. This minimum currently stands at 300k $RUNE!

    In case a node steals funds or misbehaves in some other way it’s bond will be slashed ensuring that users can be refunded.

    Loading...
    db_img

    Pooled Nodes

    Goal

    While 300k $RUNE might be an achievable amount for some people, it certainly is not for everyone.

    Increasing the networks node count will increase security and decentralization. Both of which are very critical and important goals for every blockchain!

    In order to allow people who have the technical skills but lack the money to run a node, “pooled bonds” have been introduced.

    How does it work?

    It works by allowing other addresses besides the node operator to bond / unbond funds from a node’s bond.

    These addresses need to be explicity whitelisted by the node operator.

    Using this the 300k $RUNE requirement can be split up between several bond providers.

    The system ensures that each bond provider gets a cut of the nodes earnings and will get refunded when the node is “disbanded”

    Loading...
    Loading...
    db_img

    Basic Node Lifecycle Events

    1. Creation

    This is a transaction with a memo of BOND:node_address.

    The sender of the transaction will be the node operator with the only one having permissions to bond and unbond.

    2. Churn In

    When a node is fully set up and enough bond is provided it can be churned in, a process that swaps out active nodes and allows new ones to get in. It will also do a lot of other tasks in the network like manage vaults on each chain. Those are not relevant here.

    ==Churns happen weekly: Active Nodes update weekly!==

    Additions for pooled nodes

    1.1 Bond provider added

    This can be done at any point in time after the creation, it does not have to be during a churn.

    The transaction uses a BOND:node_address:bond_provider_address memo and is sent by the node operator.

    2.1 Bond provider deposit

    All deposits into a node bond use the memo BOND:node_address. You can distinguish them by looking at the sender address. If it’s not the node operator it is a bond provider.

    The same applies for UNBOND memos.

    Exception being a number between node and provider address

    Definitions

    Pooled vs Classic Validator

    We define a pooled validator as a validator that currently has at least one bond provider whitelisted.

    (==This also means a pooled validator can become a classic validator in the future and the other way around too!==)

    All validators that are not pooled are classic.

    Active Validator

    This is just a node being churned in and producing blocks. A node with sufficient bond will usually not spend much time in non-active state which is why we only concentrate on active ones / ones that were active once.

    All data below only includes nodes that have been churned in at least once!

    Findings

    • After pooled validators were introduced in mid march there were a few created immediately.

    • The total node count barely increased

      • It was already close to its all time high
      • Tons of competition and a lot higher bond minimum than the $300k RUNE
    • In the coming months more and more pooled validators appeared

    • The total node count fell by ~10 nodes from when pooled validators have been introduced

      • it was ~20 validators down in July 2022.
    • Currently around 30% of all validators are pooled

    Weakness of the data

    • While the total number of nodes show that validators used the new features it is a bad indicator of nodes joining because of the feature.

    • The total amount of nodes not increasing after launch is more a sign of existing nodes adding bond providers.

    Time to dig deeper!

    We need more definitions

    Pooled Before

    This class should include nodes that have been created with the help of bond sharing.

    Requirements

    • At least one bond provider must have been added before the first churn in
    • At least one deposit to the bond must have been made by a bond provider before the first churn in
    • Must have been churned in once

    => A validator matching those requirements will always be either categorized as pooled before or (if all bond providers were removed) as classic. It cannot switch to pooled after

    Pooled After

    The exact opposite of pooled before. These are validators that were churned in before they made use of bond pooling.

    Requirements

    • Must have at least one bond provider
    • Must have been churned in once
    • Is not categorized as pooled before

    => Validators in this class can become classic again but will never be able to become pooled before

    Potential improvements

    Switching from pooled before to pooled after

    • If a node used bond pooling before its first churn it will be considered pooled before.

    Maybe it got rid of all bond providers at some point and adds them back later. This makes more sense to be pooled after. Practically this is very rare and unnecessary.

    • Include some metric about the actual deposit sizes.

      This goes beyond scope here as there is another bounty designed to look into this.

    Findings

    • As previously expected we can see that after launch all pooled validators were actually ones created before becoming pooled.
    • While the amount of pooled after validators barely shows any change 2 months after launch onwards the pooled before amount is growing.
      • This is also reflected in the normalized chart:
      • 0% pooled before at launch
      • Mostly steady increase to ~60% now
    Loading...

    Concluding

    • Pooled Bonds were introduced in March 2022

    • They allow whitelisting addresses to add/withdraw to/from a node’s bond securly

    • After launch 12 previously churned in nodes became pooled

      • This number barely increased hovering at 11 now
    • However over time the total amount of pooled nodes increased

    • This is due to new nodes being created that use pooled bonds during their inital setup

      • Which is what the system is intended for
    • In total 21 nodes that are / were using pooled bonds during setup ended up becoming active validators!

      \

    • Given that this is a 20+% increase in total nodes I’d say pooled bonds are a success at brining in new nodes!

    Bonus: All 21 newly attracted nodes!