What is Stellar?

Introduction

Stellar is a public blockchain designed to move money and other assets across accounts, currencies, and jurisdictions with low cost and fast finality. That sounds similar to many payment-focused networks, but Stellar is built around a more specific problem: how do you coordinate transfers between parties who may not share the same currency, may not know each other, and still need a ledger everyone can treat as authoritative within seconds rather than minutes or days?

The interesting part is not just that Stellar is fast. Many systems can be fast in easy conditions. The harder problem is being fast while preserving a single shared ledger for financial activity. If two sides of a payment disagree about what happened, or if the network keeps moving during uncertainty and later forks, then the apparent speed was an illusion. Stellar’s design starts from that constraint. It would rather stop briefly than produce conflicting histories.

That choice explains much of the network. It explains why Stellar’s consensus mechanism looks different from proof-of-work chains, why validator configuration matters so much, why operators talk about quorum sets and intersection, and why the network has become associated with cross-border payments, tokenized assets, and exchange between currencies. It also explains where the model is powerful and where it is fragile.

At a high level, Stellar offers three things together. It provides a shared ledger, a native asset called XLM or lumens, and protocol features aimed at payments and asset issuance. The official project describes Stellar as supporting borderless payments, asset tokenization, and DeFi, and its developer documentation frames the network as a place to build applications, smart contracts, and asset-based systems. But the reason these applications fit Stellar is not branding. It is the network’s underlying structure: a ledger optimized for fast agreement and value movement rather than for open-ended computation alone.

What problem does Stellar solve for cross‑border payments and asset transfers?

Most financial transfers are not just about sending a number from one address to another. In the real world, value often sits inside separate systems with separate assumptions: a bank ledger, a mobile wallet, a stablecoin issuer, a tokenized asset platform, or a local currency network. The friction comes from coordination. Each system may be internally consistent, but moving value between them is slow, expensive, and operationally messy.

Stellar’s answer is to make the ledger itself a coordination layer. Instead of treating on-chain value as only a single native coin, the network is designed to represent many issued assets and to settle transfers between them on one shared state machine. Its reference implementation, stellar-core, is described as a replicated state machine that maintains a local copy of a cryptographic ledger and processes transactions in consensus with peers. That phrase matters. A replicated state machine is not merely a database copied around the internet. It is a machine that many nodes advance together, step by step, so that the same ordered inputs produce the same resulting ledger.

Once you see Stellar that way, the design focus becomes clearer. The network is not mainly trying to maximize blockspace for arbitrary computation. It is trying to make agreement on state transitions quick and dependable enough for payment flows, issued assets, and exchange between assets. The homepage emphasizes low cost and fast settlement. Operator documentation says nodes generally reach consensus, apply a transaction set, and update the ledger every 3–5 seconds. That is not a promise that every application sees the same end-to-end experience, but it is the cadence the protocol is designed around.

This is also why Stellar includes a decentralized exchange mechanism for tokenized assets and currency pairs. If the network’s job is to move value across asset boundaries, then trading and pathfinding are not bolt-on ideas; they are part of the settlement problem. A user who wants to send dollar-denominated value to someone who wants to receive another asset does not care whether the conversion happened through one market or several. What matters is that the ledger can represent the route and settle the result coherently.

How does Stellar use local trust choices to produce global agreement?

The deepest idea in Stellar is that consensus does not begin from a single globally fixed validator set. Instead, each validator declares which other validators it is willing to rely on. Those local trust choices combine into a larger structure that may or may not support global agreement.

This model is called federated Byzantine agreement, or FBA. In the Stellar Consensus Protocol whitepaper, the basic unit is a quorum slice: a set of nodes sufficient to convince a particular node. A node can have one or more such slices. From those slices, larger quorums emerge. A quorum is a set of nodes large enough that each member sees within that set a slice it trusts. The network does not start by saying “these 100 validators are authoritative.” It starts by saying “each node has made its own trust choices,” and then asks what global structures those choices imply.

That sounds abstract, but the mechanism is intuitive. Imagine several institutions each saying, in effect, “I consider the ledger confirmed if enough of these organizations agree.” If their choices overlap in the right way, agreement can spread through the network and stabilize on one ledger state. If their choices are fragmented or poorly aligned, then the network can lose liveness or even lose the conditions needed for safe agreement.

