Introduction

This is Nym’s Operators guide, containing information and setup guides for the various pieces of Nym mixnet infrastructure (mix node, gateway and network requester) and Nyx blockchain validators.

If you are new to Nym and want to learn about the mixnet, explore kickstart options and demos, learn how to integrate with the network, and follow developer tutorials check out the Developer Portal.

If you want to dive deeper into Nym’s architecture, clients, nodes, and SDK examples visit the technical docs.

Popular pages

Binary Information

Node setup and usage guides:

Maintenance, troubleshooting and FAQ

Pre-built Binaries

The Github releases page has pre-built binaries which should work on Ubuntu 20.04 and other Debian-based systems, but at this stage cannot be guaranteed to work everywhere.

If the pre-built binaries don’t work or are unavailable for your system, you will need to build the platform yourself.

Binary Initialisation and Configuration

All Nym binaries must first be made executable and initialised with init before being run.

To make a binary executable, open terminal in the same directory and run:

chmod +x <BINARY_NAME> 
# for example: chmod +x nym-mixnode

The init command is usually where you pass flags specifying configuration arguments such as the gateway you wish to communicate with, the ports you wish your binary to listen on, etc.

The init command will also create the necessary keypairs and configuration files at ~/.nym/<BINARY_TYPE>/<BINARY_ID>/ if these files do not already exist. It will not overwrite existing keypairs if they are present.

You can reconfigure your binaries at any time by editing the config file located at ~/.nym/<BINARY_TYPE>/<BINARY_ID>/config/config.toml and restarting the binary process.

Once you have run init, you can start your binary with the run command, usually only accompanied by the id of the binary that you specified.

This id is never transmitted over the network, and is used to select which local config and key files to use for startup.

Building from Source

Nym runs on Mac OS X, Linux, and Windows. All nodes except the Desktop Wallet and NymConnect on Windows should be considered experimental - it works fine if you’re an app developer but isn’t recommended for running nodes.

Building Nym

Nym has two main codebases:

the Nym platform, written in Rust. This contains all of our code except for the validators.
the Nym validators, written in Go.

This page details how to build the main Nym platform code. If you want to build and run a validator, go here instead.

Prerequisites

Debian/Ubuntu: pkg-config, build-essential, libssl-dev, curl, jq, git

apt install pkg-config build-essential libssl-dev curl jq git

Arch/Manjaro: base-devel

pacman -S base-devel

Mac OS X: pkg-config , brew, openss1, protobuf, curl, git Running the following the script installs Homebrew and the above dependencies:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Rust & cargo >= 1.66

We recommend using the Rust shell script installer. Installing cargo from your package manager (e.g. apt) is not recommended as the packaged versions are usually too old.

If you really don’t want to use the shell script installer, the Rust installation docs contain instructions for many platforms.

Download and build Nym binaries

The following commands will compile binaries into the nym/target/release directory:

rustup update
git clone https://github.com/nymtech/nym.git
cd nym

git reset --hard # in case you made any changes on your branch
git pull # in case you've checked it out before

git checkout master # master branch has the latest release version: `develop` will most likely be incompatible with deployed public networks

cargo build --release # build your binaries with **mainnet** configuration

Quite a bit of stuff gets built. The key working parts are:

mix node: nym-mixnode
gateway node: nym-gateway
websocket client: nym-client
socks5 client: nym-socks5-client
webassembly client: webassembly-client
network requester: nym-network-requester
nym-cli tool: nym-cli

The repository also contains Typescript applications which aren’t built in this process. These can be built by following the instructions on their respective docs pages.

You cannot build from GitHub’s .zip or .tar.gz archive files on the releases page - the Nym build scripts automatically include the current git commit hash in the built binary during compilation, so the build will fail if you use the archive code (which isn’t a Git repository). Check the code out from github using git clone instead.

Node Setup Guides

To setup any type of Nym’s node, start with building Nym’s platform on the machine (VPS) where you want to run the node. Nodes will need to be bond to Nym’s wallet, setup one here.

This section contains setup guides for the following node types:

Preliminary Steps

The Nym mixnode, gateway and network-requester binaries were built in the building nym section. If you haven’t yet built Nym and want to run the code, go there first.

There are a couple of steps that need completing before starting to set up your mix node, gateway or a network requester:

preparing your desktop wallet or CLI wallet.
requisitioning a VPS (Virtual Private Server)

Wallet preparation

Mainnet

Before you initialise and run your mix node, head to our website and download the Nym wallet for your operating system. If pre-compiled binaries for your operating system aren’t available, you can build the wallet yourself with instructions here.

If you don’t already have one, please create a Nym address using the wallet, and fund it with tokens. The minimum amount required to bond a mix node is 100 NYM, but make sure you have a bit more to account for gas costs.

NYM can be purchased via Bity from the wallet itself with BTC or fiat, and is currently present on several exchanges.

Remember that you can only use Cosmos NYM tokens to bond your mix node. You cannot use ERC20 representations of NYM to run a node.

Sandbox testnet

Make sure to download a wallet and create an account as outlined above. Then head to our token faucet and get some tokens to use to bond it.

VPS Hardware Specs

You will need to rent a VPS to run your node on. One key reason for this is that your node must be able to send TCP data using both IPv4 and IPv6 (as other nodes you talk to may use either protocol).

For the moment, we haven’t put a great amount of effort into optimizing concurrency to increase throughput, so don’t bother provisioning a beastly server with multiple cores. This will change when we get a chance to start doing performance optimizations in a more serious way. Sphinx packet decryption is CPU-bound, so once we optimize, more fast cores will be better.

For now, see the below rough specs:

Processors: 2 cores are fine. Get the fastest CPUs you can afford.

For mix node

RAM: Memory requirements are very low - typically a mix node may use only a few hundred MB of RAM.
Disks: The mixnodes require no disk space beyond a few bytes for the configuration files.

For Gateway

RAM: Memory requirements depend on the amount of users your Gateway will be serving at any one time. If you’re just going to be using it yourself, then minimal RAM is fine. If you’re running your Gateway as part of a Service Grant, get something with at least 4GB RAM.
Disks: much like the amount of RAM your Gateway could use, the amount of disk space required will vary with the amount of users your Gateway is serving. If you’re running your Gateway as part of a Service Grant, get something with at least 40GB storage.

Mix Nodes

The Nym mix node binary was built in the building nym section. If you haven’t yet built Nym and want to run the code, go there first.

Any syntax in <> brackets is a user’s unique variable. Exchange with a corresponding name without the <> brackets.

Current version

1.1.30

The nym-mix node binary is currently one point version ahead of the rest of the platform binaries due to a patch applied between releases.

Preliminary steps

Make sure you do the preparation listed in the preliminary steps page before setting up your mix node.

Mix node setup

Now that you have built the codebase, set up your wallet, and have a VPS with the nym-mix node binary, you can set up your mix node with the instructions below.

To begin, move to /target/release directory from which you run the node commands:

cd target/release

Viewing command help

You can check that your binaries are properly compiled with:

./nym-mixnode --help

Which should return a list of all available commands.

Console output

Implementation of a Loopix-based Mixnode

Usage: nym-mixnode [OPTIONS] <COMMAND>

Commands:
  describe           Describe your mixnode and tell people why they should delegate state to you
  init               Initialise the mixnode
  run                Starts the mixnode
  sign               Sign text to prove ownership of this mixnode
  node-details       Show details of this mixnode
  build-info         Show build information of this binary
  completions        Generate shell completions
  generate-fig-spec  Generate Fig specification
  help               Print this message or the help of the given subcommand(s)

Options:
  -c, --config-env-file <CONFIG_ENV_FILE>  Path pointing to an env file that configures the mixnode
      --no-banner                          Flag used for disabling the printed banner in tty
  -h, --help                               Print help
  -V, --version                            Print version

You can also check the various arguments required for individual commands with:

./nym-mixnode <COMMAND> --help

Adding --no-banner startup flag will prevent Nym banner being printed even if run in tty environment.

Initialising your mix node

To check available configuration options for initializing your node use:

./nym-mixnode init --help

Console output

 Initialise the mixnode

Usage: nym-mixnode init [OPTIONS] --id <ID> --host <HOST>

Options:
      --id <ID>                        Id of the mixnode we want to create config for
      --host <HOST>                    The host on which the mixnode will be running
      --mix-port <MIX_PORT>            The port on which the mixnode will be listening for mix
                                       packets
      --verloc-port <VERLOC_PORT>      The port on which the mixnode will be listening for verloc
                                       packets
      --http-api-port <HTTP_API_PORT>  The port on which the mixnode will be listening for http
                                       requests
      --nym-apis <NYM_APIS>            Comma separated list of nym-api endpoints of the validators
  -o, --output <OUTPUT>                [default: text] [possible values: text, json]
  -h, --help                           Print help

