Stellar is often described as “a network for cheap transfers,” but that hides most of the architecture. Consensus is neither Proof of Work nor Proof of Stake: the Stellar Consensus Protocol is a Federated Byzantine Agreement system in which each validator selects its own quorum set and threshold. Payment assets are defined by asset code plus issuer, accounts explicitly create trustlines, anchors connect the blockchain with banks and cash rails, and path payments can atomically convert one asset into another through built-in liquidity. XLM ties the system together through fees, account reserves and native settlement utility.
Stellar separates payment-network consensus from the asset layer
Stellar Core validators agree on ledger state, but they do not decide which external currencies are “real.” An issuer creates an asset, an account chooses whether to trust it through a trustline, and an anchor provides the off-chain deposit or withdrawal path.
This separation of responsibilities matters. Consensus ensures nodes apply the same operations. The issuer stands behind its token obligations. The anchor handles movement between blockchain and banking or payment rails. The wallet controls identity, trustline creation and user authorization.
XLM is the only asset without an issuer or trustline
The native lumen has no issuer account and does not require a ChangeTrust operation. Ordinary Stellar assets such as a tokenized dollar are identified by code and issuer public key.
An asset code alone does not identify the money
Two issuers can both create an asset called USD. They are different ledger assets even if a wallet displays the same ticker.
Payment UX hides several independent trust boundaries
A user sees “receive 100 USD,” while an engineer must ask which issuer created it, whether the receiver has a trustline, which anchor handles fiat conversion, which path payment is used and which ledger confirmed the operation.
SCP uses quorum sets and quorum slices instead of mining or stake weight
The Stellar Consensus Protocol implements Federated Byzantine Agreement. Each Core node chooses which other validators it considers sufficient for agreement. That trusted configuration is its **quorum set**.
A node also configures a threshold: the minimum portion of its set required for agreement. Any concrete combination that satisfies the node's requirement is a **quorum slice**.
A quorum is not a fixed protocol committee
The network does not enforce one universal list of validator keys. Each operator configures trust relationships independently. Global safety emerges when quorum sets across independent nodes overlap sufficiently.
Quorum intersection is the central security property
If the network splits into independent validator groups that can each form a quorum without the other, safety can fail. Quorum topology therefore matters at least as much as raw validator count.
Node-blocking sets affect liveness
If a threshold requires three of four trusted nodes, enough unavailable members can prevent that node from making progress. SCP deliberately prioritizes safety and fault tolerance, so under poor connectivity it may stall rather than agree on incompatible ledgers.
In SCP, “how much stake does the attacker own?” is replaced by “which validators sit inside quorum slices and how strongly do trust graphs intersect across independent operators?”
Validators do not receive protocol monetary rewards
Current Stellar Docs explicitly state that validators receive no monetary reward for validation. Organizations operate them because they depend on network security and resilience for their own products and services.
Assets and trustlines make holder consent part of the ledger
A standard Stellar asset is identified by **asset code + issuer public key**. The issuer can issue the asset, while a holder generally needs a trustline to hold it unless it is native XLM.
A trustline is created through a ChangeTrust operation and exists as a distinct ledger entry.
A trustline is more than a social statement of trust
It is an explicit ledger object with asset identity, balance limit and authorization state. An account without the relevant trustline normally cannot receive the issued asset.
A trustline consumes reserve
The current Stellar base reserve is **0.5 XLM**. A normal account must maintain two base reserves, or **1 XLM**. Each additional subentry, including an ordinary trustline, increases the minimum balance by another base reserve, currently 0.5 XLM.
Sponsored reserves allow another account to carry that reserve burden, which is useful for wallet onboarding.
Issuer controls can restrict transferability
Depending on asset design, an issuer can use authorization flags, clawback-related controls and other protocol features. A self-custodied private key does not automatically eliminate issuer policy.
A trustline limit caps the holder balance
A holder can specify a maximum balance. An incoming payment that would exceed the limit fails rather than silently overflowing it.
Anchors connect the Stellar ledger to fiat and external payment rails
An anchor is an organization that accepts an external asset or fiat and issues or distributes a corresponding Stellar asset, or performs the reverse withdrawal. Modern Stellar documentation also calls them ramps.
A typical flow is that a user sends money to the anchor through a bank transfer, completes required compliance, and after funds arrive the anchor sends the issued asset to the user's Stellar account.
SEP standards reduce integration fragmentation
Stellar Ecosystem Proposals define interoperable contracts between wallets and anchors. Common examples include:
- **SEP-1** for discovery through stellar.toml;
- **SEP-10** for web authentication;
- **SEP-24** for interactive deposit and withdrawal;
- **SEP-6** for programmatic transfer APIs;
- **SEP-31** for cross-border payments;
- **SEP-38** for quotes and exchange information.
KYC can happen outside the wallet interface
SEP-24 allows a wallet to open an interactive flow hosted by the anchor. Identity data can be handled directly by the anchor while the wallet receives transaction status and metadata.
Anchor risk is not SCP risk
If one fiat issuer stops redeeming its token, Stellar consensus can continue closing ledgers normally. Token solvency and network consensus are separate failure domains.
One ticker can have several anchors
Multiple anchors can issue their own USD assets. Path payments and market liquidity may connect them economically while the issuer obligations remain distinct.
Path Payments combine payment and exchange in one atomic operation
One of Stellar's most distinctive features is the path payment. A sender can spend one asset while the receiver gets another, with the network using offers on the Stellar DEX and/or liquidity pools to find a conversion path.
Strict Send fixes the sender amount
Path Payment Strict Send specifies the exact amount of the source asset. Destination amount varies with the route and liquidity. destMin protects against an unacceptable conversion result.
Strict Receive fixes the receiver amount
Path Payment Strict Receive specifies the exact destination amount. Source spend varies, while sendMax caps the maximum amount the sender is willing to use.
Settlement is atomic
Intermediate exchanges and the final payment are part of one operation. If no acceptable path exists or slippage protection is violated, the operation fails rather than partially executing.
The receiver still needs permission to hold the destination asset
When the destination asset is not XLM, the recipient normally needs the corresponding trustline. Exchange routing does not bypass the ledger's authorization model.
Pathfinding does not guarantee a good market
A route can exist while shallow order books or liquidity pools produce a poor price. Wallets should display quotes, slippage boundaries and issuer identity rather than only a green Send button.
XLM provides fees, reserves and native network utility
Lumens matter even when a payment itself is denominated in another asset. XLM pays transaction fees, funds account and subentry reserves, and covers smart-contract resource or rent-related costs.
Minimum balance protects the ledger from cheap state spam
The base reserve is currently 0.5 XLM. A baseline account requires two reserves, or 1 XLM. Trustlines, offers, signers and data entries add subentries and increase the reserve requirement.
Closing a subentry makes its reserve amount available again. Sponsored reserves let a product provider fund reserves on behalf of users.
The minimum inclusion fee is 100 stroops per operation
One stroop is 0.0000001 XLM. The current network minimum for a normal operation is **100 stroops = 0.00001 XLM**. A transaction with several operations pays an inclusion fee based on operation count.
During surge pricing the effective fee can rise when demand exceeds configured ledger capacity.
Validators do not receive those fees as block rewards
Fees accumulate in a protocol fee pool; Stellar validators do not earn mining or staking rewards. XLM fee utility and validator incentives are therefore separate topics.
Soroban adds resource fees and rent
Smart-contract transactions use an inclusion fee plus resource charges for computation, IO and ledger state. That is a separate economic layer from classic payment operations.
Ledger and explorer analysis means reading the operation list
A Stellar transaction is an envelope that can contain multiple operations. Operations are applied atomically within the transaction under protocol rules.
Each SCP round agrees on a transaction set to apply to the last closed ledger. A new ledger then cryptographically references the previous ledger.
Sequence numbers protect account ordering
A source account transaction consumes a sequence number. Reusing a stale sequence causes failure and prevents ordinary transaction replay.
Memos matter for pooled custody flows
An exchange can use one deposit account for many customers and distinguish them through memo. Sending to the correct public key without the required memo can require manual recovery by the custodian.
Explorers should expose operations, not only one payment label
One transaction may contain ChangeTrust, ManageSellOffer, PathPayment, Payment or other operations. Debugging requires expanding the full list.
Close time is a consensus field, not an atomic clock
Stellar Docs note that close time depends on the system clock of the proposing validator and may differ slightly from wall-clock time. Ledger sequence and hash are better ordering identities than treating timestamps as perfect latency measurements.
Failure modes span consensus, issuers, anchors and liquidity
A Stellar payment can be fast and inexpensive while the end-to-end user flow still depends on systems outside Core consensus.
- **SCP/quorum risk:** bad quorum topology or unavailable validators can halt progress.
- **Issuer risk:** issued assets depend on issuer policy and reserves.
- **Anchor risk:** deposits and withdrawals depend on banking rails, compliance and operational availability.
- **Liquidity risk:** path payments can fail or quote poorly.
- **Trustline risk:** receiver lacks authorization or reaches its limit.
- **Custody/memo risk:** exchanges may require exact memo routing.
- **Reserve risk:** account lacks XLM for a new subentry.
Network success does not equal fiat settlement success
An on-chain asset can arrive quickly while a bank withdrawal takes much longer. This is not contradictory because blockchain transfer and off-chain settlement are different systems.
Atomic path payment reduces partial-execution risk
If the route stops satisfying sendMax or destMin, the operation fails rather than leaving the user holding an intermediate asset.
Issuer identity should be checked like a contract address in EVM systems
The ticker USD is not enough. A wallet should display issuer domain or public key and rely on verified metadata.
Stellar and XRP Ledger: similar payment intent, different consensus and asset architectures
Stellar and the XRP Ledger are often compared because both target payments, issued assets, integrated exchange or pathfinding functionality, and fast settlement without Proof-of-Work mining.
The implementations are not the same.
Stellar formalizes FBA through quorum sets and slices
Each Stellar Core node configures a quorum set and threshold. Network safety depends on quorum intersection across independent operators.
XRPL consensus also uses trusted-validator relationships rather than stake weight, but validator trust configuration and consensus rounds follow the XRP Ledger's own protocol model. SCP and XRPL Consensus should not be treated as one algorithm simply because their product goals overlap.
Trustline semantics are related in purpose but ledger identity differs
Both systems model issuer relationships for non-native assets. In Stellar, canonical asset identity is code plus issuer and a trustline is explicitly created with ChangeTrust.
Path payment is a first-class Stellar operation
Strict Send and Strict Receive explicitly combine payment with DEX or liquidity routing. XRPL also provides payment paths and pathfinding, but transaction types and liquidity semantics differ.
| Layer | Stellar | XRP Ledger |
|---|---|---|
| Native asset | XLM | XRP |
| Consensus family | SCP / Federated Byzantine Agreement | XRP Ledger Consensus Protocol |
| Non-native asset | Code + issuer + trustline | Issuer/currency + trust line |
| Integrated exchange | Stellar DEX + liquidity pools | XRPL DEX + AMM |
| Payment conversion | PathPayment Strict Send/Receive | Payment paths / pathfinding |
| Validator reward | No protocol reward | No mining or staking reward |
The main conclusion
Stellar is not merely a cheap chain for XLM transfers. It is a **payment graph** where SCP agrees on the ledger, issuers create assets, trustlines express holder consent, anchors connect fiat rails, and path payments use liquidity so sender and receiver can work with different assets.
The engineering question is therefore: **which issuer created the asset, does the receiver trust it, which route converts value, where does anchor risk live, and which quorum relationships secure the settlement ledger?**
FAQ
Does Stellar use Proof of Stake?
No. SCP is based on Federated Byzantine Agreement. Validators choose quorum sets and thresholds; XLM stake does not determine consensus voting weight.
Does XLM require a trustline?
No. XLM is Stellar's native asset and has no issuer. Trustlines are used for ordinary issued assets.
How much XLM does a normal account need?
The current base reserve is 0.5 XLM. A baseline account needs two base reserves, or 1 XLM, unless reserves are sponsored. Subentries such as trustlines increase that requirement.
What does an anchor do?
An anchor or ramp connects a Stellar asset with external money rails: it accepts deposits, issues or distributes the corresponding asset and handles withdrawals under KYC, banking and issuer rules.
What is the difference between Strict Send and Strict Receive?
Strict Send fixes the source amount and protects the minimum destination result with destMin. Strict Receive fixes the destination amount and caps source spend with sendMax.
Do Stellar validators earn XLM rewards?
No. Current Stellar Docs explicitly state that validators receive no protocol monetary reward for validation.
This material is educational and does not constitute financial advice or a guarantee of issuer or anchor liquidity.