Skip to content
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
140 lines (101 sloc) 4.25 KB
SEP: 0020
Title: Self-verification of validator nodes
Author: Johan Stén <>
Track: Standard
Status: Draft
Created: 2018-05-06

Simple Summary

Using Stellar accounts to link validator nodes to the entities operating them.


SCP depends on knowing the identies of the nodes you add in your quorum slice and thus choose to listen to. When discovering or verifying validators in the Stellar network it is useful to have a clear link between the nodes and their identity in the wider internet.

So who do you listen to? And how do you know what nodes belong to them?

Just as Stellar uses federation for anchors, and federated address lookups, we suggest using the same mechanics for a baseline level of verification of validator nodes.


There is currently no standard way for publishing node metadata. We need better scalability, better discoverability, more decentralization, better information quality.



  • Create an account for the validator node you operate
  • Set the account homedomain to your website
  • Create a stellar.toml file in /.well-known on the website server
  • Add your validator node to the stellar.toml file

This creates a two-way link between the node and the website of the operating entity, uniquely identifying it.

Stellar.toml metadata

Please refer to SEP-00011 for specifics on how this works.

Whereas SEP-0001 is primarily targetted at asset issuers, the idea is to re-use as much from SEP-0001 as makes sense.

At an absolute minimum, OUR_VALIDATORS MUST be used since that is what creates a link from the website back to the validator node.

Recommended fields would be:

NODE_NAMES - to give display names to the nodes listed in OUR_VALIDATORS

Example code for linking

const userKeys = StellarSdk.Keypair.fromSecret(...);

// validator node NODE_SEED
const nodeKeys = StellarSdk.Keypair.fromSecret(...);
const nodeId = nodeKeys.publicKey();

// the
const homeDomain = '...';

const account = await server.loadAccount(userKeys.publicKey());
const tx = new StellarSdk.TransactionBuilder(account,  {fee: 100})
        destination: nodeId,
        startingBalance: '1'
        source: nodeId,
        homeDomain: homeDomain


const result = await server.submitTransaction(tx);

Example look-up

MacBook-Pro:~ Johan$ curl
  "home_domain": "",

MacBook-Pro:~ Johan$ curl

Design Rationale

Federation is well-established as a building block for protocols built on Stellar.

Validator nodes have keypairs and are already using public keys as their identity, so it's not much of a stretch to add accounts into the mix, in order to start using reverse federation as a means of looking up metadata associated with a specific validator node.

Security Concerns

With a validator node account linked to a homedomain stellar.toml file like suggested, we're really relying on the integrity of the stellar.toml file and the server it resides on, making sure it only has write access by authorized users.

Additional security measures that could be taken include signing the stellar.toml file with the validator key(s), and serving in a file next to the stellar.toml file.

Another thing might be to add DKIF2-style protection, and sign the stellar.toml file with a private key unrelated to the validator node(s), and publish the public key in the DNS response.

These are most likely the topic of a SEP by themselves.



You can’t perform that action at this time.