The key condition is quorum intersection. The whitepaper states this bluntly: agreement can be guaranteed only if any two quorums intersect. In ordinary language, any two sufficient groups for confirming the ledger must share at least one node. Why does that matter? Because if two disjoint groups could each finalize different outcomes without any overlap, there would be no structural reason for them to remain consistent. Intersection is what forces independently trusted groups back into a single shared reality.

This is the point where many readers misunderstand Stellar. They hear “nodes choose whom they trust” and infer that consensus is subjective in the loose sense that everyone can believe whatever they want. That is not the right picture. The local trust is subjective at the configuration level, but safety is objective at the network level. Either the chosen quorum slices produce enough overlap for agreement, or they do not. The flexibility is real, but so is the constraint.

How does the Stellar Consensus Protocol (SCP) reach agreement in practice?

The protocol that implements this model is the Stellar Consensus Protocol, or SCP. The whitepaper describes SCP as combining decentralized control, low latency, flexible trust, and asymptotic security. Those are not marketing adjectives glued together; they describe the intended tradeoff. Anyone can participate, nodes can choose trust relationships, confirmation can happen quickly, and safety does not depend on burning electricity or on a fixed committee blessed by a central operator.

Mechanically, SCP has two cooperating parts: a nomination protocol and a ballot protocol. The nomination phase is how nodes converge on candidate values for a given ledger slot. The ballot phase is how they turn a candidate into a prepared and then committed outcome while handling conflicting proposals safely.

A worked example makes this easier to see. Suppose the network is about to close the next ledger. Different validators have seen overlapping but not identical transaction sets from clients and peers. If they tried to jump straight to final commitment, they could easily talk past each other. So the nomination phase acts like a way of narrowing the conversation: nodes begin proposing values, observe what trusted peers are nominating, and gradually accumulate a candidate set with enough support to be worth advancing.

But nomination alone does not finalize anything. Nodes still need a way to commit to a specific outcome without risking two incompatible commitments. That is where the ballot protocol matters. Nodes move through statements that let them prepare, commit, or abandon ballots as evidence from their trusted quorums evolves. The details are formal and subtle, but the intuition is simple: SCP is trying to let nodes make progress when there is enough overlapping support, while preventing them from stepping into contradictory final states.

The operator-facing documentation gives the practical result: nodes generally update the ledger every few seconds. That speed comes from not having to wait for long proof-of-work confirmation windows. But it is not free. It depends on validators being online, well configured, and connected through quorum sets that preserve intersection.

How can Stellar finalize ledgers quickly without mining or staking rewards?

Stellar does not use proof-of-work mining. It also does not use staking rewards in the familiar proof-of-stake sense. Consensus comes from validator agreement under SCP, not from expending energy or from locking up stake for block production rewards.

That has several consequences. The first is obvious: the network avoids the resource cost of proof-of-work. The SCP paper explicitly contrasts this with the electricity use and settlement latency associated with proof-of-work systems. The second consequence is more subtle: without mining races or probabilistic longest-chain competition, Stellar can aim for fast confirmation around each ledger close.

The third consequence is governance-shaped rather than purely technical. In networks where consensus participation is driven by block rewards, the validator or producer set is partly organized by economic incentives baked into the protocol. In Stellar, participation is more institutional and reputational. Organizations run validators because they want the network to exist, want influence over the ledger they depend on, or want to help provide infrastructure and trust to others. The validator docs even note that signatures from validators can serve as authoritative endorsements for issuers or operators who need an official ledger view in disputes.

This helps explain both Stellar’s strengths and its operational burden. The network can support a payments-oriented experience without mining overhead. But it also relies on real organizations maintaining nodes, coordinating upgrades, publishing history, and configuring trust relationships responsibly. The social layer is not optional decoration here. It is part of the system’s safety envelope.

What roles do Stellar validators play and how should they be operated?

A validator in Stellar is a node running Stellar Core that participates in consensus to validate transactions and determine network settings. That phrase “determine network settings” matters because validators are not only ordering user transactions. They also participate in changes to network-wide parameters and upgrades.

