THORChain bare-metal validator — Part 3: Maya’s Chocolate

6 min readApr 19, 2023

This guide is the Part 3 of the THORChain bare-metal validators series, see Part 1 about building the hardware for this server, and Part 2 about configuring Multi-Node using MicroK8s.

Now that we have our ThorChain bare-metal running and printing Runes, we may be wondering if we could use a similar same setup to run a MayaNode from the Maya Protocol (a friendly fork from ThorChain).

I’ll give out the punch right away: Yes! Not only can we use a similar setup to run Maya Validator, but even better: we can use our current setup and share chains between ThorChain and MAYA!

Maya node is so similar to THORNode that THORnode guide could be used almost as is. In this guide, I’ll go one step further, and display how we can easily add a MAYA Liquidity-Node to an already running THORNode Bare-Metal Setup. At time of writing, given that most chains can be reused from THORChain, resulting in MAYA Node being really lite to add with 12 CPUs — Bifrost (7), Bitcoin (1), Mayanode(4).

NOTE: At this time it is not possible to re-use an existing THORchain validator RPC as thornode-daemon for Maya because TC disabled grpc by default (port 9090).

Note that this Guide is still a work in progress and will be updated in the near future as Maya start churning in Liquidity-Node and my journey continues on the Maya Protocol.

Setup WireGuard Proxy Server

First, we will setup an additional WireGuard Proxy to provide the additional IP used for our MAYA Liquidity-Node.

Follow this as-is from Part 2.

Install MAYAChain Daemon

We will setup a Daemon installation namespace to hold the re-usable Daemons for Maya. I named this namepsace d0. (while c0 is the namespace of thorchain daemon install)

Prepare git folder:

cd ~
mkdir d0
cd d0
git clone https://gitlab.com/mayachain/devops/node-launcher
cd node-launcher
git checkout master
git config pull.rebase true
git config rebase.autoStash true

Change Chaosnet Config to Install only UXTO Chains daemon and re-use Non-UXTO Chains created earlier for THORNode.

cd ~/d0/node-launcher

// Edit Daemons Configs
nano mayanode-stack/chaosnet.yaml

I disabled every daemon except for Thornode and Dash. Maya also call for Ethereum Daemon, but we already have a Ethereum-Daemon in our ThorChain install we can point to.

NET=mainnet TYPE=daemons NAME=d0 make install

Sync Thornode from Snapshot

NET=mainnet TYPE=daemons NAME=d0 make recover-ninerealms

Install MAYAChain Node

For this setup we will create a distinct git working folder for each validator node, the same way as we did for THORChain Node.

Will be using m3 here for Maya node, following the two Thornode n1 and n2.

Prepare git folder:

cd ~
mkdir m3
cd m3
git clone https://gitlab.com/mayachain/devops/node-launcher
cd node-launcher
git checkout master
git config pull.rebase true
git config rebase.autoStash true

Change Chaosnet Config to Install only UXTO Chains daemon and re-use Non-UXTO Chains created earlier for THORNode.

cd ~/m3/node-launcher

// Edit Daemons Configs
nano mayanode-stack/chaosnet.yaml

Disable all chain except bitcoin, by setting the enabled value to false. They are shared between all nodes.

thornode-daemon:
  enabled: false

bitcoin-daemon:
  enabled: true

At time of writing, the only enabled chain would be bitcoin-daemon, because we chose not to share UXTO Chains. As MAYA add more chains, we will have to either run them with each Node, or as Daemon for all chains.

Add the following values at the end of the file to re-use existing daemons:

# point bifrost at shared daemons
bifrost:
  # Eth
  ethereumDaemon:
    mainnet: http://ethereum-daemon.c0.svc.cluster.local:8545
  # Thor
  thorApi: thornode-daemon.d0.svc.cluster.local:1317
  thorDaemon:
    mainnet:
      rpc: http://thornode-daemon.d0.svc.cluster.local:27147
      grpc: thornode-daemon.d0.svc.cluster.local:9090
      grpcTLS: false
  # DASH
  dashDaemon:
    mainnet: dash-daemon.d0.svc.cluster.local:9998

Note here that d0 is the namespace of our maya daemon install, and c0 is our thorchain daemon (for ETH)

Set LoadBalancerIP parameter for Gateway

nano gateway/templates/service.yaml

Add the following values (IP of the WireGuard interface) in the section metadata, annotations:

metadata:
  annotations:
    #MetalLb - WG
    metallb.universe.tf/loadBalancerIPs: 10.10.3.101

Set External Environment IP for Bifrost

nano bifrost/templates/deployment.yaml

Hardcode IP value in the section Env

          env:
            - name: EXTERNAL_IP
              value: "1.2.3.4"
            #  valueFrom:
            #    configMapKeyRef:
            #      name: {{ include "bifrost.fullname" . }}-external-ip
            #      key: externalIP

Set External Environment IP for Mayanode

nano mayanode/templates/deployment.yaml

Hardcode IP value in the section Env

          env:
            - name: EXTERNAL_IP
              value: "1.2.3.4"
            #  valueFrom:
            #    configMapKeyRef:
            #      name: {{ include "thornode.fullname" . }}-external-ip
            #      key: externalIP

Run Make Install to Create Node

NAME=m3 TYPE=validator NET=mainnet make install

Confirm Pods are starting correctly

k9s
// or
kubectl get pods -A

Sync Maya Chain from Snapshot (Optional)

This step will speed the sync of the mayanode, the awscli tool is required to download the snapshot data.

# Install aws-cli (one time) EDIT: NO LONGER REQUIRED
sudo apt install awscli

NAME=m3 TYPE=validator NET=mainnet make recover-maya

Check Status and wait for all chains to Sync

NAME=m3 TYPE=validator NET=mainnet make status

ETH and THOR should instantly indicate 100% because they are pointing to our existing ones. BTC will take about a day to sync to 100%. MAYA takes a few hours. Note that MAYA will indicate 100% before being fully sync, we need to compare the Tip with the actual block height from a dashboard to know the sync progression.

Finish the Validator Configuration as Usual.

The initial bond of a MayaNode is in CACAO, we will need to send a few CACAO to the MayaNode address to complete the configuration (Set IP, Version, etc).

Bonding

Adding this section for bonding maya validator as that task is less straight forward than for a Thorchain node.

At the time of writing, only eldorado allow to send maya deposit with custom memo. We will need a few cacao token to do so.

Create/Import wallet in eldorado

Visit https://www.eldorado.market/wallet, on the top right click the Connect button. To create a new wallet, chose “Create new keystore”, to import an existing wallet, chose “Create keystore from phrase”.

How to Send a deposit with a custom memo

Note: We will need cacao in this wallet before continuing, if we don’t already have some.

To send a transaction with a custom memo, select “SEND” from the left menu.

Under Maya Chain, click the Transfer button at the right of the cacao balance.

In the Transfer prompt, select “Make a deposit with custom memo”

Enter MEMO, and amount 1 (for 1 cacao) and press Send. Clicking anywhere around the prompt will close the prompt (yes it is annoying!)

Get LP Position

If our wallet don’t have a LP position already, we will need to take a small LP position to be able to bond a small number of LP Unit to the node.

Send the following MEMO to create an LP position:

Memo:
+:thor.rune

Send Initial Bond to Node

Memo:
BOND:THOR.RUNE:1:NODEADDRESS

Configure the Node

Now that our node is whitelisted, we can now do the make set-version, set-node-keys, set-ip-address.

make set-version
make set-node-keys
make set-ip-address

Note: If you get the following error, ensure the maya chain is sync to the tip, don’t trust the 100% in make status, compare the tip with an online dashboard, the chain is at over 2M block.
error: Error: rpc error: code = NotFound desc = rpc error: code = NotFound desc = account maya1exxxxxxxxxxxxxxxxx not found: key not found

Make set-ip-address (optional)

If our node is behind a VPN, this is the mayanode variation for set-ip-address.

kubectl exec -it -n m3 deploy/mayanode -- /kube-scripts/set-ip-address.sh "<ProxyExternalIP>"

Whitelist External Bond Provider Wallet

If we want to allow other wallet to bond on our node, we need to whitelist their address.

Memo:
BOND:NODEADDRESS:WALLETADDRESS:5555

Fully bond the node

To send the full bond to our node, we can assign our LP Unit to that node. The following can be ran from the wallet holding the LP Units. The folowing example assign LP Units from the Bitcoin LP.

Memo:
BOND:BTC.BTC:500000000000000:NODEADDRESS

Conclusion

This Guide allows us to add MayaNode Validators in addition to THORNode Validator on our Bare-Metal Server, sharing chain-daemons with both networks.