Issuer-Enforced Finality Explained

The Stellar Development Foundation’s mission is to create equitable access to the global financial system, and we believe new, digital representations of money are part of achieving that goal. This will take the work of many different people and projects, all making progress together. That’s why we are following the work of projects like Libra, and were interested to see them announce the next steps for their work. Based on conversations with regulators, they now plan to offer single-currency stablecoins and enhanced compliance and safety models. They are also forgoing their previous plan to transition to a permissionless network.

This question of “permissioned vs permissionless” highlights a key feature of the Stellar network. From the very beginning, Stellar was designed to let entities (safely) issue digital representations of currencies with the certainty of a permissioned network, but the interoperability of a permissionless network. This is made possible by one of Stellar’s most powerful, but least understood, features: Issuer-Enforced Finality.

But what the heck does “Issuer-Enforced Finality” actually mean? And why does it give you the certainty of a “permissioned network?” That’s best answered by comparing two examples.‍

Example 1: Issuing a stablecoin on Ethereum‍

Let’s first consider an entity that issues a dollar stablecoin on Ethereum (call it “e-USD”). Because Ethereum uses proof-of-work to achieve consensus, during its normal operation different (and potentially conflicting) branches emerge as miners verify different blocks. These are usually short-lived, because as soon as one branch gets longer than the other by additional blocks being added, most of the nodes in the network switch over to working on that branch (which is what they’re supposed to do).

A “double spend attack” is when somebody keeps one of these branches alive on purpose and in secret, in order to spend the same tokens twice. A detailed explanation of double spend attacks can be found here, but here’s a quick version: Suppose a fraudster spends some tokens (by transferring them out of their account), and then creates a secret branch of the chain in which those tokens are still in their account. If they have 51% of the total hashing power of the network, they can add new blocks on the secret branch fast enough to keep pace with the rest of the network, and eventually get to a longer chain than the public branch. At that point, the fraudster broadcasts its branch, and the network switches over to that chain because it is longer than the public branch. The fraudster would then be able to spend the tokens for a second time.

The possibility of double spend attacks creates a dilemma for stablecoin issuers. Whenever an account wants to redeem e-USD for fiat USD, they have to wonder if there could be a double spend attack in progress. After sending fiat USD to the owner of the redeeming account, a new chain could be revealed that doesn’t include the redemption transaction, and in which the account that just redeemed no longer has any e-USD!

A situation where a single malicious actor could undermine the system is understandably concerning to regulators. Even if right now it might not make sense for an entity to try to amass the necessary computing power (because the costs of doing so would outweigh the potential payoff), that might not always be the case.‍

The Stellar Consensus Protocol‍

To see how issuing a stablecoin on Stellar compares, we first need a quick overview of the Stellar Consensus Protocol (or “SCP”). Understanding the intricacies of SCP is outside the scope of this post, but here’s how it works at a high level:

Each validator (see footnote 1) on Stellar specifies something called its quorum set, which is the set of n other validators it chooses to trust, and a threshold k (where k ≤ n), which is the number of those other validators it requires for each vote. When that validator is deciding whether to add a new block to the ledger history, instead of confirming that a miner has proved a computational problem (like in proof-of-work), the validator checks if at least k of the nodes in its quorum set agree with adding it. The fact that each validator gets to choose whom to trust is one of the most unique aspects of Stellar.

As long as the quorum sets for two validators intersect “enough,” they will always reach agreement with each other. If the quorum sets for all of the validators overlap “enough” then the entire network will reach consensus.

For the sake of simplicity, we’ve left out two important pieces of understanding SCP. First, to implement this scheme on a real network, the voting process needs to involve multiple rounds of voting to deal with network latency, the fact that new transactions are coming in constantly, and other edge cases. Second, we talked above about quorum sets intersecting “enough” for the network to reach consensus. Precisely defining what “enough” means gets extremely technical. If you’re interested in digging into this more, we encourage you to read our blog post on Why Quorums Matter.