The docs distinguish between Basic Validators and Full Validators. A basic validator participates in consensus and tracks the ledger but does not publish history archives. A full validator does both consensus and history publication. That history archive is not incidental bookkeeping. It helps other nodes catch up and improves network resilience by making ledger snapshots publicly available.

The operational guidance is also revealing in what it doesn’t recommend. A validator node should not be the same machine you use for application data access or transaction submission. For those purposes, the docs point developers toward non-validating infrastructure such as Stellar RPC nodes for simulating and submitting transactions and querying current state, or Galexie nodes for retrieving and storing network data at scale. This separation reflects a mature network design: validation is one job, application serving is another, and trying to collapse them can make both worse.

The docs also describe a socially important category: Tier 1 organizations. These are organizations whose validators are widely included in other participants’ quorum sets, meaning they carry disproportionate responsibility for the network’s safety and liveness. The Stellar guidance recommends that such organizations typically run three geographically dispersed full validators so others can require agreement from two out of three. That arrangement is not mathematically magical. It is a redundancy pattern that lets one machine fail without causing the organization to disappear from consensus.

Notice what this implies about decentralization in Stellar. It is not captured well by simply counting nodes. What matters is which organizations other validators actually depend on. A network can have many validators on paper while still concentrating practical consensus weight in a much smaller set of trusted institutions.

When is Stellar a good fit for payments, issued assets, and tokenized flows?

Stellar is well suited to systems where the hard part is not arbitrary computation but coordinated movement of value. That includes cross-border payments, issued assets, tokenized representations of off-chain value, and flows where users want one asset but pay with another.

The reason is architectural. Stellar treats assets and settlement as first-class concerns. Its built-in support for tokenized assets and exchange means the ledger can express not just “Alice sent XLM to Bob,” but more complex payment routes where one asset is converted into another during settlement. For institutions and fintech products, that can be more useful than a chain that is theoretically general-purpose but requires much more application-level machinery to recreate the same economic flow.

Fast ledger closes and low transaction costs reinforce that fit. The public site highlights low average transaction cost and short settlement time, while operator documentation frames consensus as updating the ledger every few seconds under normal conditions. For payment experiences, that changes what is practical. If a transfer can become authoritative quickly and cheaply, the application does not need to hide as much uncertainty behind delayed settlement windows.

The network also supports smart contract development through the broader developer stack, including Soroban-related documentation and tools in the docs portal. That matters because Stellar today is not just a narrow payment rail. But even there, the through-line remains the same: the network’s identity starts from payments and asset movement, then extends outward, rather than starting from unconstrained computation and hoping finance will fit later.

What operational and safety risks stem from Stellar's federated trust assumptions?

The most important thing to understand about Stellar is that its consensus safety is conditional on how validators choose quorum slices. The SCP paper is explicit: SCP can guarantee safety only when nodes choose adequate quorum slices. This is not a minor implementation detail. It is the central operational risk.

If quorum intersection is lost, the network can no longer rely on the structure that forces independent validator groups into one shared outcome. Even before full safety failure, poor configuration or correlated downtime can threaten liveness. Because Stellar prefers consistency over liveness, the network may halt rather than continue under uncertainty.

That is not hypothetical. An official incident report describes a 67-minute network halt on May 15 caused by inability to reach consensus. No ledgers were closed and no transactions were processed during that period. Yet the report emphasizes that ledger state remained safe and consistent and that no funds were lost. The protocol behaved as designed: a temporary stop was preferred to a forked or inconsistent ledger.

The causes were operational, not a cryptographic break in SCP. The report points to misconfigured or down validators, new nodes taking on too much consensus responsibility too soon, and maintenance at a fragile moment. This is a useful lesson because it shows where Stellar’s real difficulty lives. The elegant theory of federated trust does not remove the need for careful network stewardship; it makes that stewardship more important.

A second incident, involving SDF-operated validators and the public SDF Horizon API going offline, showed a different distinction. The broader network remained online and continued processing transactions because enough other validators were still functioning. In other words, provider infrastructure can fail without the whole network failing. That is what decentralization is supposed to buy. But users who relied on a single public API endpoint still felt downtime. So there are two layers of resilience to think about: consensus resilience and service-access resilience.