Initalise your mix node with the following command, replacing the value of --id with the moniker you wish to give your mix node. Your --host must be publicly routable on the internet in order to mix packets, and can be either an Ipv4 or IPv6 address. The $(curl -4 https://ifconfig.me) command returns your IP automatically using an external service. If you enter your IP address manually, enter it without any port information.

./nym-mixnode init --id <NODE_NAME> --host $(curl -4 https://ifconfig.me)

Console output

.nym-mixnode init --id <YOUR_ID> --host $(curl -4 https://ifconfig.me) --wallet-address <WALLET_ADDRESS>


Initialising mixnode <YOUR_ID>...
Saved mixnet identity and sphinx keypairs
 2023-06-04T08:20:32.862Z INFO  nym_config > Configuration file will be saved to "/home/<USER>/.nym/mixnodes/<YOUR_ID>/config/config.toml"
Saved configuration file to "/home/<USER>/.nym/mixnodes/<YOUR_ID>/config/config.toml"
Mixnode configuration completed.

      _ __  _   _ _ __ ___
     | '_ \| | | | '_ \ _ \
     | | | | |_| | | | | | |
     |_| |_|\__, |_| |_| |_|
            |___/

             (nym-mixnode - version v1.1.29)


Identity Key: DhmUYedPZvhP9MMwXdNpPaqCxxTQgjAg78s2nqtTTiNF","version":"v1.1.29"},"cost_params
Sphinx Key: CfZSy1jRfrfiVi9JYexjFWPqWkKoY72t7NdpWaq37K8Z
Host: 62.240.134.189 (bind address: 62.240.134.189)
Version: v1.1.29
Mix Port: 1789, Verloc port: 1790, Http Port: 8000

The init command will refuse to destroy existing mix node keys.

During the init process you will have the option to change the http_api, verloc and mixnode ports from their default settings. If you wish to change these in the future you can edit their values in the config.toml file created by the initialization process, which is located at ~/.nym/mixnodes/<YOUR_ID>/.

Bonding your mix node

Caution

From v1.1.3, if you unbond your mix node that means you are leaving the mixnet and you will lose all your delegations (permanently). You can join again with the same identity key, however, you will start with no delegations.

Bond via the Desktop wallet (recommended)

You can bond your mix node via the Desktop wallet.

Open your wallet, and head to the Bond page, then select the node type Mixnode and input your node details. Press Next.
Enter the Amount, Operating cost and Profit margin and press Next.
You will be asked to run a the sign command with your gateway - copy and paste the long signature as the value of --contract-msg and run it.

./nym-mixnode sign --id <YOUR_ID> --contract-msg <PAYLOAD_GENERATED_BY_THE_WALLET>

It will look something like this:

Console output

./nym-mixnode sign --id upgrade_test --contract-msg 22Z9wt4PyiBCbMiErxj5bBa4VCCFsjNawZ1KnLyMeV9pMUQGyksRVANbXHjWndMUaXNRnAuEVJW6UCxpRJwZe788hDt4sicsrv7iAXRajEq19cWPVybbUqgeo76wbXbCbRdg1FvVKgYZGZZp8D72p5zWhKSBRD44qgCrqzfV1SkiFEhsvcLUvZATdLRocAUL75KmWivyRiQjCE1XYEWyRH9yvRYn4TymWwrKVDtEB63zhHjATN4QEi2E5qSrSbBcmmqatXsKakbgSbQoLsYygcHx7tkwbQ2HDYzeiKP1t16Rhcjn6Ftc2FuXUNnTcibk2LQ1hiqu3FAq31bHUbzn2wiaPfm4RgqTwGM4eqnjBofwR3251wQSxbYwKUYwGsrkweRcoPuEaovApR9R19oJ7GVG5BrKmFwZWX3XFVuECe8vt1x9MY7DbQ3xhAapsHhThUmzN6JPPU4qbQ3PdMt3YVWy6oRhap97ma2dPMBaidebfgLJizpRU3Yu7mtb6E8vgi5Xnehrgtd35gitoJqJUY5sB1p6TDPd6vk3MVU1zqusrke7Lvrud4xKfCLqp672Bj9eGb2wPwow643CpHuMkhigfSWsv9jDq13d75EGTEiprC2UmWTzCJWHrDH7ka68DZJ5XXAW67DBewu7KUm1jrJkNs55vS83SWwm5RjzQLVhscdtCH1Bamec6uZoFBNVzjs21o7ax2WHDghJpGMxFi6dmdMCZpqn618t4

      _ __  _   _ _ __ ___
     | '_ \| | | | '_ \ _ \
     | | | | |_| | | | | | |
     |_| |_|\__, |_| |_| |_|
            |___/

             (nym-mixnode - version v1.1.29)


>>> attempting to sign 22Z9wt4PyiBCbMiErxj5bBa4VCCFsjNawZ1KnLyMeV9pMUQGyksRVANbXHjWndMUaXNRnAuEVJW6UCxpRJwZe788hDt4sicsrv7iAXRajEq19cWPVybbUqgeo76wbXbCbRdg1FvVKgYZGZZp8D72p5zWhKSBRD44qgCrqzfV1SkiFEhsvcLUvZATdLRocAUL75KmWivyRiQjCE1XYEWyRH9yvRYn4TymWwrKVDtEB63zhHjATN4QEi2E5qSrSbBcmmqatXsKakbgSbQoLsYygcHx7tkwbQ2HDYzeiKP1t16Rhcjn6Ftc2FuXUNnTcibk2LQ1hiqu3FAq31bHUbzn2wiaPfm4RgqTwGM4eqnjBofwR3251wQSxbYwKUYwGsrkweRcoPuEaovApR9R19oJ7GVG5BrKmFwZWX3XFVuECe8vt1x9MY7DbQ3xhAapsHhThUmzN6JPPU4qbQ3PdMt3YVWy6oRhap97ma2dPMBaidebfgLJizpRU3Yu7mtb6E8vgi5Xnehrgtd35gitoJqJUY5sB1p6TDPd6vk3MVU1zqusrke7Lvrud4xKfCLqp672Bj9eGb2wPwow643CpHuMkhigfSWsv9jDq13d75EGTEiprC2UmWTzCJWHrDH7ka68DZJ5XXAW67DBewu7KUm1jrJkNs55vS83SWwm5RjzQLVhscdtCH1Bamec6uZoFBNVzjs21o7ax2WHDghJpGMxFi6dmdMCZpqn618t4
>>> decoding the message...
>>> message to sign: {"nonce":0,"algorithm":"ed25519","message_type":"mixnode-bonding","content":{"sender":"n1eufxdlgt0puwrwptgjfqne8pj4nhy2u5ft62uq","proxy":null,"funds":[{"denom":"unym","amount":"100000000"}],"data":{"mix_node":{"host":"62.240.134.189","mix_port":1789,"verloc_port":1790,"http_api_port":8000,"sphinx_key":"CfZSy1jRfrfiVi9JYexjFWPqWkKoY72t7NdpWaq37K8Z","identity_key":"DhmUYedPZvhP9MMwXdNpPaqCxxTQgjAg78s2nqtTTiNF","version":"1.1.14"},"cost_params":{"profit_margin_percent":"0.1","interval_operating_cost":{"denom":"unym","amount":"40000000"}}}}}

Copy the resulting signature:

>>> The base58-encoded signature is:
2GbKcZVKFdpi3sR9xoJWzwPuGdj3bvd7yDtDYVoKfbTWdpjqAeU8KS5bSftD5giVLJC3gZiCg2kmEjNG5jkdjKUt

And paste it into the wallet nodal, press Next and confirm the transaction.

Paste Signature

Your node will now be bonded and ready to mix at the beginning of the next epoch (at most 1 hour).

You are asked to sign a transaction on bonding so that the mixnet smart contract is able to map your nym address to your node. This allows us to create a nonce for each account and defend against replay attacks.

Bond via the CLI (power users)

If you want to bond your mix node via the CLI, then check out the relevant section in the Nym CLI docs.

Running your mix node

Now you’ve bonded your mix node, run it with:

./nym-mixnode run --id <YOUR_ID>

If everything worked, you’ll see your node running on the either the Sandbox testnet network explorer or the mainnet network explorer, depending on which network you’re running.

Note that your node’s public identity key is displayed during startup, you can use it to identify your node in the list.

Have a look at the saved configuration files in $HOME/.nym/mixnodes/ to see more configuration options.

Node Description (optional)

In order to easily identify your node via human-readable information later on in the development of the testnet when delegated staking is implemented, you can describe your mix node with the following command:

./nym-mixnode describe --id <YOUR_ID>

Node description is a short text that describes your node. It is displayed in the ./nym-mixnode list command and in the ./nym-mixnode node-details --id <YOUR_ID> command. It also shows up in the node explorer to let people know what your node is about and link to your website.

You can set your node description, by creating a file called description.toml and put it in the same directory as your config.toml file (~/.nym/mixnodes/<YOUR_ID>/description.toml). The file should look like this example:

name = "Winston Smith"
description = "I am the Sphinx"
link = "https://nymtech.net"
location = "Giza, Egypt"

Remember to restart your mix node process in order for the new description to be propagated.

Node Families

Node family involves setting up a group of mix nodes that work together to provide greater privacy and security for network communications. This is achieved by having the nodes in the family share information and routes, creating a decentralized network that makes it difficult for third parties to monitor or track communication traffic.

Create a Node Family

To create a Node family, you will need to install and configure multiple mix nodes, and then use the CLI to link them together into a family. Once your Node family is up and running, you can use it to route your network traffic through a series of nodes, obscuring the original source and destination of the communication.

You can use either nym-cli which can be downloaded from the release page or compiling nyxd.

Change directory by cd <PATH>/<TO>/<THE>/<RELEASE> and run the following on the family head to obtain the signature for the member:

./nym-mixnode sign --id <YOUR_ID> --text <TEXT>

Console output

Using nym-cli:

--mnemonic is the mnemonic of the member wanting to be the head of family.

/nym-cli cosmwasm execute <WALLET_ADDRESS> '{"create_family": {"signature": "<base58-encoded-signature>","family_head": "<TEXT>","owner_signature":"<NODE_OWNER_SIGNATURE>","label": "<NODE_LABEL>"}}' --mnemonic <MNEMONIC_FROM_THE_NODE_TO_THE_HEAD>

Using nyxd:

--from is mnemonic of the member wanting to join the family.

./nyxd tx wasm execute ${MIXNET-CONTRACT} '{"join_family": {"signature": "<base58-encoded-signature>","family_head": "<TEXT>"}}' --node ${VALIDATOR-ENDPOINT} --from mix1 --chain-id nyx --gas-prices 0.025unym --gas auto --gas-adjustment 1.3 -y -b block

To get the node owner signature, use:

./nym-mixnode node-details --id <NODE_ID>

Joining a Node Family

Change directory by cd <PATH>/<TO>/<THE>/<RELEASE> and run the following on the family head to obtain the signature for the member:

./nym-mixnode sign --id <YOUR_ID> --text <TEXT>

Console output

Using nym-cli:

./nym-cli cosmwasm execute <WALLET_ADDRESS> '{"join_family": {"signature": "<base58-encoded-signature>","family_head": "<TEXT>","owner_signautre": "<OWNER_SIGNATURE_FROM_NODE_TO_JOIN>", "label":"<NODE_TO_JOIN_LABEL>"}}'  --mnemonic <MNEMONIC_FROM_NODE_TO_JOIN>

Using nyxd:

./nyxd tx wasm execute ${MIXNET-CONTRACT} '{"join_family": {"signature": "<base58-encoded-signature>","family_head": "<TEXT>"}}' --node ${VALIDATOR-ENDPOINT} --from mix1 --chain-id nyx --gas-prices 0.025unym --gas auto --gas-adjustment 1.3 -y -b block

To get the node owner signature, use:

./nym-mixnode node-details --id <NODE_ID>

Leaving a family

If wanting to leave, run the same initial command as above, followed by:

Using nym-cli:

./nym-cli cosmwasm execute <WALLET_ADDRESS> '{"leave_family": {"signature": "<base58-encoded-signature>","family_head": "<TEXT>","owner_signautre": "<OWNER_IGNATURE_FROM_NODE_TO_LEAVE>"}}'  --mnemonic <MNEMONIC_FROM_NODE_TO_LEAVE>

Using nyxd:

./nyxd tx wasm execute ${MIXNET-CONTRACT} '{"join_family": {"signature": "<base58-encoded-signature>","family_head": "<TEXT>"}}' --node ${VALIDATOR-ENDPOINT} --from mix1 --chain-id nyx --gas-prices 0.025unym --gas auto --gas-adjustment 1.3 -y -b block

Checking that your node is mixing correctly

Network explorers

Once you’ve started your mix node and it connects to the validator, your node will automatically show up in the ‘Mix nodes’ section of either the Nym Network Explorers:

Enter your identity key to find your node. There are numerous statistics about your node on that page that are useful for checking your up-time history, packets mixed, and any delegations your node may have.

There are also 2 community explorers which have been created by Nodes Guru:

For more details see Troubleshooting FAQ

Maintenance

For mix node upgrade, firewall setup, port configuration, API endpoints, VPS suggestions, automation and more, see the maintenance page

Gateways

The Nym gateway was built in the building nym section. If you haven’t yet built Nym and want to run the code, go there first.

Any syntax in <> brackets is a user’s unique variable. Exchange with a corresponding name without the <> brackets.

Current version

1.1.29

Preliminary steps

Make sure you do the preparation listed in the preliminary steps page before setting up your gateway.

Gateway setup

Now that you have built the codebase, set up your wallet, and have a VPS with the nym-gateway binary, you can set up your gateway with the instructions below.

To begin, move to /target/release directory from which you run the node commands:

cd target/release

Viewing command help

You can check that your binaries are properly compiled with:

./nym-gateway --help

Console output

Implementation of the Nym Mixnet Gateway

Usage: nym-gateway [OPTIONS] <COMMAND>

Commands:
  init               Initialise the gateway
  node-details       Show details of this gateway
  run                Starts the gateway
  sign               Sign text to prove ownership of this mixnode
  build-info         Show build information of this binary
  completions        Generate shell completions
  generate-fig-spec  Generate Fig specification
  help               Print this message or the help of the given subcommand(s)

Options:
  -c, --config-env-file <CONFIG_ENV_FILE>  Path pointing to an env file that configures the gateway
      --no-banner                          Flag used for disabling the printed banner in tty
  -h, --help                               Print help
  -V, --version                            Print version

You can also check the various arguments required for individual commands with:

./nym-gateway <COMMAND> --help

Adding --no-banner startup flag will prevent Nym banner being printed even if run in tty environment.

Initialising your gateway

To check available configuration options use:

 ./nym-gateway init --help

Console output

Initialise the gateway

Usage: nym-gateway init [OPTIONS] --id <ID> --host <HOST>

Options:
      --id <ID>
          Id of the gateway we want to create config for
      --host <HOST>
          The custom host on which the gateway will be running for receiving sphinx packets
      --mix-port <MIX_PORT>
          The port on which the gateway will be listening for sphinx packets
      --clients-port <CLIENTS_PORT>
          The port on which the gateway will be listening for clients gateway-requests
      --datastore <DATASTORE>
          Path to sqlite database containing all gateway persistent data
      --nym-apis <NYM_APIS>
          Comma separated list of endpoints of nym APIs
      --mnemonic <MNEMONIC>
          Cosmos wallet mnemonic needed for double spending protection
      --enabled-statistics <ENABLED_STATISTICS>
          Enable/disable gateway anonymized statistics that get sent to a statistics aggregator
          server [possible values: true, false]
      --statistics-service-url <STATISTICS_SERVICE_URL>
          URL where a statistics aggregator is running. The default value is a Nym aggregator server
  -o, --output <OUTPUT>
          [default: text] [possible values: text, json]
  -h, --help
          Print help

The following command returns a gateway on your current IP with the id of supergateway:

./nym-gateway init --id supergateway --host $(curl ifconfig.me) --wallet-address n1eufxdlgt0puwrwptgjfqne8pj4nhy2u5ft62uq

Console output

The $(curl ifconfig.me) command above returns your IP automatically using an external service. Alternatively, you can enter your IP manually if you wish. If you do this, remember to enter your IP without any port information.

Bonding your gateway

Via the Desktop wallet

You can bond your gateway via the Desktop wallet.

Open your wallet, and head to the Bonding page, then select the node type Gateway and input your node details (Location format is , ). Press Next
Enter the Amount, Operating cost and press Next.
You will be asked to run a the sign command with your gateway - copy and paste the long signature as the value of --contract-msg and run it.

./nym-mixnode sign --id <YOUR_ID> --contract-msg <PAYLOAD_GENERATED_BY_THE_WALLET>

It will look something like this:

Console output

./nym-gateway sign --id upgrade_test --contract-msg 2Mf8xYytgEeyJke9LA7TjhHoGQWNBEfgHZtTyy2krFJfGHSiqy7FLgTnauSkQepCZTqKN5Yfi34JQCuog9k6FGA2EjsdpNGAWHZiuUGDipyJ6UksNKRxnFKhYW7ri4MRduyZwbR98y5fQMLAwHne1Tjm9cXYCn8McfigNt77WAYwBk5bRRKmC34BJMmWcAxphcLES2v9RdSR68tkHSpy2C8STfdmAQs3tZg8bJS5Qa8pQdqx14TnfQAPLk3QYCynfUJvgcQTrg29aqCasceGRpKdQ3Tbn81MLXAGAs7JLBbiMEAhCezAr2kEN8kET1q54zXtKz6znTPgeTZoSbP8rzf4k2JKHZYWrHYF9JriXepuZTnyxAKAxvGFPBk8Z6KAQi33NRQkwd7MPyttatHna6kG9x7knffV6ebGzgRBf7NV27LurH8x4L1uUXwm1v1UYCA1WSBQ9Pp2JW69k5v5v7G9gBy8RUcZnMbeL26Qqb8WkuGcmuHhaFfoqSfV7PRHPpPT4M8uRqUyR4bjUtSJJM1yh6QSeZk9BEazzoJqPeYeGoiFDZ3LMj2jesbJweQR4caaYuRczK92UGSSqu9zBKmE45a


      _ __  _   _ _ __ ___
     | '_ \| | | | '_ \ _ \
     | | | | |_| | | | | | |
     |_| |_|\__, |_| |_| |_|
            |___/

             (nym-gateway - version v1.1.29)  


>>> attempting to sign 2Mf8xYytgEeyJke9LA7TjhHoGQWNBEfgHZtTyy2krFJfGHSiqy7FLgTnauSkQepCZTqKN5Yfi34JQCuog9k6FGA2EjsdpNGAWHZiuUGDipyJ6UksNKRxnFKhYW7ri4MRduyZwbR98y5fQMLAwHne1Tjm9cXYCn8McfigNt77WAYwBk5bRRKmC34BJMmWcAxphcLES2v9RdSR68tkHSpy2C8STfdmAQs3tZg8bJS5Qa8pQdqx14TnfQAPLk3QYCynfUJvgcQTrg29aqCasceGRpKdQ3Tbn81MLXAGAs7JLBbiMEAhCezAr2kEN8kET1q54zXtKz6znTPgeTZoSbP8rzf4k2JKHZYWrHYF9JriXepuZTnyxAKAxvGFPBk8Z6KAQi33NRQkwd7MPyttatHna6kG9x7knffV6ebGzgRBf7NV27LurH8x4L1uUXwm1v1UYCA1WSBQ9Pp2JW69k5v5v7G9gBy8RUcZnMbeL26Qqb8WkuGcmuHhaFfoqSfV7PRHPpPT4M8uRqUyR4bjUtSJJM1yh6QSeZk9BEazzoJqPeYeGoiFDZ3LMj2jesbJweQR4caaYuRczK92UGSSqu9zBKmE45a
>>> decoding the message...
>>> message to sign: {"nonce":0,"algorithm":"ed25519","message_type":"gateway-bonding","content":{"sender":"n1ewmme88q22l8syvgshqma02jv0vqrug9zq9dy8","proxy":null,"funds":[{"denom":"unym","amount":"100000000"}],"data":{"gateway":{"host":"62.240.134.189","mix_port":1789,"clients_port":9000,"location":"62.240.134.189","sphinx_key":"FKbuN7mPdoCG9jA3CkAfXxC5X4rHhqeMVtmfRtJ3cFZd","identity_key":"3RoAhR8gEdfBETMjm2vbMFzKddxXDdE9ygBAnJHWqSzD","version":"1.1.13"}}}}

Copy the resulting signature:

>>> The base58-encoded signature is:
2SPDjLjX4b6XEtkgG7yD8Znsb1xycL1edFvRK4JcVnPsM9k6HXEUUeVS6rswRiYxoj1bMgiRKyPDwiksiuyxu8Xi

And paste it into the wallet nodal, press Next and confirm the transaction.

Paste Signature

Your gateway is now bonded.

You are asked to sign a transaction on bonding so that the mixnet smart contract is able to map your nym address to your node. This allows us to create a nonce for each account and defend against replay attacks.

Via the CLI (power users)

If you want to bond your mix node via the CLI, then check out the relevant section in the Nym CLI docs.

Running your gateway

The run command starts the gateway:

./nym-gateway run --id <YOUR_ID>

Maintenance

For gateway upgrade, firewall setup, port configuration, API endpoints, VPS suggestions, automation and more, see the maintenance page

Network Requesters

The Nym gateway was built in the building nym section. If you haven’t yet built Nym and want to run the code, go there first.

Any syntax in <> brackets is a user’s unique variable. Exchange with a corresponding name without the <> brackets.

Current version

1.1.29

Preliminary steps

Make sure you do the preparation listed in the preliminary steps page before setting up your network requester.

Network Requester Whitelist

If you have access to a server, you can run the network requester, which allows Nym users to send outbound requests from their local machine through the mixnet to a server, which then makes the request on their behalf, shielding them (and their metadata) from clearnet, untrusted and unknown infrastructure, such as email or message client servers.

By default the network requester is not an open proxy (although it can be used as one). It uses a file called allowed.list (located in ~/.nym/service-providers/network-requester/<NETWORK-REQUESTER-ID>/) as a whitelist for outbound requests.

Any request to a URL which is not on this list will be blocked.

On startup, if this file is not present, the requester will grab the default whitelist from Nym’s default list automatically.

This default whitelist is useful for knowing that the majority of Network requesters are able to support certain apps ‘out of the box’.

Operators of a network requester are of course free to edit this file and add the URLs of services they wish to support to it! You can find instructions below on adding your own URLs or IPs to this list.

The domains and IPs on the default whitelist can be broken down by application as follows:

# Keybase
keybaseapi.com
s3.amazonaws.com
amazonaws.com
twitter.com
keybase.io
gist.githubusercontent.com

# Used to for uptime healthcheck (see the section on testing your requester below for more)
nymtech.net

# Blockstream Green Bitcoin Wallet
blockstream.info
blockstream.com
greenaddress.it

# Electrum Bitcoin Wallet
electrum.org

# Helios Ethereum Client
alchemy.com
lightclientdata.org
p2pify.com

# Telegram - these IPs have been copied from https://core.telegram.org/resources/cidr.txt as Telegram does
# not seem to route by domain as the other apps on this list do
91.108.56.0/22
91.108.4.0/22
91.108.8.0/22
91.108.16.0/22
91.108.12.0/22
149.154.160.0/20
91.105.192.0/23
91.108.20.0/22
185.76.151.0/24
2001:b28:f23d::/48
2001:b28:f23f::/48
2001:67c:4e8::/48
2001:b28:f23c::/48
2a0a:f280::/32

# nym matrix server
nymtech.chat

# generic matrix server backends
vector.im
matrix.org

# monero desktop - mainnet
212.83.175.67
212.83.172.165
176.9.0.187
88.198.163.90
95.217.25.101
136.244.105.131
104.238.221.81
66.85.74.134
88.99.173.38
51.79.173.165

# monero desktop - stagenet
162.210.173.150
176.9.0.187
88.99.173.38
51.79.173.165

# alephium 
alephium.org

Network Requester Directory

You can find a list of Network requesters running the default whitelist in the explorer. This list comprises of the NRs running as infrastructure for NymConnect.

We are currently working on a smart-contract based solution more in line with how Mix nodes and Gateways announce themselves to the network.

Viewing command help

To begin, move to /target/release directory from which you run the node commands:

cd target/release

The ./nym-network-requester --help command can be used to show a list of available parameters.

Console output

Usage: nym-network-requester [OPTIONS] <COMMAND>

Commands:
  init               Initialize a network-requester. Do this first!
  run                Run the network requester with the provided configuration and optionally
                         override parameters
  sign               Sign to prove ownership of this network requester
  build-info         Show build information of this binary
  completions        Generate shell completions
  generate-fig-spec  Generate Fig specification
  help               Print this message or the help of the given subcommand(s)

Options:
  -c, --config-env-file <CONFIG_ENV_FILE>  Path pointing to an env file that configures the client
      --no-banner                          Flag used for disabling the printed banner in tty
  -h, --help                               Print help
  -V, --version                            Print version

You can check the required parameters for available commands by running:

./nym-network-requester <COMMAND> --help

Adding --no-banner startup flag will prevent Nym banner being printed even if run in tty environment.

Initializing and running your network requester

The network-requester needs to be initialized before it can be run. This is required for the embedded nym-client to connect successfully to the mixnet. We want to specify an <ID> using the --id command and give it a value of your choice. The following command will achieve that:

 ./nym-network-requester init --id <YOUR_ID>

In the following we used example.

Console output

Version: 1.1.29
ID: example
Identity key: Gv9SvghEpAqZQGkacybW17GTvSyXFfoRVjbmJEbmFn7e
Encryption: AGpyu1c3M6sEBeUmfHLRz2o8A88w2dtRKZ45VD4ts1xS
Gateway ID: EmksoVk8Q7RZZH8atvZspDShD7Ekq6vDPnjK4LCQ7DUv
Gateway: ws://82.216.163.131:9000
Address of this network-requester: Gv9SvghEpAqZQGkacybW17GTvSyXFfoRVjbmJEbmFn7e.AGpyu1c3M6sEBeUmfHLRz2o8A88w2dtRKZ45VD4ts1xS@EmksoVk8Q7RZZH8atvZspDShD7Ekq6vDPnjK4LCQ7DUv

Now that we have initialized our network-requester, we can start it with the following command:

 ./nym-network-requester run --id <YOUR_ID>

Maintenance

For network requester upgrade (including an upgrade from <v1.1.9 to >= v1.1.10), firewall setup, port configuration, API endpoints, VPS suggestions, automation and more, see the maintenance page.

Upgrading to >= v1.1.10 from <v1.1.9

In the previous version of the network-requester, users were required to run a nym-client along side it to function. As of v1.1.10, the network-requester now has a nym client embedded into the binary, so it can run standalone.

If you are running an existing network requester registered with nym-connect, upgrading requires you move your old keys over to the new network requester configuration. We suggest following these instructions carefully to ensure a smooth transition.

Initiate the new network requester:

nym-network-requester init --id mynetworkrequester

Copy the old keys from your client to the network-requester configuration that was created above:

cp -vr ~/.nym/clients/myoldclient/data/* ~/.nym/service-providers/network-requester/mynetworkrequester/data

Edit the gateway configuration to match what you used on your client. Specifically, edit the configuration file at:

~/.nym/service-providers/network-requester/mynetworkrequester/config/config.toml

Ensure that the fields gateway_id, gateway_owner, gateway_listener in the new config match those in the old client config at:

~/.nym/clients/myoldclient/config/config.toml

Automating your network requester with systemd

Stop the running process with CTRL-C, and create a service file for the requester as we did with our client instance previously at /etc/systemd/system/nym-network-requester.service:

[Unit]
Description=Nym Network Requester 
StartLimitInterval=350
StartLimitBurst=10

[Service]
User=nym # replace this with whatever user you wish
LimitNOFILE=65536
# remember to add the `--enable-statistics` flag if running as part of a service grant and check the path to your nym-network-requester binary
ExecStart=/home/nym/nym-network-requester run --id <your_id>
KillSignal=SIGINT
Restart=on-failure
RestartSec=30

[Install]
WantedBy=multi-user.target

Now enable and start your requester:

systemctl enable nym-network-requester.service
systemctl start nym-network-requester.service

# you can always check your requester has succesfully started with:
systemctl status nym-network-requester.service

VPS Setup

Configure your firewall

Although your requester is now ready to receive traffic, your server may not be - the following commands will allow you to set up a properly configured firewall using ufw:

# check if you have ufw installed
ufw version
# if it is not installed, install with
sudo apt install ufw -y
# enable ufw
sudo ufw enable
# check the status of the firewall
sudo ufw status

Finally open your requester’s ssh port to incoming administration connections:

sudo ufw allow 22/tcp
# check the status of the firewall
sudo ufw status

release/v1.1.27:documentation/docs/src/nodes/network-requester-setup.md 85ab634d9c1f1f54073c97a133c83e645a0a3f41

Using your network requester

The next thing to do is use your requester, share its address with friends (or whoever you want to help privacy-enhance their app traffic). Is this safe to do? If it was an open proxy, this would be unsafe, because any Nym user could make network requests to any system on the internet.

To make things a bit less stressful for administrators, the Network Requester drops all incoming requests by default. In order for it to make requests, you need to add specific domains to the allowed.list file at $HOME/.nym/service-providers/network-requester/allowed.list.

Global vs local allow lists

Your Network Requester will check for a domain against 2 lists before allowing traffic through for a particular domain or IP.

The first list is the default list on the nymtech.net server. Your Requester will not check against this list every time, but instead will keep a record of accepted domains in memory.
The second is the local allowed.list file.

Supporting custom domains with your network requester

It is easy to add new domains and services to your network requester - simply find out which endpoints (both URLs and raw IP addresses are supported) you need to whitelist, and then add these endpoints to your allowed.list.

In order to keep things more organised, you can now use comments in the allow.list like the example at the top of this page.

How to go about this? Have a look in your nym-network-requester config directory:

ls -lt $HOME/.nym/service-providers/network-requester/*/data | grep "list"

# returns: allowed.list  unknown.list

We already know that allowed.list is what lets requests go through. All unknown requests are logged to unknown.list. If you want to try using a new client type, just start the new application, point it at your local socks client (configured to use your remote nym-network-requester), and keep copying URLs from unknown.list into allowed.list (it may take multiple tries until you get all of them, depending on the complexity of the application). Make sure to restart your network requester!

If you are adding custom domains, please note that whilst they may appear in the logs of your network-requester as something like api-0.core.keybaseapi.com:443, you only need to include the main domain name, in this instance keybaseapi.com

Running an open proxy

If you really want to run an open proxy, perhaps for testing purposes for your own use or among a small group of trusted friends, it is possible to do so. You can disable network checks by passing the flag --open-proxy flag when you run it. If you run in this configuration, you do so at your own risk.

Testing your network requester

Make sure nymtech.net is in your allowed.list (remember to restart your network requester).
Ensure that your network-requester is initialized and running.
In another terminal window, run the following:

curl -x socks5h://localhost:1080 https://nymtech.net/.wellknown/connect/healthcheck.json

This command should return the following:

{ "status": "ok" }

Ports

Requester port reference

All network-requester-specific port configuration can be found in $HOME/.nym/service-providers/network-requester/<YOUR_ID>/config/config.toml. If you do edit any port configs, remember to restart your client and requester processes.

Validators

Nym has two main codebases:

the Nym platform, written in Rust. This contains all of our code except for the validators.

the Nym validators, written in Go.

The validator is built using Cosmos SDK and Tendermint, with a CosmWasm smart contract controlling the directory service, node bonding, and delegated mixnet staking.

We are currently working towards building up a closed set of reputable validators. You can ask us for coins to get in, but please don’t be offended if we say no - validators are part of our system’s core security and we are starting out with people we already know or who have a solid reputation.

Building your validator

Any syntax in <> brackets is a user’s unique variable. Exchange it with a corresponding name without the <> brackets.

Prerequisites

`git`, `gcc`, `jq`

Debian-based systems:

apt install git build-essential jq

# optional additional manual pages can be installed with:
apt-get install manpages-dev

Arch-based systems: Install git, gcc and jq with the following:

pacman -S git gcc jq

`Go`

Go can be installed via the following commands (taken from the Go Download and install page):

# First remove any existing old Go installation and extract the archive you just downloaded into /usr/local: 
# You may need to run the command as root or through sudo
rm -rf /usr/local/go && tar -C /usr/local -xzf go1.20.6.linux-amd64.tar.gz

# Add /usr/local/go/bin to the PATH environment variable
export PATH=$PATH:/usr/local/go/bin
source $HOME/.profile

Verify Go is installed with:

go version
# Should return something like:
go version go1.20.4 linux/amd64

Download a precompiled validator binary

You can find pre-compiled binaries for Ubuntu 22.04 and 20.04 here.

There are seperate releases for Mainnet and the Sandbox testnet - make sure to download the correct binary to avoid bech32Prefix mismatches.

Manually compiling your validator binary

The codebase for the Nyx validators can be found here.

The validator binary can be compiled by running the following commands:

git clone https://github.com/nymtech/nyxd.git
cd nyxd
git checkout release/<NYXD_VERSION>

# Mainnet
make build

# Sandbox testnet
BECH32_PREFIX=nymt make build

At this point, you will have a copy of the nyxd binary in your build/ directory. Test that it’s compiled properly by running:

./build/nyxd

You should see a similar help menu printed to you:

Console output

Wasm Daemon (server)

Usage:
  nyxd [command]

Available Commands:
  add-genesis-account      Add a genesis account to genesis.json
  add-wasm-genesis-message Wasm genesis subcommands
  collect-gentxs           Collect genesis txs and output a genesis.json file
  config                   Create or query an application CLI configuration file
  debug                    Tool for helping with debugging your application
  export                   Export state to JSON
  gentx                    Generate a genesis tx carrying a self delegation
  help                     Help about any command
  init                     Initialize private validator, p2p, genesis, and application configuration files
  keys                     Manage your application's keys
  query                    Querying subcommands
  rollback                 rollback cosmos-sdk and tendermint state by one height
  start                    Run the full node
  status                   Query remote node for status
  tendermint               Tendermint subcommands
  tx                       Transactions subcommands
  validate-genesis         validates the genesis file at the default location or at the location passed as an arg
  version                  Print the application binary version information

Flags:
  -h, --help                help for nyxd
      --home string         directory for config and data (default "/home/willow/.nyxd")
      --log_format string   The logging format (json|plain) (default "plain")
      --log_level string    The logging level (trace|debug|info|warn|error|fatal|panic) (default "info")
      --trace               print out full stack trace on errors

Use "nyxd [command] --help" for more information about a command.

Linking `nyxd` to `libwasmvm.so`

libwasmvm.so is the wasm virtual machine which is needed to execute smart contracts in v0.26.1. This file is renamed in libwasmvm.x86_64.so in v0.31.1.

If you downloaded your nyxd binary from Github, you will have seen this file when un-tar-ing the .tar.gz file from the releases page.

If you are seeing an error concerning this file when trying to run nyxd, then you need to move the libwasmvm.so file to correct location.

Simply cp or mv that file to /lib/x86_64-linux-gnu/ and re-run nyxd.

Adding `nyxd` to your `$PATH`

You’ll need to set LD_LIBRARY_PATH in your user’s ~/.bashrc or ~/.zshrc file (depends on the terminal you use), and add that to our path. Replace /home/<USER>/<PATH-TO-NYM>/binaries in the command below to the locations of nyxd and libwasmvm.so and run it. If you have compiled these on the server, they will be in the build/ folder:

NYX_BINARIES=/home/<USER>/<PATH-TO-VALIDATOR>/<BINARY>

# if you are using another shell like zsh replace '.bashrc' with the relevant config file
echo 'export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:'NYX_BINARIES >> ~/.bashrc
echo 'export PATH=$PATH:'${NYX_BINARIES} >> ~/.bashrc
source ~/.bashrc

Test everything worked:

nyxd

This should return the regular help menu:

Console output

Wasm Daemon (server)

Usage:
  nyxd [command]

Available Commands:
  add-genesis-account      Add a genesis account to genesis.json
  add-wasm-genesis-message Wasm genesis subcommands
  collect-gentxs           Collect genesis txs and output a genesis.json file
  config                   Create or query an application CLI configuration file
  debug                    Tool for helping with debugging your application
  export                   Export state to JSON
  gentx                    Generate a genesis tx carrying a self delegation
  help                     Help about any command
  init                     Initialize private validator, p2p, genesis, and application configuration files
  keys                     Manage your application's keys
  query                    Querying subcommands
  rollback                 rollback cosmos-sdk and tendermint state by one height
  start                    Run the full node
  status                   Query remote node for status
  tendermint               Tendermint subcommands
  tx                       Transactions subcommands
  validate-genesis         validates the genesis file at the default location or at the location passed as an arg
  version                  Print the application binary version information

Flags:
  -h, --help                help for nyxd
      --home string         directory for config and data (default "/home/willow/.nyxd")
      --log_format string   The logging format (json|plain) (default "plain")
      --log_level string    The logging level (trace|debug|info|warn|error|fatal|panic) (default "info")
      --trace               print out full stack trace on errors

Use "nyxd [command] --help" for more information about a command.

Initialising your validator

Prerequisites:

FQDN Domain name
IPv4 and IPv6 connectivity

Choose a name for your validator and use it in place of <ID> in the following command:

# Mainnet
nyxd init <ID> --chain-id=nyx

# Sandbox testnet
nyxd init <ID> --chain-id=sandbox

init generates priv_validator_key.json and node_key.json.

If you have already set up a validator on a network, make sure to back up the key located at ~/.nyxd/config/priv_validator_key.json.

If you don’t save the validator key, then it can’t sign blocks and will be jailed all the time, and there is no way to deterministically (re)generate this key.

At this point, you have a new validator, with its own genesis file located at $HOME/.nyxd/config/genesis.json. You will need to replace the contents of that file that with either the Nyx Mainnet or Sandbox Testnet genesis file.

You can use the following command to download them for the correct network:

# Mainnet
wget  -O $HOME/.nyxd/config/genesis.json https://nymtech.net/genesis/genesis.json

# Sandbox testnet
wget -O $HOME/.nyxd/config/genesis.json https://sandbox-validator1.nymtech.net/snapshots/genesis.json

`config.toml` configuration

Edit the following config options in $HOME/.nyxd/config/config.toml to match the information below for your network:

# Mainnet
persistent_peers = "ee03a6777fb76a2efd0106c3769daaa064a3fcb5@51.79.21.187:26656"
create_empty_blocks = false
laddr = "tcp://0.0.0.0:26656"

# Sandbox testnet
cors_allowed_origins = ["*"]
persistent_peers = "8421c0a3d90d490e27e8061f2abcb1276c8358b6@sandbox-validator1.nymtech.net:26666"
create_empty_blocks = false
laddr = "tcp://0.0.0.0:26656"

These affect the following:

persistent_peers = "<PEER_ADDRESS>@<DOMAIN>.nymtech.net:26666" allows your validator to start pulling blocks from other validators. The main sandbox validator listens on 26666 instead of the default 26656 for debugging. It is recommended you do not change your port from 26656.
create_empty_blocks = false will save space
laddr = "tcp://0.0.0.0:26656" is in your p2p configuration options

Optionally, if you want to enable Prometheus metrics then the following must also match in the config.toml:

prometheus = true
prometheus_listen_addr = ":26660"

Remember to enable metrics in the ‘Configuring Prometheus metrics’ section below as well.

And if you wish to add a human-readable moniker to your node:

moniker = "<YOUR_VALIDATOR_NAME>"

Finally, if you plan on using Cockpit on your server, change the grpc port from 9090 as this is the port used by Cockpit.

`app.toml` configuration

In the file $HOME/nyxd/config/app.toml, set the following values:

# Mainnet
minimum-gas-prices = "0.025unym,0.025unyx"
enable = true in the `[api]` section to get the API server running

# Sandbox Testnet
minimum-gas-prices = "0.025unymt,0.025unyxt"
enable = true` in the `[api]` section to get the API server running

Setting up your validator’s admin user

You’ll need an admin account to be in charge of your validator. Set that up with:

nyxd keys add nyxd-admin

This will add keys for your administrator account to your system’s keychain and log your name, address, public key, and mnemonic. As the instructions say, remember to write down your mnemonic.

You can get the admin account’s address with:

nyxd keys show nyxd-admin -a

Type in your keychain password, not the mnemonic, when asked.

Starting your validator

If you are running a Sandbox testnet validator, please skip the validate-genesis command: it will fail due to the size of the genesis file as this is a fork of an existing chain state.

Everything should now be ready to go. You’ve got the validator set up, all changes made in config.toml and app.toml, the Nym genesis file copied into place (replacing the initial auto-generated one). Now let’s validate the whole setup:

nyxd validate-genesis

If this check passes, you should receive the following output:

File at /path/to/genesis.json is a valid genesis file

If this test did not pass, check that you have replaced the contents of /<PATH-TO>/.nymd/config/genesis.json with that of the correct genesis file.

Open firewall ports

Before starting the validator, we will need to open the firewall ports:

# if ufw is not already installed:
sudo apt install ufw
sudo ufw enable
sudo ufw allow 1317,26656,26660,22,80,443/tcp
# to check everything worked
sudo ufw status

Ports 22, 80, and 443 are for ssh, http, and https connections respectively. The rest of the ports are documented here.

For more information about your validator’s port configuration, check the validator port reference table below.

If you are planning to use Cockpit on your validator server then you will have defined a different grpc port in your config.toml above: remember to open this port as well.

Start the validator:

nyxd start

Once your validator starts, it will start requesting blocks from other validators. This may take several hours. Once it’s up to date, you can issue a request to join the validator set with the command below.

Syncing from a snapshot

If you wish to sync from a snapshot on mainnet use Polkachu’s mainnet resources.

If you wish to sync from a snapshot on Sandbox testnet use the below commands, which are a modified version of Polkachu’s excellent resources. These commands assume you are running an OS with apt as the package manager:

# install lz4 if necessary
sudo apt install snapd -y
sudo snap install lz4

# download the snapshot
wget -O nyxd-sandbox-snapshot-data.tar.lz4 https://sandbox-validator1.nymtech.net/snapshots/nyxd-sandbox-snapshot-data.tar.lz4

# reset your validator state
nyxd tendermint unsafe-reset-all

# unpack the snapshot
lz4 -c -d nyxd-sandbox-snapshot-data.tar.lz4 | tar -x -C $HOME/.nyxd

You can then restart nyxd - it should start syncing from a block > 2000000.

Joining Consensus

When joining consensus, make sure that you do not disrupt (or worse - halt) the network by coming in with a disproportionately large amount of staked tokens.

Please initially stake a small amount of tokens compared to existing validators, then delegate to yourself in tranches over time.

Once your validator has synced and you have received tokens, you can join consensus and produce blocks.

# Mainnet
nyxd tx staking create-validator
  --amount=10000000unyx
  --fees=0unyx
  --pubkey=$(/home/<USER>/<PATH-TO>/nyxd/binaries/nyxd tendermint show-validator)
  --moniker="<YOUR_VALIDATOR_NAME>"
  --chain-id=nyx
  --commission-rate="0.10"
  --commission-max-rate="0.20"
  --commission-max-change-rate="0.01"
  --min-self-delegation="1"
  --gas="auto"
  --gas-adjustment=1.15
  --from="KEYRING_NAME"
  --node https://rpc-1.nyx.nodes.guru:443

# Sandbox Testnet
nyxd tx staking create-validator
  --amount=10000000unyxt
  --fees=5000unyxt
  --pubkey=$(/home/<USER>/<PATH-TO>/nym/binaries/nyxd tendermint show-validator)
  --moniker="<YOUR_VALIDATOR_NAME>"
  --chain-id=sandbox
  --commission-rate="0.10"
  --commission-max-rate="0.20"
  --commission-max-change-rate="0.01"
  --min-self-delegation="1"
  --gas="auto"
  --gas-adjustment=1.15
  --from="KEYRING_NAME"
  --node https://sandbox-validator1.nymtech.net:443

You’ll need either unyxt tokens on Sandbox, or unyx tokens on mainnet to perform this command.

We are currently working towards building up a closed set of reputable validators. You can ask us for coins to get in, but please don’t be offended if we say no - validators are part of our system’s core security and we are starting out with people we already know or who have a solid reputation.

If you want to edit some details for your node you will use a command like this:

# Mainnet
nyxd tx staking edit-validator
  --chain-id=nyx
  --moniker="<YOUR_VALIDATOR_NAME>"
  --details="Nyx validator"
  --security-contact="<YOUR_EMAIL>"
  --identity="<YOUR_IDENTITY>"
  --gas="auto"
  --gas-adjustment=1.15
  --from="KEYRING_NAME"
  --fees 2000unyx

# Sandbox testnet
nyxd tx staking edit-validator
  --chain-id=sandbox
  --moniker="<YOUR_VALIDATOR_NAME>"
  --details="Sandbox testnet validator"
  --security-contact="your email"
  --identity="<YOUR_IDENTITY>"
  --gas="auto"
  --gas-adjustment=1.15
  --from="KEYRING_NAME"
  --fees 2000unyxt

With above command you can specify the gpg key last numbers (as used in keybase) as well as validator details and your email for security contact.

Automating your validator with systemd

You will most likely want to automate your validator restarting if your server reboots. Checkout the maintenance page with a quick tutorial.

Installing and configuring nginx for HTTPS

If you want to set up a reverse proxying on the validator server to improve security and performance, using nginx, follow the manual on the maintenance page.

Setting the ulimit

Linux machines limit how many open files a user is allowed to have. This is called a ulimit. We need to set it to a higher value than the default 1024. Follow the instructions in the maintenance page to change the ulimit value for validators.

Using your validator

Un-jailing your validator

If your validator gets jailed, you can fix it with the following command:

# Mainnet
nyxd tx slashing unjail
  --broadcast-mode=block
  --from="KEYRING_NAME"
  --chain-id=nyx
  --gas=auto
  --gas-adjustment=1.4
  --fees=7000unyx

# Sandbox Testnet
nyxd tx slashing unjail
  --broadcast-mode=block
  --from="KEYRING_NAME"
  --chain-id=sandbox
  --gas=auto
  --gas-adjustment=1.4
  --fees=7000unyxt

Upgrading your validator

To upgrade your validator, follow the steps on the maintenance page.

Common reasons for your validator being jailed

The most common reason for your validator being jailed is that your validator is out of memory because of bloated syslogs.

Running the command df -H will return the size of the various partitions of your VPS.

If the /dev/sda partition is almost full, try pruning some of the .gz syslog archives and restart your validator process.

Day 2 operations with your validator

You can check your current balances with:

nymd query bank balances ${ADDRESS}

For example, on the Sandbox testnet this would return:

balances:
- amount: "919376"
denom: unymt
pagination:
next_key: null
total: "0"

You can, of course, stake back the available balance to your validator with the following command.

Remember to save some tokens for gas costs!

# Mainnet
nyxd tx staking delegate VALOPERADDRESS AMOUNTunym
  --from="KEYRING_NAME"
  --keyring-backend=os
  --chain-id=nyx
  --gas="auto"
  --gas-adjustment=1.15
  --fees 5000unyx

# Sandbox Testnet
nyxd tx staking delegate VALOPERADDRESS AMOUNTunymt
  --from="KEYRING_NAME"
  --keyring-backend=os
  --chain-id=sandbox
  --gas="auto"
  --gas-adjustment=1.15
  --fees 5000unyxt

Maintenance

Useful commands

Adding --no-banner startup flag will prevent Nym banner being printed even if run in tty environment.

build-info

A build-info command prints the build information like commit hash, rust version, binary version just like what command --version does. However, you can also specify an --output=json flag that will format the whole output as a json, making it an order of magnitude easier to parse.

For example ./target/debug/nym-network-requester --no-banner build-info --output json will return:

{"binary_name":"nym-network-requester","build_timestamp":"2023-07-24T15:38:37.00657Z","build_version":"1.1.23","commit_sha":"c70149400206dce24cf20babb1e64f22202672dd","commit_timestamp":"2023-07-24T14:45:45Z","commit_branch":"feature/simplify-cli-parsing","rustc_version":"1.71.0","rustc_channel":"stable","cargo_profile":"debug"}

Upgrading your node

The process is the similar for mix node, gateway and network requester. In the following steps we use a placeholder <NODE> in the commands, please change it for the type of node you want to upgrade. Any particularities for the given type of node are included.

Upgrading your node is a two-step process:

Updating the binary and ~/.nym/<NODE>/<YOUR_ID>/config/config.toml on your VPS
Updating the node information in the mixnet smart contract. This is the information that is present on the mixnet explorer.

Step 1: Upgrading your binary

Follow these steps to upgrade your mix node binary and update its config file:

pause your mix node process.
replace the existing binary with the newest binary (which you can either compile yourself or grab from our releases page).
re-run init with the same values as you used initially. This will just update the config file, it will not overwrite existing keys.
restart your mix node process with the new binary.

In case of a network requester this is all all, the following step is only for mix nodes and gateways.

Step 2: Updating your node information in the smart contract

Follow these steps to update the information about your <NODE> which is publicly available from the Nym API and information displayed on the mixnet explorer.

You can either do this graphically via the Desktop Wallet, or the CLI.

Updating node information via the Desktop Wallet

Navigate to the Bonding page and click the Node Settings link in the top right corner:

Bonding page

Update the fields in the Node Settings page and click Submit changes to the blockchain.

Node Settings Page

Updating node information via the CLI

If you want to bond your <NODE> via the CLI, then check out the relevant section in the Nym CLI docs.

Upgrading Network Requester to >= v1.1.10 from <v1.1.9

Initiate the new network requester:

nym-network-requester init --id <YOUR_ID>

Copy the old keys from your client to the network-requester configuration that was created above:

cp -vr ~/.nym/clients/myoldclient/data/* ~/.nym/service-providers/network-requester/<YOUR_ID>/data

Edit the configuration to match what you used on your client. Specifically, edit the configuration file at:

~/.nym/service-providers/network-requester/<YOUR_ID>/config/config.toml

Ensure that the fields gateway_id, gateway_owner, gateway_listener in the new config match those in the old client config at:

~/.nym/clients/myoldclient/config/config.toml

Upgrading your validator

Upgrading from v0.31.1 -> v0.32.0 process is fairly simple. Grab the v0.32.0 release tarball from the nyxd releases page, and untar it. Inside are two files:

the new validator (nyxd) v0.32.0
the new wasmvm (it depends on your platform, but most common filename is libwasmvm.x86_64.so)

Wait for the upgrade height to be reached and the chain to halt awaiting upgrade, then:

copy libwasmvm.x86_64.so to the default LD_LIBRARY_PATH on your system (on Ubuntu 20.04 this is /lib/x86_64-linux-gnu/) replacing your existing file with the same name.
swap in your new nyxd binary and restart.

You can also use something like Cosmovisor - grab the relevant information from the current upgrade proposal here.

Note: Cosmovisor will swap the nyxd binary, but you’ll need to already have the libwasmvm.x86_64.so in place.

Common reasons for your validator being jailed

The most common reason for your validator being jailed is that your validator is out of memory because of bloated syslogs.

Running the command df -H will return the size of the various partitions of your VPS.

If the /dev/sda partition is almost full, try pruning some of the .gz syslog archives and restart your validator process.

Moving a node

In case of a need to move a node from one machine to another and avoiding to lose the delegation, here are few steps how to do it.

The following examples transfers a mix node (in case of other nodes, change the mixnodes in the command for the <NODE> of your desire.

Pause your node process.

Assuming both machines are remote VPS.

Make sure your ~/.ssh/<YOUR_KEY>.pub is in both of the machines ~/.ssh/authorized_keys file
Create a mixnodes folder in the target VPS. Ssh in from your terminal and run:

# in case none of the nym configs was created previously
mkdir ~/.nym

#in case no nym mix node was initialized previously
mkdir ~/.nym/mixnodes

Move the node data (keys) and config file to the new machine by opening a local terminal (as that one’s ssh key is authorized in both of the machines) and running:

scp -r -3 <SOURCE_USER_NAME>@<SOURCE_HOST_ADDRESS>:~/.nym/mixnodes/<YOUR_ID> <TARGET_USER_NAME>@<TARGET_HOST_ADDRESS>:~/.nym/mixnodes/

Re-run init (remember that init doesn’t overwrite existing keys) to generate a config with the new listening address etc.
Change the node smart contract info via the wallet interface. Otherwise the keys will point to the old IP address in the smart contract, and the node will not be able to be connected, and it will fail up-time checks.
Re-run the node from the new location.

VPS Setup and Automation

Configure your firewall

Although your <NODE> is now ready to receive traffic, your server may not be. The following commands will allow you to set up a firewall using ufw.

# check if you have ufw installed
ufw version

# if it is not installed, install with
sudo apt install ufw -y

# enable ufw
sudo ufw enable

# check the status of the firewall
sudo ufw status

Finally open your <NODE> p2p port, as well as ports for ssh and ports for verloc and measurement pings:

# for mix node
sudo ufw allow 1789,1790,8000,22/tcp

# for gateway
sudo ufw allow 1789,22,9000/tcp

# for network requester
sudo ufw allow 22,9000/tcp

# for validator
sudo ufw allow 1317,26656,26660,22,80,443/tcp

Check the status of the firewall:

sudo ufw status

For more information about your node’s port configuration, check the port reference table below.

Automating your node with nohup, tmux and systemd

Although it’s not totally necessary, it’s useful to have the mix node automatically start at system boot time.

nohup

nohup is a command with which your terminal is told to ignore the HUP or ‘hangup’ signal. This will stop the node process ending if you kill your session.

nohup ./<NODE> run --id <YOUR_ID> # where `<YOUR_ID>` is the id you set during the `init` command and <NODE> depends on which node you starting

tmux

One way is to use tmux shell on top of your current VPS terminal. Tmux is a terminal multiplexer, it allows you to create several terminal windows and panes from a single terminal. Processes started in tmux keep running after closing the terminal as long as the given tmux window was not terminated.

Use the following command to get tmux.

Platform	Install Command
Arch Linux	`pacman -S tmux`
Debian or Ubuntu	`apt install tmux`
Fedora	`dnf install tmux`
RHEL or CentOS	`yum install tmux`
macOS (using Homebrew	`brew install tmux`
macOS (using MacPorts)	`port install tmux`
openSUSE	`zypper install tmux`

In case it didn’t work for your distribution, see how to build tmux from version control.

Running tmux

No when you installed tmux on your VPS, let’s run a mix node on tmux, which allows you to detach your terminal and let your <NODE> run on its own on the VPS.

Pause your <NODE>
Start tmux with the command

tmux

The tmux terminal should open in the same working directory, just the layout changed into tmux default layout.
Start the <NODE> again with a command:

./<NODE> run --id <YOUR_ID>

Now, without closing the tmux window, you can close the whole terminal and the <NODE> (and any other process running in tmux) will stay active.
Next time just start your teminal, ssh into the VPS and run the following command to attach back to your previous session:

tmux attach-session

To see keybinding options of tmux press ctrl+b and after 1 second ?

systemd

Here’s a systemd service file to do that:

For mix node

[Unit]
Description=Nym Mixnode <VERSION>
StartLimitInterval=350
StartLimitBurst=10

[Service]
User=<USER>
LimitNOFILE=65536
ExecStart=/home/<USER>/<PATH>/nym-mixnode run --id <YOUR_ID>
KillSignal=SIGINT
Restart=on-failure
RestartSec=30

[Install]
WantedBy=multi-user.target

Put the above file onto your system at /etc/systemd/system/nym-mixnode.service.

For Gateway

[Unit]
Description=Nym Gateway <VERSION>
StartLimitInterval=350
StartLimitBurst=10

[Service]
User=nym
LimitNOFILE=65536
ExecStart=/home/<USER>/<PATH>/nym-gateway run --id <YOUR_ID>
KillSignal=SIGINT
Restart=on-failure
RestartSec=30

[Install]
WantedBy=multi-user.target

Put the above file onto your system at /etc/systemd/system/nym-gateway.service.

For Network requester

[Unit]
Description=Nym Network Requester <VERSION>
StartLimitInterval=350
StartLimitBurst=10

[Service]
User=nym # replace this with whatever user you wish
LimitNOFILE=65536
# remember to add the `--enable-statistics` flag if running as part of a service grant and check the path to your nym-network-requester binary
ExecStart=/home/nym/nym-network-requester run --id <YOUR_ID>
KillSignal=SIGINT
Restart=on-failure
RestartSec=30

[Install]
WantedBy=multi-user.target

Now enable and start your requester:

systemctl enable nym-network-requester.service
systemctl start nym-network-requester.service

# you can always check your requester has succesfully started with:
systemctl status nym-network-requester.service

Put the above file onto your system at /etc/systemd/system/nym-network-requester.service.

For Validator

Below is a systemd unit file to place at /etc/systemd/system/nymd.service:

[Unit]
Description=Nyxd
StartLimitInterval=350
StartLimitBurst=10

[Service]
User=<USER>                                                       # change to your user
Type=simple
Environment="LD_LIBRARY_PATH=/home/<USER>/<PATH_TO_NYX_BINARIES>" # change to correct path
ExecStart=/home/<USER>/<PATH_TO_NYX_BINARIES>/nymd start          # change to correct path
Restart=on-failure
RestartSec=30
LimitNOFILE=infinity

[Install]
WantedBy=multi-user.target

Proceed to start it with:

systemctl daemon-reload # to pickup the new unit file
systemctl enable nymd   # to enable the service
systemctl start nymd    # to actually start the service
journalctl -f -u nymd # to monitor system logs showing the service start

Following steps for Nym Mixnet nodes

Change the <PATH> in ExecStart to point at your <NODE> binary (nym-mixnode, nym-gateway or nym-network-requester), and the <USER> so it is the user you are running as.

If you have built nym in the $HOME directory on your server, and your username is jetpanther, then the start command for nym mixnode might look like this:

ExecStart=/home/jetpanther/nym/target/release/nym-mixnode run --id <YOUR_ID>. Basically, you want the full /path/to/nym-mixnode run --id whatever-your-node-id-is

Then run:

systemctl daemon-reload # to pickup the new unit file

# for mix node
systemctl enable nym-mixnode.service

# for gateway
systemctl enable nym-gateway.service

Start your node:

# for mix node
service nym-mixnode start

# for gateway
service nym-gateway start

This will cause your node to start at system boot time. If you restart your machine, the node will come back up automatically.

You can monitor system logs of your node by running:

journalctl -f -u <NODE>.service

Or check a status by running:

systemctl status <NODE>.service

You can also do service <NODE> stop or service <NODE> restart.

Note: if you make any changes to your systemd script after you’ve enabled it, you will need to run:

systemctl daemon-reload

This lets your operating system know it’s ok to reload the service configuration.

Setting the ulimit

Linux machines limit how many open files a user is allowed to have. This is called a ulimit.

ulimit is 1024 by default on most systems. It needs to be set higher, because mix nodes make and receive a lot of connections to other nodes.

If you see errors such as:

Failed to accept incoming connection - Os { code: 24, kind: Other, message: "Too many open files" }

This means that the operating system is preventing network connections from being made.

Set the ulimit via `systemd` service file

Replace <NODE> variable with nym-mixnode, nym-gateway or nym-network-requester according the node you running on your machine.

The ulimit setup is relevant for maintenance of nym mix node only.

Query the ulimit of your <NODE> with:

# for nym-mixnode, nym-gateway and nym-network requester:
grep -i "open files" /proc/$(ps -A -o pid,cmd|grep <NODE> | grep -v grep |head -n 1 | awk '{print $1}')/limits

# for nyx validator:
grep -i "open files" /proc/$(ps -A -o pid,cmd|grep nymd | grep -v grep |head -n 1 | awk '{print $1}')/limits

You’ll get back the hard and soft limits, which looks something like this:

Max open files            65536                65536                files

If your output is the same as above, your node will not encounter any ulimit related issues.

However if either value is 1024, you must raise the limit via the systemd service file. Add the line:

LimitNOFILE=65536

Reload the daemon:

systemctl daemon-reload

or execute this as root for system-wide setting of ulimit:

echo "DefaultLimitNOFILE=65535" >> /etc/systemd/system.conf

Reboot your machine and restart your node. When it comes back, use:

# for nym-mixnode, nym-gateway and nym-network requester:
cat /proc/$(pidof <NODE>)/limits | grep "Max open files"

# for validator
cat /proc/$(pidof nym-validator)/limits | grep "Max open files"

Make sure the limit has changed to 65535.

Set the ulimit on `non-systemd` based distributions

In case you chose tmux option for mix node automatization, see your ulimit list by running:

ulimit -a

# watch for the output line -n
-n: file descriptors          1024

You can change it either by running a command:

ulimit -u -n 4096

or editing etc/security/conf and add the following lines:

# Example hard limit for max opened files
username        hard nofile 4096

# Example soft limit for max opened files
username        soft nofile 4096

Then reboot your server and restart your mix node.

Virtual IPs and hosting via Google & AWS

For true internet decentralization we encourage operators to use diverse VPS providers instead of the largest companies offering such services. If for some reasons you have already running AWS or Google and want to setup a <NODE> there, please read the following.

On some services (AWS, Google, etc) the machine’s available bind address is not the same as the public IP address. In this case, bind --host to the local machine address returned by $(curl ifconfig.me), but also specify --announce-host with the public IP. Please make sure that you pass the correct, routable --announce-host.

For example, on a Google machine, you may see the following output from the ifconfig command:

ens4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1460
        inet 10.126.5.7  netmask 255.255.255.255  broadcast 0.0.0.0
        ...

The ens4 interface has the IP 10.126.5.7. But this isn’t the public IP of the machine, it’s the IP of the machine on Google’s internal network. Google uses virtual routing, so the public IP of this machine is something else, maybe 36.68.243.18.

./nym-mixnode init --host 10.126.5.7, initalises the mix node, but no packets will be routed because 10.126.5.7 is not on the public internet.

Trying nym-mixnode init --host 36.68.243.18, you’ll get back a startup error saying AddrNotAvailable. This is because the mix node doesn’t know how to bind to a host that’s not in the output of ifconfig.

The right thing to do in this situation is to init with a command:

./nym-mixnode init --host 10.126.5.7 --announce-host 36.68.243.18

This will bind the mix node to the available host 10.126.5.7, but announce the mix node’s public IP to the directory server as 36.68.243.18. It’s up to you as a node operator to ensure that your public and private IPs match up properly.

To find the right IP configuration, contact your VPS provider for support.

Nym API (previously ‘Validator API’) endpoints

Numerous API endpoints are documented on the Nym API (previously ‘Validator API’)’s Swagger Documentation. There you can also try out various requests from your browser, and download the response from the API. Swagger will also show you what commands it is running, so that you can run these from an app or from your CLI if you prefer.

Mix node Reward Estimation API endpoint

The Reward Estimation API endpoint allows mix node operators to estimate the rewards they could earn for running a Nym mix node with a specific MIX_ID.

The <MIX_ID> can be found in the “Mix ID” column of the Network Explorer.

The endpoint is a particularly common for mix node operators as it can provide an estimate of potential earnings based on factors such as the amount of traffic routed through the mix node, the quality of the mix node’s performance, and the overall demand for mixnodes in the network. This information can be useful for mix node operators in deciding whether or not to run a mix node and in optimizing its operations for maximum profitability.

Using this API endpoint returns information about the Reward Estimation:

/status/mixnode/<MIX_ID>/reward-estimation

Query Response:

    "estimation": {
        "total_node_reward": "942035.916721770541325331",
        "operator": "161666.263307386408152071",
        "delegates": "780369.65341438413317326",
        "operating_cost": "54444.444444444444444443"
    },

The unit of value is measured in uNYM.

estimated_total_node_reward - An estimate of the total amount of rewards that a particular mix node can expect to receive during the current epoch. This value is calculated by the Nym Validator based on a number of factors, including the current state of the network, the number of mix nodes currently active in the network, and the amount of network traffic being processed by the mix node.
estimated_operator_reward - An estimate of the amount of rewards that a particular mix node operator can expect to receive. This value is calculated by the Nym Validator based on a number of factors, including the amount of traffic being processed by the mix node, the quality of service provided by the mix node, and the operator’s stake in the network.
estimated_delegators_reward - An estimate of the amount of rewards that mix node delegators can expect to receive individually. This value is calculated by the Nym Validator based on a number of factors, including the amount of traffic being processed by the mix node, the quality of service provided by the mix node, and the delegator’s stake in the network.
estimated_node_profit - An estimate of the profit that a particular mix node operator can expect to earn. This value is calculated by subtracting the mix node operator’s operating_costs from their estimated_operator_reward for the current epoch.
estimated_operator_cost - An estimate of the total cost that a particular mix node operator can expect to incur for their participation. This value is calculated by the Nym Validator based on a number of factors, including the cost of running a mix node, such as server hosting fees, and other expenses associated with operating the mix node.

Validator: Installing and configuring nginx for HTTPS

Setup

Nginx is an open source software used for operating high-performance web servers. It allows us to set up reverse proxying on our validator server to improve performance and security.

Install nginx and allow the ‘Nginx Full’ rule in your firewall:

sudo ufw allow 'Nginx Full'

Check nginx is running via systemctl:

systemctl status nginx

Which should return:

● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2018-04-20 16:08:19 UTC; 3 days ago
     Docs: man:nginx(8)
 Main PID: 2369 (nginx)
    Tasks: 2 (limit: 1153)
   CGroup: /system.slice/nginx.service
           ├─2369 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
           └─2380 nginx: worker process

Configuration

Proxying your validator’s port 26657 to nginx port 80 can then be done by creating a file with the following at /etc/nginx/conf.d/validator.conf:

server {
  listen 80;
  listen [::]:80;
  server_name "domain_name";

  location / {
    proxy_pass http://127.0.0.1:26657;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Followed by:

sudo apt install certbot nginx python3
certbot --nginx -d nym-validator.yourdomain.com -m you@yourdomain.com --agree-tos --noninteractive --redirect

If using a VPS running Ubuntu 20: replace certbot nginx python3 with python3-certbot-nginx

These commands will get you an https encrypted nginx proxy in front of the API.

Configuring Prometheus metrics (optional)

Configure Prometheus with the following commands (adapted from NodesGuru’s Agoric setup guide):

echo 'export OTEL_EXPORTER_PROMETHEUS_PORT=9464' >> $HOME/.bashrc
source ~/.bashrc
sed -i '/\[telemetry\]/{:a;n;/enabled/s/false/true/;Ta}' $HOME/.nymd/config/app.toml
sed -i "s/prometheus-retention-time = 0/prometheus-retention-time = 60/g" $HOME/.nymd/config/app.toml
sudo ufw allow 9464
echo 'Metrics URL: http://'$(curl -s ifconfig.me)':26660/metrics'

Your validator’s metrics will be available to you at the returned ‘Metrics URL’.

Console output

# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 6.7969e-05
go_gc_duration_seconds{quantile="0.25"} 7.864e-05
go_gc_duration_seconds{quantile="0.5"} 8.4591e-05
go_gc_duration_seconds{quantile="0.75"} 0.000115919
go_gc_duration_seconds{quantile="1"} 0.001137591
go_gc_duration_seconds_sum 0.356555301
go_gc_duration_seconds_count 2448
# HELP go_goroutines Number of goroutines that currently exist.
# TYPE go_goroutines gauge
go_goroutines 668
# HELP go_info Information about the Go environment.
# TYPE go_info gauge
go_info{version="go1.15.7"} 1
# HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.
# TYPE go_memstats_alloc_bytes gauge
go_memstats_alloc_bytes 1.62622216e+08
# HELP go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed.
# TYPE go_memstats_alloc_bytes_total counter
go_memstats_alloc_bytes_total 2.09341707264e+11
# HELP go_memstats_buck_hash_sys_bytes Number of bytes used by the profiling bucket hash table.
# TYPE go_memstats_buck_hash_sys_bytes gauge
go_memstats_buck_hash_sys_bytes 5.612319e+06
# HELP go_memstats_frees_total Total number of frees.
# TYPE go_memstats_frees_total counter
go_memstats_frees_total 2.828263344e+09
# HELP go_memstats_gc_cpu_fraction The fraction of this program's available CPU time used by the GC since the program started.
# TYPE go_memstats_gc_cpu_fraction gauge
go_memstats_gc_cpu_fraction 0.03357798610671518
# HELP go_memstats_gc_sys_bytes Number of bytes used for garbage collection system metadata.
# TYPE go_memstats_gc_sys_bytes gauge
go_memstats_gc_sys_bytes 1.3884192e+07

Ports

All <NODE>-specific port configuration can be found in $HOME/.nym/<NODE>/<YOUR_ID>/config/config.toml. If you do edit any port configs, remember to restart your client and node processes.

Mix node port reference

Default port	Use
`1789`	Listen for Mixnet traffic
`1790`	Listen for VerLoc traffic
`8000`	Metrics http API endpoint

Gateway port reference

Default port	Use
`1789`	Listen for Mixnet traffic
`9000`	Listen for Client traffic

Network requester port reference

Default port	Use
`9000`	Listen for Client traffic

Validator port reference

All validator-specific port configuration can be found in $HOME/.nymd/config/config.toml. If you do edit any port configs, remember to restart your validator.

Default port	Use
1317	REST API server endpoint
26656	Listen for incoming peer connections
26660	Listen for Prometheus connections

Troubleshooting

Binary Build Problems

I am trying to build from the GitHub archive files and the build fails

GitHub automatically includes .zip and tar.gz files of the Nym repository in its release. You cannot extract these and build - you’ll see something like this:

  process didn't exit successfully: `/build/nym/src/nym-0.12.1/target/release/build/nym-socks5-client-c1d0f76a8c7d7e9a/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'failed to extract build metadata: could not find repository from '/build/nym/src/nym-0.12.1/clients/socks5'; class=Repository (6); code=NotFound (-3)', clients/socks5/build.rs:7:31
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed

Why does this happen?

We have scripts which automatically include the Git commit hash and Git tag in the binary for easier debugging later. If you download a .zip and try building from that, it’s not a Git repository and build will fail as above.

What to do?

Open terminal in the directory where you want to have a git repository
To get Nym repository for the first time, run:

git clone https://github.com/nymtech/nym.git

Follow the instructions to build the platform
To upgrade, pause your nodes, in the same terminal window run git pull, follow the upgrade instructions and re-start your nodes.

General Node Config

Where can I find my private and public keys and config?

All config and keys files are stored in a directory named after your id which you chose during the init process, and can be found at the following PATH: $HOME/.nym/<NODE_TYPE>/<NODE_ID> where $HOME is a home directory of the user (your current user in this case) that launched the node or client.

The directory structure for each node will be roughly as follows:

bob@nym:~$ tree /home/nym/.nym/mixnodes/
/home/nym/.nym/mixnodes/
|-- nym010
|   |-- config
|   |   `-- config.toml
|   `-- data
|       |-- private_identity.pem
|       |-- private_sphinx.pem
|       |-- public_identity.pem
|       `-- public_sphinx.pem

If you cat the public_sphinx.pem key, the output will be different from the public key you will see on Nym dashboard. The reason for this is that .pem files are encoded in base64, however on the web they are in base58. Don’t be confused if your keys look different. They are the same keys, just with different encoding :)

Mix Nodes

How can I tell my node is up and running and mixing traffic?

First of all check the ‘Mixnodes’ section of either the Nym Network Explorers:

Enter your identity key to find your node. Check the contents of the Mixnode stats and Routing score sections.

There are 2 community explorers currently, which have been created by Nodes Guru:

Here is a dictionary with Nyx chain registry entry regarding all explorers.

If you want more information, or if your node isn’t showing up on the explorer of your choice and you want to double-check, here are some examples on how to check if the node is configured properly.

Check from your VPS

Additional details can be obtained via various methods after you connect to your VPS:

Socket statistics with `ss`

sudo ss -s -t | grep 1789 # if you have specified a different port in your mix node config, change accordingly

This command should return a lot of data containing ESTAB. This command should work on every unix based system.

List open files and reliant processes with `lsof`

# check if lsof is installed:
lsof -v
# install if not installed
sudo apt install lsof
# run against mix node port
sudo lsof -i TCP:1789 # if you have specified a different port in your mixnode config, change accordingly

This command should return something like this:

nym-mixno 103349 root   53u  IPv6 1333229972      0t0  TCP [2a03:b0c0:3:d0::ff3:f001]:57844->[2a01:4f9:c011:38ae::5]:1789 (ESTABLISHED)
nym-mixno 103349 root   54u  IPv4 1333229973      0t0  TCP nym:57104->194.5.78.73:1789 (ESTABLISHED)
nym-mixno 103349 root   55u  IPv4 1333229974      0t0  TCP nym:48130->static.236.109.119.168.clients.your-server.de:1789 (ESTABLISHED)
nym-mixno 103349 root   56u  IPv4 1333229975      0t0  TCP nym:52548->vmi572614.contaboserver.net:1789 (ESTABLISHED)
nym-mixno 103349 root   57u  IPv6 1333229976      0t0  TCP [2a03:b0c0:3:d0::ff3:f001]:43244->[2600:1f18:1031:2401:c04b:2f25:ca79:fef3]:1789 (ESTABLISHED)

Query `systemd` journal with `journalctl`

sudo journalctl -u nym-mixnode -o cat | grep "Since startup mixed"

If you have created nym-mixnode.service file (i.e. you are running your mix node via systemd) then this command shows you how many packets have you mixed so far, and should return a list of messages like this:

2021-05-18T12:35:24.057Z INFO  nym_mixnode::node::metrics                      > Since startup mixed 233639 packets!
2021-05-18T12:38:02.178Z INFO  nym_mixnode::node::metrics                      > Since startup mixed 233739 packets!
2021-05-18T12:40:32.344Z INFO  nym_mixnode::node::metrics                      > Since startup mixed 233837 packets!
2021-05-18T12:46:08.549Z INFO  nym_mixnode::node::metrics                      > Since startup mixed 234081 packets!
2021-05-18T12:56:57.129Z INFO  nym_mixnode::node::metrics                      > Since startup mixed 234491 packets!

You can add | tail to the end of the command to watch for new entries in real time if needed.

build-info

For example ./target/debug/nym-network-requester --no-banner build-info --output json will return:

{"binary_name":"nym-network-requester","build_timestamp":"2023-07-24T15:38:37.00657Z","build_version":"1.1.23","commit_sha":"c70149400206dce24cf20babb1e64f22202672dd","commit_timestamp":"2023-07-24T14:45:45Z","commit_branch":"feature/simplify-cli-parsing","rustc_version":"1.71.0","rustc_channel":"stable","cargo_profile":"debug"}

Check from your local machine

Scan ports with `nmap`:

nmap -p 1789 <IP ADDRESS> -Pn

If your mix node is configured properly it should output something like this:

bob@desktop:~$ nmap -p 1789 95.296.134.220 -Pn

Host is up (0.053s latency).

PORT     STATE SERVICE
1789/tcp open  hello

Query online nodes:

curl --location --request GET 'https://validator.nymtech.net/api/v1/mixnodes/'

Will return a list all nodes currently online.

You can query gateways by replacing mixnodes with gateways in the above command, and can query for the mixnodes and gateways on the Sandbox testnet by replacing validator with sandbox-validator.

Check with Network API

We currently have an API set up returning our metrics tests of the network. There are two endpoints to ping for information about your mix node, report and history. Find more information about this in the Mixnodes metrics documentation.

Why is my node not mixing any packets?

If you are still unable to see your node on the dashboard, or your node is declaring it has not mixed any packets, there are several potential issues:

The firewall on your host machine is not configured properly. Checkout the instructions.
You provided incorrect information when bonding your node.
You are running your mix node from a VPS without IPv6 support.
You did not use the --announce-host flag while running the mix node from your local machine behind NAT.
You did not configure your router firewall while running the mix node from your local machine behind NAT, or you are lacking IPv6 support.
Your mix node is not running at all, it has either exited / panicked or you closed the session without making the node persistent. Check out the instructions.

Caution

Your mix node must speak both IPv4 and IPv6 in order to cooperate with other nodes and route traffic. This is a common reason behind many errors we are seeing among node operators, so check with your provider that your VPS is able to do this!

Incorrect bonding information

Check that you have provided the correct information when bonding your mix node in the web wallet interface. When in doubt, un-bond and then re-bond your node!

All delegated stake will be lost when un-bonding! However the mix node must be operational in the first place for the delegation to have any effect.

Missing `announce-host` flag

On certain cloud providers such as AWS and Google Cloud, you need to do some additional configuration of your firewall and use --host with your local ip and --announce-host with the public ip of your mix node host.

If the difference between the two is unclear, contact the help desk of your VPS provider.

No IPv6 connectivity

Make sure that your VPS has IPv6 connectivity available with whatever provider you are using.

To get all ip addresses of your host, try following commands:

hostname -i

Will return your local ip address.

hostname -I

Will return all of the ip addresses of your host. This output should look something like this:

bob@nym:~$ hostname -I
88.36.11.23 172.18.0.1 2a01:28:ca:102::1:641

The first ipv4 is the public ip you need to use for the --announce-host flag.
The second ipv4 is the local ip you need to use for the --host flag.
The 3rd output should confirm if your machine has ipv6 available.

Running on a local machine behind NAT with no fixed IP address

Your ISP has to be IPv6 ready if you want to run a mix node on your local machine. Sadly, in 2020, most of them are not and you won’t get an IPv6 address by default from your ISP. Usually it is an extra paid service or they simply don’t offer it.

Before you begin, check if you have IPv6 here or by running command explained in the section above. If not, then don’t waste your time to run a node which won’t ever be able to mix any packet due to this limitation. Call your ISP and ask for IPv6, there is a plenty of it for everyone!

If all goes well and you have IPv6 available, then you will need to init the mix node with an extra flag, --announce-host. You will also need to edit your config.toml file each time your IPv4 address changes, that could be a few days or a few weeks. Check the your IPv4 in the section above.

Additional configuration on your router might also be needed to allow traffic in and out to port 1789 and IPv6 support.

Here is a sample of the init command example to create the mix node config.

./nym-mixnode init --id <YOUR_ID> --host 0.0.0.0 --announce-host 85.160.12.13

--host 0.0.0.0 should work every time even if your local machine IPv4 address changes. For example on Monday your router gives your machine an address 192.168.0.13 and on Wednesday, the DHCP lease will end and you will be assigned 192.168.0.14. Using 0.0.0.0 should avoid this without having to set any static IP in your router`s configuration.
you can get your current IPv4 address by either using curl ipinfo.io if you’re on MacOS or Linux or visiting whatsmyip site. Simply copy it and use it as --anounce-host address.

Make sure you check if your node is really mixing. We are aiming to improve the setup for operators running locally, however you may need a bit of patience to set this up from your home behind NAT.

Accidentally killing your node process on exiting session

When you close your current terminal session, you need to make sure you don’t kill the mix node process! There are multiple ways on how to make it persistent even after exiting your ssh session, the easiest solution is to use tmux or nohup, and the more elegant solution is to run the node with systemd. Read the automation manual here.

Common errors and warnings

Most of the ERROR and WARN messages in your node logs are benign - as long as your node outputs since startup mixed X packets! (X bust be > 0) in your logs (and this number increases over time), your node is mixing packets. If you want to be sure, check the Nym dashboard or see other ways on how to check if your node is mixing properly as outlined in the section How can I tell my node is up and running and mixing traffic? above.

More specific errors and warnings are covered below.

`tokio runtime worker` error

If you are running into issues with an error including the following:

thread 'tokio-runtime-worker' panicked at 'Failed to create TCP listener: Os { code: 99, kind: AddrNotAvailable, message: "Cannot assign requested address" }'

Then you need to --announce-host <PUBLIC_IP> and --host <LOCAL_IP> on startup. This issue is addressed above

Can I use a port other than 1789 ?

Yes! Here is what you will need to do:

Assuming you would like to use port 1337 for your mix node, you need to open the new port (and close the old one):

sudo ufw allow 1337
sudo ufw deny 1789

And then edit the mix node’s config.

If you want to change the port for an already running node, you need to stop the process before editing your config file.

The config file is located at ~/.nym/mixnodes/<YOUR_ID>/config/config.toml.

For example, assuming <YOUR_ID> was chosen to be alice-node:

nano ~/.nym/mixnodes/alice-node/config/config.toml

You will need to edit two parts of the file. announce_address and listening_address in the config.toml file. Simply replace :1789 (the default port) with :1337 (your new port) after your IP address.

Finally, restart your node. You should see if the mix node is using the port you have changed in the config.toml file right after you run the node.

What is `verloc` and do I have to configure my mix node to implement it?

verloc is short for verifiable location. Mixnodes and gateways now measure speed-of-light distances to each other, in an attempt to verify how far apart they are. In later releases, this will allow us to algorithmically verify node locations in a non-fakeable and trustworthy manner.

You don’t have to do any additional configuration for your node to implement this, it is a passive process that runs in the background of the mixnet from version 0.10.1 onward.

Validators

Common reasons for your validator being jailed

The most common reason for your validator being jailed is that your validator is out of memory because of bloated syslogs.

Running the command df -H will return the size of the various partitions of your VPS.

If the /dev/sda partition is almost full, try pruning some of the .gz syslog archives and restart your validator process.

Where can I get more help?

The fastest way to reach one of us or get a help from the community, visit our Telegram Node Setup Help Chat or head to our Discord.

For more tech heavy question join our Matrix core community channel, where you can meet other builders and Nym core team members.

Frequently Asked Questions

Mixnet nodes

What determines the rewards when running a mix node?

The stake required for a mix node to achieve maximum rewards is called mix node saturation point. This is calculated from the staking supply (all circulating supply + part of unlocked tokens). The target level of staking is to have 50% of the staking supply locked in mix nodes.

The node stake saturation point, which we denote by Nsat, is given by the stake supply, target level of staking divided by the number of rewarded (active) nodes.

This design ensures the nodes aim to have a same size of stake (reputation) which can be done by delegation staking, as well as it ensures that there is a decentralization of staking as any higher level of staked tokens per node results in worse rewards. On the contrary, the more mix nodes are active, the lower is Nsat. The equilibrium is reached when the staked tokens are delegated equally across the active mix-nodes and that’s our basis for this incentive system.

For more detailed calculation, read our blog post Nym Token Economics update. More info on staking can be found here. And here is more info on how to choose a mix node for delegation. And finally an update on token economics from July 2023.

Consider in which jurisdiction you reside and where do you want to run a mix node. Do you want to pay by crypto or not and what are the other important particularities for your case? We always recommend operators to try to chose smaller and decentralized VPS providers over the most known ones controlling a majority of the internet. We receive some good feedback on these: Hertzner, DigitalOcean, Linode, Ghandi and Exoscale. Do your own research and share with the community.

What’s the Sphinx packet size?

The sizes are shown in the configs here (default is the one clients use, the others are for research purposes, not to be used in production as this would fragment the anonymity set). More info can be found here.

Why a mix node and a gateway cannot be bond to the same wallet?

Becauase of the way the smart contract works we keep it one-node one-address at the moment.

Which nodes are the most needed to be setup to strengthen Nym infrastructure and which ones bring rewards?

Right now only mix nodes are rewarded. We’re working on gateway and service payments. Gateways are the weak link right now due mostly to lack of incentivisation. Services like Network Requesters are obviously the most necessary for people to start using the platform, and we’re working on smart contracts to allow for people to start advertising them the same way they do mix nodes.

Are mixnodes whitelisted?

Nope, anyone can run a mix node. Purely reliant on the node’s reputation (self stake + delegations) & routing score.

Validators and tokens

What’s the difference between NYM and uNYM?

1 NYM = 1 000 000 uNYM

Can I run a validator?

We are currently working towards building up a closed set of reputable validators. You can ask us for coins to get in, but please don’t be offended if we say no - validators are part of our system’s core security and we are starting out with people we already know or who have a solid reputation.

Why is validator set entry whitelisted?

We understand that the early days of the Nyx blockchain will face possible vulnerabilities in terms of size - easy to disrupt or halt the chain if a malicious party entered with a large portion of stake. Besides that, there are some legal issues we need to address before we can distribute the validator set in a fully permissions fashion.

Why does Nym do many airdrops?

It is part of ensuring decentralisation - we need to avoid a handful of people having too much control over the token and market. Of course ideally people will stake the tokens and contribute to the project at this stage. We run surveys to better understand what people are doing with their tokens and what usability issues there are for staking. Any feedback is appreciated as it helps us improve all aspects of using the token and participating in the ecosystem.

Project Smoosh - FAQ

We aim on purpose to make minimal changes to reward scheme and software. We’re just ‘smooshing’ together stuff we already debugged and know works.
– Harry Halpin, Nym CEO

This page refer to the changes which are planned to take place over Q3 and Q4 2023. As this is a transition period in the beginning (Q3 2023) the [Mix Nodes FAQ page](./mixnodes-faq.md) holds more answers to the current setup as project Smoosh refers to the eventual setup. As project Smoosh gets progressively implemented the answers on this page will become to be more relevant to the current state and eventually this FAQ page will be merged with the still relevant parts of the main Mix Nodes FAQ page.

If any questions are not answered or it's not clear for you in which stage project Smoosh is right now, please reach out in Node Operators [Matrix room](https://matrix.to/#/#operators:nymtech.chat).

Overview

What is project Smoosh?

As we shared in our blog post article What does it take to build the wolds most powerful VPN, project Smoosh is:

A nick-name by CTO Dave Hrycyszyn and Chief Scientist Claudia Diaz for the work they are currently doing to “smoosh” Nym nodes so that the same operator can serve alternately as mix node, gateway or VPN node. This requires careful calibration of the Nym token economics, for example, only nodes with the highest reputation for good quality service will be in the VPN set and have the chance to earn higher rewards. By simplifying the components, adding VPN features and supporting new node operators, the aim is to widen the geographical coverage of nodes and have significant redundancy, meaning plenty of operators to be able to meet demand. This requires strong token economic incentives as well as training and support for new node operators.

Technical Questions

What are the changes?

Project smoosh will have three steps:

Combine the gateway and network-requester.
Combine all the nodes in the Nym Mixnet into one binary, that is mixnode, gateway (entry and exit) and network-requester.
Make a selection button (command/argument/flag) for operators to choose whether they want their node to provide all or just some of the functions nodes have in the Nym Mixnet. Not everyone will be able/want to run an exit gateway for example.

These three steps will be staggered over time - period of several months, and will be implemented one by one with enough time to take in feedback and fix bugs in between.
Generally, the software will be the same, just instead of multiple binaries, there will be one Nym Mixnet node binary. Delegations will remain on as they are now, per our token economics (staking, saturation etc)

What is the change from allow list to deny list?

The operators running gateways would have to “open” their nodes to a wider range of online services, in a similar fashion to Tor exit relays. The main change will be to expand the original short allow list to a more permissive setup. An exit policy will constrain the hosts that the users of the Nym VPN and Mixnet can connect to. This will be done in an effort to protect the operators, as Gateways will act both as SOCKS5 Network Requesters, and exit nodes for IP traffic from Nym VPN and Mixnet clients.

Can I run a mix node only?

Yes, to run a mix node only is an option. However it will be less rewarded as nodes providing option for gateway - meaning the new smooshed gateway (previously gateway and network requester) - due to the work and risk the operators have in comparison to running a mixnode only.

Token Economics & Rewards

What are the incentives for the node operator?

In the original setup there were no incentives to run a network-requester. After the transition all the users will buy multiple tickets of zkNyms credentials and use those as anonymous e-cash to pay for their data traffic ([Nym API](https://github.com/nymtech/nym/tree/master/nym-api) will do the do cryptographical checks to prevent double-spending). All collected fees get distributed to all active nodes proportionally to their work by the end of each epoch.

How does this change the token economics?

The token economics will stay the same as they are, same goes for the reward algorithm. In practice the distribution of rewards will benefit more the operators who run open gateways.

How are the rewards distributed?

As each operator can choose what roles their nodes provide, the nodes which work as open gateways will have higher rewards because they are the most important to keep up and stable. Besides that the operators of gateways may be exposed to more complication and possible legal risks.

The nodes which are initialized to run as mix nodes and gateways will be chosen to be on top of the active set before the ones working only as a mix node.

We are considering to turn off the rewards for non-open gateways to incentivize operators to run the open ones. Mix nodes on ‘standby’ will not be rewarded (as they are not being used).

The more roles an operator will allow their node to provide the bigger reward ratio which will have huge performance benefits for the end-users.

How will be the staking and inflation after project Smoosh?

We must run tests to see how many users pay. We may need to keep inflation on if not enough people pay to keep high quality gateways on in the early stage of the transition. That would mean keeping staking on for gateways. Staking will always be on for mix nodes.

When project smooth will be launched, it would be the mixmining pool that will pay for the gateway rewards based on amount of traffic routed ?

Yes, the same pool. Nym’s aim is to do minimal modifications. The only real modification on the smart contract side will be to get into top X of ‘active set’ operators will need to have open gateway function enabled.

What does this mean for the current delegators?

From an operator standpoint, it shall just be a standard Nym upgrade, a new option to run the gateway software on your node. Delegators should not have to re-delegate.

Legal Questions

Are there any legal concerns for the operators?

So far the general line is running a gateway is not illegal (unless you are in Iran, China, and a few other places) and due to encryption/mixing less risky than running a normal VPN node. For mix nodes, its very safe as they have no idea what packets they are mixing.

There are several legal questions regarding to this and we would like to ask you to fill this short survey.

We’ll have a thorough legal analysis out before hand and various resources from and for the community.

Code of Conduct

We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.

Please avoid using overtly sexual aliases or other nicknames that might detract from a friendly, safe and welcoming environment for all.

Please be kind and courteous. There’s no need to be mean or rude.

Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.

Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works.

We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behaviour. We interpret the term “harassment” as including the definition in the Citizen Code of Conduct; if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don’t tolerate behaviour that excludes people in socially marginalized groups.

Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops or any of the Rust moderation team immediately. Whether you’re a regular contributor or a newcomer, we care about making this community a safe place for you and we’ve got your back.

Likewise any spamming, trolling, flaming, baiting or other attention-stealing behaviour is not welcome.

Licensing

Nym is Free Software released under the Apache License V2.

All of the contributions of the Nym core developers are © Nym Technologies SA. If you are interested in talking to us about other licenses, please get in touch.

Nym Operators Guide