Skip to main content

Tier 1 Organizations

To help with Stellar’s decentralization, the most advanced teams building on Stellar run validators and strive to join the ranks of “Tier 1 organizations.”

Remember that the Stellar network consists of organizations that each run validators, and each organization decides for itself, by configuring a quorum set, which and how many other organizations it requires agreement from in order to commit to a particular new ledger. Tier 1 organizations are a group of organizations that, due to the fact that most other organizations require agreement from them, bear the safety and liveness of the Stellar network on their shoulders[^1].

To become a Tier 1 organization, a team running validators must convince enough other organizations in the Stellar network to trust them by including them in their quorum sets. As part of this process, they must meet some requirements that are accepted by the community of Stellar validators. For example, Tier 1 organizations generally run three validators, coordinate any changes to their quorum sets with each other, and hold themselves to a higher standard of uptime and responsiveness.

As a steward of the Stellar network, the SDF works closely with Tier 1 organizations to ensure the health of the network, maintain robust quorum intersection, and build in redundancy to minimize network disruptions. This guide outlines the minimum requirements recommended by the SDF in order to be a Tier 1 organization. However, in the end, the SDF on its own cannot add or remove a Tier 1 organization; this depends on the quorum sets of many other organizations in the network.

Why Three Validators​

The most important recommendation for a Tier 1 organization is to set up and maintain three full validators. Why three?

On Stellar, validators choose to trust organizations when they configure their quorum set. If you are a trustworthy organization, you want your presence on the network to persist even if a node fails or you take it down for maintenance. A trio of validating nodes allows that to happen: when configuring their quorum sets, other participants can requires ⅔ of your validating nodes to agree. If 1 has issues, no big deal: the other two still vote on your organization’s behalf, so the show goes on. To ensure redundancy, it's also important that those three full validators be geographically dispersed: if they're in the same data center, they run the risk of going down at the same time.

Here’s what else Tier 1 organizations should expect of one another:

Publish History Archives​

In addition to participating in the Stellar Consensus Protocol, a full validator publishes an archive of network transactions. To do that, you need to configure Stellar Core to record history to a publicly accessible archive, and add the location of that archive to your stellar.toml. We recommend that, as a Tier 1 organization, you should set each of your nodes to record history to a separate archive.

Public archives make the network more resilient: when new nodes come online, or when existing nodes lose synch, they need to consult an archive to figure out what they missed. Sharing snapshots of the ledger, which detail transactions and their results, allows those nodes to catch up, and more archives mean more redundancy and greater decentralization. Plus, sharing history keeps everyone honest.

Set Up a Safe Quorum Set​

For simplicity, we’re recommending that every Tier 1 node use the same quorum set configuration, which is made up of inner quorum sets representing each Tier 1 organization.

To configure a quorum set for your validator, we recommend including several Tier 1 organizations or copying the existing Tier 1 Qset and optionally adding additional organizations that you trust to it. Using existing Tier 1 organizations as a safety net, we can work together to expand the quorum methodically and deliberately.

To see what the current recommended quorum set looks like, check out the example Full Validator config file.

Declare Your Node​

SEP-20 is an open spec that explains how self-verification of validator nodes works. The fields it specifies are pretty simple: you set the home domain of your validator’s Stellar account to your website, where you publish information about your node and your organization in a stellar.toml file.

It’s an easy way to propagate information, and it harnesses the network to allow other participants to discover your node and add it to their quorum sets without the need for a centralized database.

Keep Your Nodes Up To Date​

Running a validator requires vigilance. You need to keep an eye on your nodes, keep them up to date with the latest version of Stellar Core, and check in on public channels for information about what’s currently happening with other validators. As organizations join or leave the network, you might need to update the quorum set configuration of your validators to ensure that your validators have robust quorum intersection with Tier 1 and robust quorum availability.

The best two ways to do that:

We always announce new Stellar Core releases in those channels. You can also find those releases on our github.

It’s also critical that you pay attention to information about what those updates mean: often, you’ll need to set your validators to vote on something timely, such as when to vote to upgrade to a new protocol version, or how high to set the operations-per-ledger limit.

Coordinate With Other Validators​

Whether you run a trio of validators or a single node, it’s important that you coordinate with other validators when you make a significant change or notice something wrong. You should let them know when you plan to:

  • Take your node down for maintenance
  • Make changes to your quorum set

Letting other validators know when you plan to take your node down for maintenance or to upgrade to the latest version of stellar-core prevents a critical mass of nodes from going offline at the same time.

Letting other validators know when you plan to change your quorum set allows them to respond, adjust, and think through the implications of the change. For the Stellar network to expand safely, the SDF recommends that validators coordinate off-chain to maintain good quorum intersection.

Monitor your quorum set​

We recommend using Prometheus to scrape and store your stellar-core metrics, and Grafana to render that data for human consumption. You can find step-by-step instructions for setting up monitoring and alerts in Monitoring and Diagnostics, along with links to Grafana dashboards we’ve created to make things easier.

You can also use Stellarbeat to view validators’ quorum configurations, get information about their availability and uptime, and the quorum command to diagnose problems with the quorum set of the local node.

You should do regular check-ins on your quorum set. If nodes have bad uptime or prove otherwise unreliable, you may need to remove them from your quorum set so that you don’t get stuck and so that the network doesn’t halt. You may also want to add new organizations that come online and prove reliable. If you plan to do either of those things, remember to communicate and coordinate with other validators.

Get in touch​

If you think you can be a Tier 1 organization, let us know on the #validators channel on the Stellar Developers Discord. We can help you through the process, and once you’re up and running, we’ll help you join Tier 1 so that you can take your rightful place as a pillar of the network. Once you’ve proven that you are responsive, reliable, and maintain good uptime, we will recommend that other validators adjust their quorum set to include your validators.

As Stellar grows, and more and more businesses build on the network, Tier 1 organizations will be crucial to a healthy expansion of the network.

[^1] The notion of Tier 1 organization can be defined precisely, but this is besides the point of this document