There is also a more theoretical limit. Research in 2023 argued that under a specific minimal-knowledge model called Consensus with Unknown Participants, Stellar cannot solve consensus with only the initial knowledge available in that model, even though related protocols can, unless participant knowledge is augmented with an oracle such as a proposed sink detector. This does not mean “Stellar is broken.” It means the exact information assumptions behind federated consensus matter, and some stronger assumptions are doing real work even if application developers never see them directly.

How was XLM issued and what is Stellar’s supply model?

The native asset of Stellar is XLM, also called lumens. XLM is useful inside the network as a native unit, including as a bridge asset in multi-currency flows, but Stellar’s economic design is not centered on mining issuance.

Historically, the initial supply was created by the Stellar Development Foundation rather than mined over time. A former 1% annual inflation mechanism was later removed by community vote in 2019. That same year, SDF announced a large burn of lumens, including 5 billion from its operating fund and 50 billion from giveaway programs, leaving about 50 billion lumens in existence according to the announcement. The burn was performed by sending lumens to an account with no signers.

These details matter because they shape how readers should think about Stellar. Some networks distribute power through ongoing issuance to miners or stakers. Stellar instead has a native asset embedded in a network whose consensus is validator-driven and whose supply history has been heavily influenced by foundation stewardship and later reductions. That does not by itself tell you whether the model is good or bad, but it does tell you that token economics and consensus participation are less tightly coupled here than in many proof-of-stake systems.

How do you build and connect applications on Stellar today?

The current Stellar documentation reflects a broader platform than older summaries sometimes suggest. The docs are organized around building applications and smart contracts, learning the fundamentals of accounts, transactions, fees, and consensus, working with deployed networks such as Mainnet, Testnet, and Futurenet, and using tools like SDKs, CLI tooling, Quickstart, RPC, and data services. That breadth matters because many readers still think of Stellar only as a payments chain from an earlier era.

At the same time, the infrastructure story is evolving. The docs list multiple data access paths, including RPC, Hubble, Galexie, the Ingest SDK, and Horizon, with Horizon explicitly marked as deprecated. That is a practical reminder that “what Stellar is” at the protocol level is different from “how developers connect to it” at the tooling level. The network can remain conceptually stable while APIs and operational patterns change.

For developers, the important takeaway is straightforward. If you are building on Stellar, you are not only choosing a blockchain. You are choosing a ledger model optimized for assets and payments, a consensus model based on federated trust, and an ecosystem where production-grade reliability depends heavily on using the right infrastructure layers for the right jobs.

Conclusion

Stellar is best understood as a shared financial coordination ledger: a public network built to move value across assets and institutions quickly, cheaply, and with strong emphasis on a single consistent history. Its defining innovation is not merely fast settlement, but the way it reaches agreement through federated Byzantine agreement, where validators choose local trust relationships that must still produce global quorum intersection.

That design gives Stellar its character. It can settle ledgers in seconds without mining, support asset issuance and exchange naturally, and remain online even when some major operators fail. But it also depends on careful validator configuration, real institutional coordination, and the willingness to halt rather than fork when confidence in consensus breaks down.

If you remember one thing tomorrow, remember this: Stellar is a payments-and-assets network whose speed comes from structured trust, not from ignoring the hard parts of consensus.

How do you buy Stellar (XLM)?

How do you buy Stellar (XLM)? Buy XLM on Cube Exchange by funding your account and placing a spot order on the XLM market. The workflow below shows the standard Cube sequence: fund, open the XLM spot market, pick an order type (market for immediate execution or limit for price control), and place the order.

1. Deposit USD or USDC into your Cube account using the fiat on‑ramp or send a crypto transfer to your Cube USDC address. If you plan to deposit XLM from an external wallet instead, choose the Stellar network and include any required memo.
2. Open the XLM/USDC (or XLM/USD) spot market on Cube Exchange from Markets → Spot → XLM. Confirm which trading pair and quote currency you will use.
3. Choose an order type: select Market to buy immediately at the best available price or Limit to set the exact XLM price you want. For limit orders, enter your target price and quantity.
4. Enter the XLM amount or the fiat/USDC amount you want to spend, review estimated fees and expected fill or slippage, and submit the order.
5. (Optional) Withdraw purchased XLM to a Stellar wallet: select Withdraw → XLM, choose the Stellar network, paste the destination address, and add the destination memo if the recipient requires one.