Non-block ledger

Stellar ticker XLM

No public-data lookups yet
5 reviewed developments
40 cited sources

Summary

Stellar Core nodes run the Stellar Consensus Protocol, a form of federated Byzantine agreement. Each validator picks its own quorum set (the nodes and organizations it trusts) and a threshold; a statement becomes safe to act on once enough overlapping trusted groups have voted, accepted and confirmed it. Each round has a nomination stage that converges on candidate transaction sets and a ballot stage that prepares and commits one set, which is then applied as the next ledger, generally every 5 to 7 seconds. Sybil resistance comes from real-world trust choices rather than stake or work: validators are not paid, and the Tier 1 group of organizations, each running three validators, is the set most others require agreement from (10 organizations in the docs' example Mainnet configuration as updated in August 2026). 2 3 4 5 9 14 16 23

Design

System: Non-block ledgerStellar's own documentation calls it a layer-1 blockchain, and each ledger carries the hash of the previous one back to the genesis ledger. It is filed with non-block ledgers here because there is no mining, no block reward and no fork choice: validators agree on each ledger through federated voting among organizations they chose to trust, and the network halts rather than forks when they cannot agree. Block-production measures are therefore replaced by ledger closes.
Settlement family: Its own design
Scarce resource: Reputation
State model: Accounts
Finality: Other
Who makes blocks: Every validator crafts a candidate transaction set from the valid transactions it has seen. Nomination uses a per-round leader election: each node weights organizations by the quality rating it gave them in its own configuration (not by stake), nodes adopt the leaders' candidates, and the protocol converges on one set, its close time and any network upgrades. There is no fixed or stake-weighted proposer and no reward for proposing.
Fork choice: No weight-based fork choice. A ledger closes only when a node's quorum slices confirm the same transaction set, so conflicting ledgers would require quorums that do not overlap in well-behaved nodes. Keeping that overlap depends on how operators configure their quorum sets, which Tier 1 organizations coordinate off-chain. When agreement is impossible the network stops closing ledgers instead of splitting.

Qualifications

System class · Contested. Filed with non-block ledgers because there is no mining, block reward or fork choice and each ledger closes by federated voting. Stellar's own documentation calls it a layer-1 blockchain and each ledger carries the hash of the previous one, so a reviewer following the project's self-description could class it as a base-layer blockchain instead.
Scarce resource · Contested. Voting weight comes from being included in other validators' quorum sets, not from work, stake or storage: validators are not paid, and a new organization matters only once others choose to trust it. It is recorded as reputation, the class for designs in which each node picks whom to trust. Because that trust is set per node by configuration rather than earned or measured on the ledger, some readers would file it as another kind of resource.
Finality · Applies. A ledger is final once it closes: nodes act only on transaction sets confirmed by their quorum slices, and there are no reorganizations while quorums overlap in well-behaved nodes. If quorums cannot agree, the network stops closing ledgers rather than forking, as in the 67-minute halt of May 2019. No stake is slashed if the trust assumptions fail, so it is not economic finality in the proof-of-stake sense.
Block metrics · Not applicable. Stellar closes hash-linked ledgers through federated voting instead of mining blocks, so hashrate, block reward, orphan rate and reorganization depth do not apply. Ledger close interval (about 5 to 7 seconds) is the nearest equivalent.
Staking and validator rewards · Not applicable. There is no staking and no payment for validating. Fees go to a locked fee pool that no account controls, and all lumens were created at launch apart from inflation that validators ended in October 2019.
Validator decentralization · Contested. Anyone may run a validator and choose whom to trust, but the network's safety and liveness rest on a Tier 1 group that joins only when existing Tier 1 organizations add it to their quorum sets, and quorum changes are coordinated off-chain. The docs' example Mainnet configuration, described as containing all current Tier 1 validators, listed 10 organizations running 30 validators after its 25 August 2026 update. The foundation describes the 2019 halt as the protocol working as intended and rejects the over-centralization reading.
Ledger state immutability · Contested. The foundation says Stellar's transaction history stays immutable and that no recorded transaction was changed. Still, the Protocol 24 upgrade (October 2025) amended 394 never-restored archived contract entries that a Protocol 23 bug had stored with stale values, and since Protocol 26 validators can vote to freeze specific accounts, trustlines and contract entries. Both are narrow, on-chain and auditable, but they show that validator votes can block or correct particular entries.
Evm compatibility · Not applicable. Smart contracts run on Soroban as Rust compiled to WebAssembly, so EVM compatibility does not apply.
Settlement family · Partial. Recorded as other: Stellar settles on its own ledgers, which Stellar Core nodes close through the Stellar Consensus Protocol (Stellar's terms); each ledger is final once it closes, and nothing settles to another chain. None of the named settlement families describes this.

Tradeoffs

This view follows one way of thinking about design priorities, often called the blockchain trilemma. The design-priorities lesson sets out the counter-view. Read the design-priorities lesson.

Emphasizes

Security and Decentralization Contested

Gives up

Liveness, throughput headroom and, in practice, breadth of consensus. The design prefers halting to forking, so the network stops when quorums cannot agree (it halted for 67 minutes in May 2019). Validators cap the work in each ledger and make storage writes much more expensive once live state passes a target size, which keeps node requirements modest at the cost of throughput headroom. Safety and liveness rest on a small Tier 1 group (10 organizations in the docs' example configuration), admitted through existing members' trust choices and coordinated off-chain.Security here means safety-first finality, not economic security: no stake can be slashed, and the guarantee depends on well-configured, overlapping quorum sets. Decentralization means open membership, no stake or payment needed to validate, and modest node hardware. That reading is contested: network safety and liveness rest on a Tier 1 group (10 organizations, the foundation among them, in the docs' example configuration) admitted by other organizations' trust decisions, and the foundation held about 15.6 of roughly 50 billion lumens in the docs' July 2026 snapshot.

Full node at home

Practical at home 14 15 16Stellar's validator guide recommends 8 vCPUs at 3.4 GHz, 16 GB RAM and a 100 GB NVMe SSD (10,000 IOPS), verified against production nodes in April 2024, and puts the typical working set at 30 to 60 GB (the page was last updated in August 2026; the storage estimate carries no separate date). A validator needs an open peer port and an accurate clock. Nodes that publish full history put multi-terabyte archives on separate object storage, and Tier 1 organizations run three separate nodes. Hardware for the separate data services was not reviewed.

Throughput claims

Theoretical peak 11 14 15Theoretical peak; not comparable across chains or with observed load.Ledger capacity set by validators, not a rate: 1,000 non-contract operations and up to 2,000 contract transactions per ledger on Mainnet (July 2026). No per-second figure is given.Settings as documented in July 2026; validators can change them by vote.Not tied to a stated hardware profile. The validator hardware recommendation was last verified in April 2024.A configured ceiling is not observed load; surge pricing starts only when submitted work exceeds it. Smart contract capacity is also bounded by per-ledger resource limits (instructions, reads, writes and bytes), so the transaction count alone overstates what heavy contracts can use. The figures ignore state growth and history-archive bandwidth, which the validator guide names as the main cost drivers for archive-publishing nodes.

Headline figures are not comparable across chains. A theoretical peak is never a like-for-like number.

Scaling layers

Starlight (Stellar Development Foundation prototype) · Payment channels, research 24 27
A prototype two-party payment channel protocol that relied on transaction preconditions added in Protocol 19 (relative timelocks and relaxed sequence checks). Its README offered it for experiments on the test network or a local network and marked it not for production or for assets with real value; the repository was archived read-only on 23 April 2024. No production channel network on Stellar was found. (as of Sep 27, 2026)

Capabilities

Capabilities of Stellar: how each one is provided, or its research status
Capability	How it is provided	Notes and sources
Account abstraction	Structured assessment pending	Not yet assessed for any chain.
Atomic swaps	Built into the protocolLimited scope	Limited to exchanges on Stellar itself. A transaction may carry operations from several accounts, each signed by its owner, and it applies all-or-nothing, so two parties can exchange assets in one transaction without an intermediary. Path payments also convert through the built-in order book and liquidity pools inside one operation. The docs describe hash-preimage signers as especially useful for atomic cross-chain swaps; those are a building block for swaps with other networks. 7 8 12
Authenticated data publication	Unknown	Not yet assessed under the current definitions; the reviewed features keep data in ledger state: accounts can store small name and value pairs (up to 64 bytes each) with the manage data operation, and contracts store their own data. The current definition does not count data held only in chain state, no other publication feature was found, and absence was not exhaustively verified. 10
Light clients	Unknown	Not yet assessed under the current definitions; no documented light-client path that lets an end user verify consensus without a full node was found. The documented data services (Stellar RPC and Horizon) are servers a user trusts unless they run one, and nodes catch up from hash-linked history archives. 14 20
Native staking or delegation	Structured assessment pending	Not yet assessed for any chain.
On-chain governance	Structured assessment pending	Not yet assessed for any chain.
Parallel execution	Structured assessment pending	Not yet assessed for any chain.
Payment or state channels	Partial (layer not stated) Earlier definition	Protocol 19 added transaction preconditions whose stated goal includes enabling off-chain payment channels, and the foundation built the Starlight prototype on them, but that repository is archived and no production channel network was found. 24 27
Programmable spending	Native (protocol or core-team software) Earlier definition	Classic accounts support weighted multisignature thresholds, pre-authorized transaction hashes, hash-preimage signers and transaction preconditions such as time bounds and relative timelocks. Since February 2024 Soroban adds WebAssembly smart contracts, including contract accounts with custom authorization; Protocol 27 added first-class delegation of that authorization. 6 7 8 13 19
Protocol-verified messaging	Structured assessment pending	Not yet assessed for any chain.
Reversible transfers or recovery	Built into the protocolLimited scope	Part (a) through built-in claimable balances: a sender can create a balance with time conditions so that it reclaims the funds if the recipient has not claimed in time. Part (b) is not met by the protocol: relative timelocks (Protocol 19) are building blocks for time-delayed key recovery set-ups, not a defined recovery role. Issuers can enable clawback on their own assets and burn balances from holders for fraud, regulatory action or lost-key recovery; that is issuer control over holders, and lumens have no issuer and cannot be clawed back. 17 18 24
Rollups	Unknown	Absence was not verified, so the rule that absence needs a source makes this unknown rather than not present. The earlier review found no rollup settling to Stellar in the reviewed documentation or release notes; Protocol 25 and 26 added zero-knowledge proof building blocks, which are not a rollup. 13 21
Shielded transfers	Structured assessment pending	Not yet assessed for any chain.
Signed partial offers	Not present	A Stellar offer is a standing order stored as a ledger entry in the protocol's built-in order book, and the protocol liquidity pools hold pooled reserves. Neither lets a maker sign one side of a trade that any taker completes in one transaction: the order book is a Layer C venue whose orders are ledger entries, and a pool holds the assets before any trade. 12

Reading these values

How this feature is provided: Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
Structured assessment pending: The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
Unknown: The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
Earlier definition: Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
Reading across rows: The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.

Definitions, schema version and review history

Ecosystem & custody

Ecosystem products for Stellar
Product type	Status	Notes and sources
Automated market makers	Native to the protocolStellar order book (protocol), Protocol liquidity pools, Aquarius, Soroswap	The ledger itself includes an order book and constant-product liquidity pools with a fixed 0.30% fee, used together by path payments. Smart-contract venues include Aquarius (its own Soroban AMM) and Soroswap (an AMM and aggregator that also routes through Phoenix and the built-in order book). Liquidity depth was not reviewed. 12 37 38 As of Sep 27, 2026.
Issuer-native stablecoins	Established in the ecosystemUSDC (Circle), EURC (Circle)	Circle lists USDC and EURC issued directly on Stellar as classic assets with Circle issuer accounts. Native here means issuer-issued on Stellar, not a protocol asset; issuers keep the asset controls the protocol gives them. Tether's own protocol list does not include Stellar; USDT0 on Stellar is a LayerZero-based representation backed by USDT locked on Ethereum, recorded under bridges. 28 29 32 33 As of Sep 27, 2026.
Algorithmic stablecoins	Unknown	Algorithmic or collateral-debt stablecoins on Stellar were not reviewed. As of Sep 27, 2026.
Bridges	Established in the ecosystemCircle CCTP, Axelar (GMP and Interchain Token Service), USDT0 (LayerZero OFT), Allbridge Core	Circle's cross-chain transfer protocol lists Stellar and requires a forwarding contract for transfers into Stellar. Stellar's docs list Axelar for cross-chain messages and tokens. USDT0 publishes a Stellar deployment. Allbridge Core says its Stellar support is temporarily unavailable while its Stellar CCTP implementation is pending audit. Risk: Each route adds its own trust: Circle attestations for CCTP, Axelar's validator set and hub for Axelar, and LayerZero verifier networks plus a multisig-owned Ethereum lockbox for USDT0. Circle warns that CCTP transfers to a Stellar account without its forwarding contract become permanently stuck. A bridged token is only as sound as its origin asset and route. 21 30 31 33 34 35 36 As of Sep 27, 2026.
Block explorers	Established in the ecosystemStellarExpert, StellarChain, Stellar Explorer (steexp), Soroscan	Stellar's developer docs list these explorers; Soroscan is described there as newer and under active development. Listing is not a quality or completeness check, and explorer data is provider-indexed. 22 As of Sep 27, 2026.
Hardware wallets	Established in the ecosystemLedger, Trezor	See custody rows: both vendors list Stellar in their own apps. Support for Stellar issued assets such as USDC in those apps was not verified. 39 40 As of Sep 27, 2026.

Hardware-wallet custody

Hardware-wallet custody for Stellar
Device maker	Status	What users can and cannot do
Ledger	Native supportSame as native: Yes	Can: Set up and manage a Stellar account holding XLM in the Ledger Wallet app with keys on a Ledger deviceLedger's page covers XLM; whether issued Stellar assets and Soroban contract interactions can be signed in Ledger Wallet was not verified. 39 As of Sep 27, 2026.
Trezor	Native supportSame as native: Yes	Can: Send and receive XLM in the Trezor Suite app on Trezor Safe 3, Safe 5 and Safe 7 Can: Sign with a Trezor through third-party apps Trezor lists: Exodus, Stellar Account Viewer and StellarTermTrezor's page covers XLM; support for issued Stellar assets in Trezor Suite was not verified. 40 As of Sep 27, 2026.

Public data

iKnow Blockchain has no public-data lookups for Stellar yet. This is a limit of the service, not a statement about the network.

Public-data lookups for Stellar
Lookup	Status	What it covers and its limits
Address or account	Not available yet	Public-data lookups for this chain are not built yet.
Tokens and assets	Not available yet	Public-data lookups for this chain are not built yet.
NFTs	Not available yet	Public-data lookups for this chain are not built yet.
Transactions	Not available yet	Public-data lookups for this chain are not built yet.

A lookup covers one address or transaction from one provider. It is never a complete wallet, and an error or private value is reported as unknown, not zero. About public data · Connect your AI

Sourced developments

Developments: Review overdue Reviewed Sep 27, 2026; next review was due Oct 7, 2026, 12:00 UTC.

Publication date · newest first

Published Sep 16, 2026ProtocolVerified against sources

Protocol 28 (Adapter) activated on Mainnet with earlier consensus voting and shared contract code

Protocol 28 took effect on Mainnet on 16 September 2026 at the scheduled 17:00 UTC vote; the foundation had announced it on 13 August 2026, the day stellar-core v28.0.0 was released. It lets validators begin voting before a full transaction set arrives and vote to drop a late or invalid set, lets many contracts point at one shared, upgradable piece of code, and makes contract data easier to migrate.
- Proposal:CAP-83, CAP-85 and CAP-86 listed for Protocol 28
- Implementation:stellar-core v28.0.0 released 2026-08-13
- Release:stable releases scheduled from 13 to 21 August 2026
- Activation:active on Mainnet from ledger 64458446, closed 2026-09-16T17:00:06Z; parallel transaction-set downloading is to be enabled gradually afterwards
Date basis: Activation from Horizon ledger records: ledger 64458446 (2026-09-16T17:00:06Z) is the first at protocol 28. Announcement date from the stellar.org blog index. The docs software-versions page still listed Protocol 28 as testnet with no date on 27 September 2026.

Sources: Stellar Development Foundation — Introducing Adapter, Protocol 28 on Stellar (external site) · Stellar Development Foundation — Adapter, Protocol 28 Upgrade Guide (external site) · Stellar Development Foundation (GitHub) — stellar-core v28.0.0 (external site) · Stellar Development Foundation (Horizon API) — Horizon ledger record 64458446 (external site) · Stellar Protocol (GitHub) — CAP-0083: Allow validators to vote to drop the transaction set from the current ledger (external site) · Stellar Docs (Stellar Development Foundation) — Software Versions (external site)
Published Sep 2, 2026Ecosystem projectVerified against sources

USDT0 launched on Stellar

The Stellar Development Foundation announced that USDT0, a token backed one-to-one by USDT locked on Ethereum and moved with LayerZero, is live on Stellar, naming SushiSwap and several wallets and exchanges as supporting it. USDT0's own deployment list includes a Stellar token contract and a matching classic asset.
- Implementation:Stellar deployment listed in USDT0 contract documentation
- Release:announced live
- Activation:live per announcement; partner availability not independently verified
Date basis: Date shown for the post on the stellar.org blog index (2 September 2026); the post page did not show a date in retrieved text.

Sources: Stellar Development Foundation — USDT0 is now live on Stellar (external site) · Stellar Development Foundation — Stellar blog (external site) · USDT0 — USDT0 Contract Deployments (external site) · USDT0 — USDT0 Technical Documentation (external site) · Tether — Supported protocols (external site)
Published Sep 1, 2026ProtocolVerified against sources

stellar-core v28.0.1 released with three stability fixes

stellar-core v28.0.1, a patch to the Protocol 28 node software, was published on GitHub on 1 September 2026, ahead of the 16 September Mainnet vote. Its release notes list three stability changes: repeated query messages between peers are deduplicated, transactions arriving from peers that have not finished authenticating no longer get background signature checks, and the functions that add up a transaction set's fees now cap their totals so the sums cannot overflow. The notes describe no protocol change and no network vote.
- Implementation:three stability fixes in stellar-core; no protocol change listed
- Release:stable release (not a pre-release) published 2026-09-01; shown as Latest on the releases page at retrieval
- Activation:takes effect on each node when its operator installs it; no network vote involved
Date basis: GitHub release published 2026-09-01T07:01:54Z (the tag was created 2026-08-14); the stellar-core releases Atom feed shows the same time.

Sources: Stellar Development Foundation (GitHub) — stellar-core v28.0.1 (external site) · Stellar Development Foundation (GitHub) — Clamp additions in tx set fee summing functions (external site) · Stellar Development Foundation (GitHub) — stellar-core releases (external site) · Stellar Development Foundation (GitHub) — stellar-core releases (Atom feed) (external site)
Published May 6, 2026ProtocolVerified against sources

Protocol 26 (Yardstick) added validator-voted freezing of ledger entries

Protocol 26, listed on Mainnet from 6 May 2026, lets validators keep an on-chain list of frozen ledger keys through network configuration votes: transactions that touch a frozen account, trustline or contract entry are rejected and affected order-book offers are removed, with an allow-list for approved recovery transactions. It also added checked 256-bit arithmetic, limited time-to-live extensions, muxed-address conversions and more zero-knowledge helper functions for contracts.
- Proposal:CAP-77 final
- Implementation:shipped in Protocol 26 builds of the node software
- Release:stable releases available from 8 April 2026
- Activation:Mainnet upgrade listed for 6 May 2026
Date basis: Mainnet date from the Stellar Docs software-versions page; the upgrade guide scheduled the vote for 6 May 2026 at 17:00 UTC.

Sources: Stellar Docs (Stellar Development Foundation) — Software Versions (external site) · Stellar Development Foundation — Stellar Yardstick, Protocol 26 Upgrade Guide (external site) · Stellar Protocol (GitHub) — CAP-0077: Freeze Ledger Entries via Network Configuration (external site)
Published Oct 22, 2025ProtocolVerified against sources

Protocol 24 corrected smart-contract entries damaged by a Protocol 23 archival bug

After the foundation found on 9 October 2025 that Protocol 23 had archived some contract entries with outdated values, validators voted to pause the eviction of unused entries into the archive and ran a patched build that blocked transactions touching the 478 affected entries. Protocol 24, put to a Mainnet validator vote on 22 October 2025, reset the 394 affected entries that had never been restored to their correct pre-archival values and adjusted the fee pool; the other cases were left to the affected organizations.
- Proposal:CAP-76 final
- Implementation:shipped in Protocol 24 builds of the node software
- Release:stable releases scheduled for 20 October 2025
- Activation:Mainnet upgrade listed for 22 October 2025
Date basis: Stellar Docs software-versions page lists Protocol 24 on Mainnet on 22 October 2025; the foundation post set the vote for 17:00 UTC that day. The post's own date was not shown in retrieved text.

Sources: Stellar Development Foundation — Addressing state archival inconsistencies: protocol upgrade vote next week (external site) · Stellar Protocol (GitHub) — CAP-0076: P23 State Archival bug remediation (external site) · Stellar Docs (Stellar Development Foundation) — Software Versions (external site)

Topics your AI can explain

Your AI can explain these topics for Stellar through the connection, with sources.

What Stellar is and what XLM is for
How the Stellar Consensus Protocol reaches agreement
Accounts, trustlines and reserves: how Stellar stores state
Fees, stroops, reserves and rent
Finality on Stellar: closed ledgers, halts and rare corrections
The built-in order book, liquidity pools and path payments
Soroban smart contracts and state archival
Issued assets, stablecoins and issuer controls
Bridges, channels and how Stellar scales

Known gaps

What this profile's review did not establish:

The Tier 1 count comes from the docs' example configuration, not from the live network; how quorum sets are actually configured across all validators was not verified because the public validator monitor needs a browser to render.
No light-client verification path for end users was found; the row is marked unknown rather than not present.
Algorithmic or collateral-debt stablecoins on Stellar were not reviewed.
Liquidity depth on the built-in order book, the protocol pools and smart-contract venues was not reviewed.
Hardware needs for Stellar RPC and Horizon data nodes were not reviewed; the validator figure dates from April 2024.
Whether Ledger Wallet and Trezor Suite handle issued Stellar assets such as USDC, or Soroban contract calls, was not verified.
Absence of rollups, sidechains, and an authenticated data-publishing layer was not exhaustively verified.

Sources

Oldest dated source check: Source checked Sep 27, 2026 Next check due Oct 27, 2026.

All 40 sources were checked in the last 30 days.

Lumens (XLM) (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Stellar Consensus Protocol (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Admin Guide: Configuring (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Example Mainnet full-validator configuration (stellar-core.cfg) (external site)Stellar Development Foundation (GitHub, stellar/packages) · retrieved Sep 27, 2026
Ledgers (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Accounts (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Operations and Transactions (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Signatures and Multisig (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Transaction Lifecycle (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
List of Operations (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Fees, Resource Limits, and Metering (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Liquidity on Stellar: SDEX and Liquidity Pools (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Software Versions (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Validators Introduction (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Admin Guide: Prerequisites (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Tier 1 Organizations (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Clawbacks (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Claimable balances (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Smart contracts overview (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
RPC Introduction (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Cross-Chain (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
Block Explorers (external site)Stellar Development Foundation (Stellar Docs) · retrieved Sep 27, 2026
May 15th Network Halt (external site)Stellar Development Foundation · retrieved Sep 27, 2026
CAP-0021: Generalized transaction preconditions (external site)Stellar Protocol (GitHub) · retrieved Sep 27, 2026
CAP-0076: P23 State Archival bug remediation (external site)Stellar Protocol (GitHub) · retrieved Sep 27, 2026
CAP-0077: Freeze Ledger Entries via Network Configuration (external site)Stellar Protocol (GitHub) · retrieved Sep 27, 2026
Starlight payment channel prototype (archived repository) (external site)Stellar Development Foundation (GitHub, stellar-deprecated) · retrieved Sep 27, 2026
USDC contract addresses (external site)Circle · retrieved Sep 27, 2026
EURC contract addresses (external site)Circle · retrieved Sep 27, 2026
CCTP supported blockchains (external site)Circle · retrieved Sep 27, 2026
CCTP on Stellar (external site)Circle · retrieved Sep 27, 2026
Supported protocols (external site)Tether · retrieved Sep 27, 2026
USDT0 Technical Documentation (external site)USDT0 · retrieved Sep 27, 2026
USDT0 Contract Deployments (external site)USDT0 · retrieved Sep 27, 2026
Stellar Interchain Token Service (ITS) (external site)Axelar · retrieved Sep 27, 2026
Allbridge Core documentation (external site)Allbridge · retrieved Sep 27, 2026
Welcome to Aquarius (external site)Aquarius · retrieved Sep 27, 2026
Soroswap Finance documentation (external site)Soroswap Finance · retrieved Sep 27, 2026
Stellar Wallet (external site)Ledger · retrieved Sep 27, 2026
Stellar wallet (external site)Trezor · retrieved Sep 27, 2026

Report an error

Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.

Report an error about Stellar Corrections log

Funding disclosure

Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding