How Trust Works on Stellar

This blog is part of an ongoing series on the progress made on SDF's 2025 roadmap and the key initiatives we’re driving to improve usability, expand adoption, and strengthen the Stellar ecosystem.

This article describes how the Stellar Development Foundation (SDF), which operates three high-availability Stellar-network validator nodes, decides which other validating organizations to add to our trust configuration. In addition to providing transparency into how SDF evaluates network participants, it serves as a blueprint of sorts for other organizations that are interested in running their own validators. All validators need to think through their own configuration; seeing how we do it may help you get started.

The Stellar network uses Stellar Consensus Protocol (SCP) to reach agreement on a new set of transactions to apply to the current ledger in order to obtain a new ledger. Unlike the other consensus mechanisms, SCP requires each participating Stellar Core node (also called a validator node) to configure the set of other nodes to poll when determining the validity of a transaction set. When defining that configuration, validator operators decide which other validators to trust. How do they do that?

Typically, they configure their nodes based on knowledge of the real-world organizations that participate in the Stellar network. They choose a set of organizations that meet their trust requirements, and SCP guarantees that their node will not agree to apply a new set of transactions unless a sufficient number of the nodes in that set agree to apply the same set of transactions. This flexibility of user-defined trust allows for open network membership, meaning anyone can create a node in the Stellar network, and decentralized control, meaning no central authority dictates whose vote is required for consensus.

But what if a node operator chooses to trust validators from an unreliable or untrustworthy organization? The operator’s nodes may halt if too many of its trusted organizations go down, or they may even fork from the rest of the network if its trusted organizations decide to fork on their own. These problems could cascade into a network-wide outage if too many highly trusted nodes are affected. Node operators, especially the highly-trusted ones who are trusted by others, therefore have a duty to carefully select who they trust.

Below, we describe SDF’s approach to making configuration decisions. Others may choose to follow their own, different method to determine whom to trust.

To decide which nodes to trust and include in our quorum configuration, SDF evaluates potential candidates across these eight dimensions.

These dimensions form an orthogonal framework that describes a validating organization’s contribution to the health of SDF’s quorum configuration. Let’s explore the impact of each of these dimensions.

The potential impact of the dimensions is not equivalent. For each dimension, we can imagine a range of scenarios, which are simply potential situations and their outcomes. Severity is a function of impact (how bad is a scenario) and likelihood (what are the chances this happens?).

At SDF we use a risk estimation matrix like the OWASP risk classification to determine the severity:

Severity is how we can easily compare scenarios. For example, consider the following scenarios (“critical” vs “low”):

• Organizations that have a poor track record in keeping up with security best practices, the likelihood of all their validators getting hijacked to run a rogue version of the protocol becomes “High”, which combined with the impact that is also “High” (if too many validators are impacted, the network forks to the rogue version) could create a situation with “Critical” severity.
• Organizations have many of their validators located in the same region. An earthquake causes all datacenters in that region to lose power (likelihood “Low”). In a situation like this one, the network would halt until either power is restored, or validator operators start replacement validators in a different region in a matter of hours (impact is “Medium”). The overall severity is therefore “Low”.

A related key concept is correlation, specifically correlation of failures. The second example above demonstrates how a correlated failure in the physical geolocation dimension can cascade into many organization failures.

The antidote to correlation is diversity. Again, using that second example to illustrate, by ensuring that data centers hosting organizations are in diverse locations, we can reduce the impact of any data center outage on our overall quorum configuration. This is the intuition behind decentralization - redundancy in the face of potentially correlated failure.

An exhaustive enumeration of scenarios is out of scope for this article, but by gaming out such scenarios, we can build a picture of the importance of each dimension. Here is the list of dimensions in decreasing order of priority and example threat:

Any organization that runs validators needs to think about what makes sense for their business, and develop and apply a framework to determine their trust configurations. At SDF, we are focused on the growth of the ecosystem and the health of the network, and so when we decide to add new validators to our quorum configuration it's because we want to increase the resilience of the network by adding diversity across one or more of the dimensions listed above. Once we have decided that it is time to consider adding a new validator, we use the 8 dimensions described above to evaluate potential candidates by:

1. Evaluating the organization in each dimension.
2. Paying attention to the most important dimensions.
3. Considering whether that organization improves diversity in some dimensions, relative to the existing quorum configuration of SDF’s validator nodes.
4. Making a final judgment, aiming to increase diversity where possible.

At some point, we may actually determine a formula to measure against the 8 dimensions but for now, we do something a bit messier: we have humans review, make notes, discuss their findings, and come to a consensus on a recommendation. So far, we have been able to come to a clear decision as to whether validators under consideration meet the trust requirements necessary to be included in our quorum configuration.

By illustrating the key considerations that help SDF decide who to trust when configuring its validators, we hope to give you some insight into how Stellar works, into how SDF thinks about our role as a validator, and into what you should think about if you are running your own validators. Of course, every node operator will make their own, independent choices about who to trust, based on their own criteria. By presenting our approach, we aim to provide transparency around SDF’s own trust decisions, and hope to provide things to consider for other network operators as they configure their own quorum so that together we build a more reliable and trustworthy network.

This article was co-authored by Eric Saunders, Giuliano Losa, Anup Pani and Nicolas Barry.

Issuer-Enforced Finality may be an additional consideration for node operators that want a guarantee never to fork from certain asset issuers.

OWASP stands for Open Worldwide Application Security Project, and it’s a nonprofit foundation that works to improve the security of software.