tl;dr: The Trustlines Blockchain is planned to be launched mid of November 2019. Validators and other interested parties can get information about the exact launch date by following the Trustlines Foundation’s Twitter and signing up for the Trustlines newsletter. Before the launch, validators should make sure their nodes are properly set up. The easiest way to install all necessary components is by using the provided quickstart script. Nodes will automatically start sealing blocks on the start date, which is defined in the genesis block.

Recap πŸ”„

The Trustlines Blockchain is a minimal viable Proof-of-Stake sidechain to Ethereum. It features anonymous validators and is intended to specifically host DApps which are aligned with the Trustlines vision, i.e. applications which leverage mutual-trust relationships to organize the transfer of value. The validator auction which ended on the 22nd of October 2019, determined the first set of validators, consisting of 45 slots.

The Trustlines testnet, Laika, had been launched on the 21st of November 2018, has 16 active validators and reached a total of 4.6m blocks at the time of writing.

Getting ready for the launch πŸš€

In preparation for the blockchain launch, the Trustlines Foundation will provide the specification of the blockchain in form of a Parity chain spec file. The foundation will also provide a quickstart script, which will make installing all necessary components straight forward.

Both the chain spec file (needed only for manual installation) as well as the quickstart script will be provided for download in a dedicated repo in the coming weeks. For now, if you’re curious you can check it out in the Trustlines Blockchain Github repository. The chain spec file will include the validator set determined via the validator auction as well as a start date in the genesis block.

As soon as the chain spec file is published and shared, validators can start running their nodes with the spec file. Their nodes will automatically start producing blocks when the start date is reached.

It is highly recommended to have the validator node up and ready for the launch of the chain. Hence it’s best to set up the node promptly once the chain spec file was provided.

After a grace period of two weeks post blockchain launch, which shall allow each validator to resolve any problems they may face with running their nodes, the Trustlines Foundation will propose a hard fork. This hard fork will switch validator handling from a list to a contract and will remove inactive validators.

Why do we do this? Initially, the chain is β€œsoft”-launched with the validator set being handled in a list format, for both simplicity reasons and to ensure a smooth start, even if some validators are offline. Then, the goal is to remove inactive validators before switching from list to contract. On the Trustlines Blockchain, validators need to be handled via a contract in order to be able to remove validators and have on-chain governance of the validator set.

Again, it is very important that all validators set up their node correctly before the end of the grace period to not be forked out of the validator set due to inactivity!

Should validators encounter any problems in setting up their nodes during the preparation period, they can get technical help by approaching Trustlines Protocol contributors in the Gitter chat.

All you need to know as a validator βœ…

As a validator, it’s your job to run the services required to operate the Trustlines Blockchain in a stable environment. These services include a Parity node running with the chain spec file corresponding to the Trustlines Blockchain, an Ethereum mainnet node or access to one via JSON RPC, and a bridge client. A `quickstart` script will be provided to easily set these services up.

Below you find a list of the optional and required services validators need to run in order to operate the Trustlines Blockchain.

Required components

  • Parity node: The Parity node is connected to the Trustlines Blockchain and validates blocks on the Trustlines Blockchain.
  • Bridge client: The bridge client enables the transfer of Trustlines Network Tokens (TLN) from the Ethereum mainnet to the Trustlines Blockchain. The bridge client monitors the Ethereum mainnet for transfer events of TLN to the `foreign bridge` contract. Once such event occurs, the bridge will confirm the transfer on the `home bridge` contract on the Trustlines Blockchain. Then, once more than 50% of the validators have confirmed the transfer, Trustlines Network Coins (TLC) will be sent to the same address (originator of the transfer on Ethereum) on the Trustlines Blockchain.
  • Ethereum mainnet node: In order for the bridge to work, validators need access to an Ethereum mainnet node. To make it simpler for validators, the quickstart script will thus start such a node or give you the option to connect to an Ethereum node you have access to.

Optional components

  • Netstat client: Optionally, validators may report the status of their Trustlines node to the Trustlines Blockchain netstat service. To do this, they will have to ask for authentication credentials by sending an email to and run a netstat client with the received credentials. This will allow to gather information about the health of the network. You can see the netstats for the Laika testnet here.
  • tlbc-monitor: Another optional tool is the `tlbc-monitor` which will monitor the Trustlines Blockchain and produce a report for equivocating validators, as well as for inactive validators. The equivocation report contains the proof required to remove a validator from the validator set and slash his deposit on the Ethereum mainnet. The inactivity report only contains information as to how many blocks a certain validator failed to produce when it should have. Please note: The tlbc-monitor is set up automatically when using the quickstart script.
  • Watchtower: To make the updating process easier for validators that use the quickstart script, a `watchtower` docker container will be started. This container will monitor for newer versions of the services described above. Once a newer version is detected, it will pull it and restart the service without requiring any action by the validator.

We recommend at least 4GB of memory and 20GB of SSD storage as a minimum hardware setup to run the required services for a validator node (based on the experiences we have had on our long-running testnet). Please take into account that this excludes the Ethereum mainnet node.

Introducing the quickstart script 🎬

The quickstart script is a means for validators to easily set up every service they should run. It will walk you through the following steps:

  • Asks for your private key to set up a Trustlines Blockchain node.
  • Sets up an Ethereum mainnet node to be used by the bridge client or asks you to provide a URL to connect to an Ethereum mainnet node you have access to.
  • Sets up the bridge client.
  • Sets up `tlbc-monitor` tool used to monitor the Trustlines Blockchain for equivocation and inactivity.
  • Asks whether it should set an optional netstat client up, which would send status reports to our netstat service.
  • Sets up the `watchtower` service that will automatically update and restart the previously set up services when a new version is published.

If you are not confident you can execute all of the above listed steps on your own, we recommend using the quickstart script.

Option to remove auto update feature: You can also use the quickstart script to start everything, but subsequently stop and remove the watchtower docker container to disable automatic updates of running services. You will then have to update the services on your own. Important: If you disable the watchtower you will need to update the Trustlines Blockchain spec file if you want to follow hard forks proposed and pushed to theTrustlines Protocol Github organization.

You can review the code of the quickstart script here, however, please do not download it yet. The download will be provided from a different repo.

Important information on operating a validator node ⚠️

1. Slashing conditions

Currently, the only condition under which a validator’s stake will be slashed is equivocation. This means that validators will only get slashed if they produce two or more blocks for the same step. A step is defined as the five seconds time window for which a validator should produce a block. Having two blocks for the same step would create two different possible forks at that moment and is deemed malicious.

Validators should never run two validators nodes with the same private key simultaneously since this will eventually result in equivocation.

2. Inactivity

There is no slashing of stakes for inactivity, however it is generally advised that inactive validators should be removed from the validator set via hard forking. Inactive validators shall be communicated and publicly disclosed in the governance forums. This should give them the opportunity to fix their node before a fork is proposed to remove them from the validator set. If a validator is removed from the validator set, his stake remains locked until the end of the validation period. After the validation period has concluded, it can be claimed back. The stake will not get slashed.

3. Participating in Trustlines Blockchain governance

Validators and other interested parties can participate in the governance and voting process by joining in the Trustlines Blockchain related discussions. The currently proposed forum for those discussions is the Trustlines subreddit. However, other forums and channels can be used at the discretion of the community.

Validators can use the `tlbc-monitor` tool to get reports on inactive and equivocating validators. Those reports can be used to initiate discussions around forks concerning validators removal. Visit the tlbc monitor Github repo for documentation on monitoring.

4. Hard forks

Any validator or other community member can propose a hard fork via the chosen discussion and governance forums (e.g. Reddit, Gitter, Telegram; please note that other blockchain governance centered new forums may arise in future). Discussions should derive from there. If consensus is reached, the Trustlines Foundation may assist the fork by pushing an update to users having enabled the watchtower for their Trustlines Blockchain node (mainly quickstart script users). The effective decision (voting power) of the validator is to update their nodes to follow the fork or not.

Closing remarks

We hope this blog post helped clarify any questions arising for validators or other Trustlines ecosystem members with regards to the launch of the Trustlines Blockchain and its governance. Please let us know about any remaining questions you might have!

We are excited to soon be launching the chain alongside with the 40+ validators that successfully secured their slot in the first Trustlines validator auction.

In the meantime, feel free to read more about validators on the Trustlines FAQ page, check out the Trustlines Protocol codebase or join the discussions in the community Telegram and Reddit channels.

The Trustlines Foundation

To stay up to date, follow us on Twitter or join the discussion on Reddit!

Disclaimer: Note that receiving block rewards and transaction fees is dependent on a community of validators emerging and the potential users of the Trustlines Blockchain. The Trustlines Foundation cannot guarantee that a Trustlines Blockchain including the chain spec as proposed by the Trustlines Foundation actually emerges out of the actions of these third party stakeholders. Hence, participating in the auction and/or running a validator node does not entail a right or an entitlement in any way whatsoever to either becoming and/or remaining a validator or receiving block rewards and/or transaction fees.