Even though we’re glossing over certain details of SCP, the above overview is enough to see the key characteristic of Stellar for understanding Issuer-Enforced Finality: there is no branching in SCP. A validator on Ethereum is affected by any miner on the network, no matter who they are. If a validator’s ledger currently contains a given ledger history, but a new one (with the appropriate proof by a miner) comes in with a longer chain, then the validator is supposed to immediately switch over to that new history. On Stellar, validators don’t have to update their ledger based on miners, they only have to listen to the nodes in their quorum set (which they get to choose in the first place). As they add new blocks to their ledger history, they will never go back and change them. This makes double spend attacks (as described above) impossible, and opens the door to Issuer-Enforced Finality.‍

Example 2: Issuing a stablecoin on Stellar‍

Now we’re ready to consider issuing a dollar stablecoin on Stellar (call it “s-USD”, and the issuer “Issuer”). Because of how SCP works, we obviously don’t have to worry about a secret branch like in Example 1. But you might ask: Couldn’t the nodes in Issuer’s quorum set collude against them in some other way? They could try, but let’s see why Issuer is still safe.

First off, this is a much less worrying possibility than Example 1. Instead of a single, anonymous miner being able to undermine the integrity of Issuer’s assets, this would require coordination among multiple actors, all of whom are known to Issuer. They presumably will pick nodes for their quorum set managed by entities they trust. And if those other entities do misbehave, Issuer would know whom to go after in the courts.

Second, a colluding quorum set still wouldn’t threaten Issuer like in Example 1. Suppose they have issued 100 s-USD to Alice, and the quorum set nodes decide they’re going to help Alice by letting her spend that 100 s-USD to buy a car from Bob, and then also redeem that same 100 s-USD for fiat USD with Issuer. Carrying out this scheme on Stellar would involve four steps:

1. Alice transfers 100 s-USD to Bob, in exchange for a car.
2. Issuer’s quorum set purposefully omits that transaction from a new block, which Issuer accepts because the nodes in its quorum set have accepted it.
3. Alice then transfers 100 s-USD (which it still looks like she has) to Issuer for redemption.
4. Issuer gives Alice $100.

At first glance, this seems like Issuer is in trouble because Bob is going to be very angry when he realizes that Issuer does not think he has 100 s-USD and therefore can’t redeem. But there’s a simple solution: Issuer makes clear to the world that nobody should believe they have s-USD unless Issuer’s validator says they do. As long as Issuer makes that clear, Bob won’t give Alice the car until he sees 100 s-USD in his account on Issuer’s validator.

If the quorum set carries out the scheme above, when Bob tries to verify he’s received the 100 s-USD, he won’t see it on Issuer’s validator (because of step 2 above). Just as someone would wait for confirmation of a successful bank wire or credit card transaction before handing over the keys to a car, Bob wouldn’t give Alice the car until he could confirm the 100 s-USD in his account (which, by the way, should be almost immediate because Stellar closes a new ledger about every 5 seconds).

Issuer-Enforced Finality, and Why It Matters‍

That is what Issuer-Enforced Finality is. It’s the fact that at the end of the day, the Issuer gets to enforce the authoritative source of truth governing who does or does not own its asset. There is never any ambiguity as to who owns that asset, because everyone knows which copy of the ledger Issuer will consult when it’s time to redeem.

Stablecoin issuers on Stellar should establish (and make very clear to holders) two things: (1) how the asset works off of Stellar, which includes how it is backed (e.g., being backed 1:1 by USD bank reserves) and the procedures for issuance and redemption (e.g., KYC process and payment details), and (2) the validator on Stellar that serves as the authoritative record of ownership. In this way, even though Stellar is a permissionless network, anyone receiving the stablecoin has complete confidence that their ownership will be respected by the issuer, and that they will be able to redeem it (see footnote 2).‍

Issuer-Enforced Finality is just one of the features that makes Stellar a great option for stablecoin (and other asset) issuers. For more information, visit www.stellar.org/learn/the-power-of-stellar or email [email protected].

‍

‍

1. Because Stellar doesn’t have mining, we refer to “validators” instead of miners. Validators are simply nodes that participate in the consensus protocol. More information on the different types of Stellar nodes can be found here.

2. If the issuer is running its own validator, it will presumably choose its own node as the authoritative record. But that doesn’t have to be the case. An entity does not have to run a validator to issue an asset, and could specify someone else’s node as the authoritative node.