About this document

This paper describes what XDB CHAIN is, how it works, and how to verify each statement in it against the network itself. It replaces the XDB CHAIN Official Whitepaper v1.0.0 (4 December 2023), which is retained as a historical record.

It is a technical description of an open-source network. It is not an offer, solicitation or invitation to buy, sell or subscribe for any asset, and it does not constitute investment, legal, tax or financial advice. It makes no statement about the legal classification of XDB or of any asset issued on the network; classification depends on the asset, the rights attached to it and the jurisdiction, and is a matter for the relevant issuer and its advisers.

Every quantitative statement below carries the value observed at the stated time and the endpoint that returns it. Values change; the endpoints do not. Readers are expected to re-run them.

Observation window for all figures in this document: 10 August 2026, 12:06 UTC, at ledger 17,094,894 unless otherwise stated.

1. What XDB CHAIN is

XDB CHAIN is an open-source Layer 1 blockchain. It provides three protocol-level capabilities:

Issue. Assets are created as native ledger entries. Issuing an asset does not require deploying a token contract.

Move. Assets are transferred between accounts and settle on the network in seconds, at a base network fee of 0.00001 XDB per operation.

Exchange. The network contains an on-chain order book and automated market-maker pools. Orders and settlement are recorded on the ledger.

The native coin is XDB. It is used to pay transaction fees and to meet the account reserves the protocol requires; it is the only asset that does not need a trustline.

XDB CHAIN runs a Stellar-derived stack as an independent network. It is not the public Stellar network, shares no ledger with it, and is governed separately. It runs Stellar Core and Horizon and is compatible with Stellar SDKs, which means established, audited tooling applies directly. Terminology is remapped: the native asset is XDB, its smallest unit is the bee, and the client-facing API server is referred to as Frontier.

The network is operated as open infrastructure by XDBee Labs Limited.

Verify:GET https://horizon.livenet.xdbchain.com/ returns the network passphrase, core version, Horizon version and protocol version.

2. Architecture

Three components, each independently inspectable.

Stellar Core is the node software. Each node validates transactions, participates in consensus and maintains a full copy of the ledger. The network is the set of connected nodes; some also run Horizon, others validate only.

Horizon / Frontier is the HTTP API server in front of Core. It is the interface applications use: submit transactions, query accounts, assets, offers, trades and ledgers, and stream events over server-sent events. It is a read/submit layer — it holds no authority over consensus.

SDKs cover JavaScript, Go, Python and C#. The JavaScript SDK is published as ts-xdbchain-sdk; the network also runs the standard js-stellar-sdk and js-stellar-base libraries.

Anchors are entities that hold an off-chain deposit and issue a corresponding on-chain credit. Every asset other than XDB is a credit issued by an account. The conventional structure is an issuing account, which only creates and destroys the asset, and a separate distribution account that transacts and holds balances. An anchor’s obligations to holders are contractual and off-chain; the network records the credit, not the obligation behind it.

Observed 10 Aug 2026: core stellar-core 19.7.0, Horizon 2.24.0, protocol version 19, earliest retained ledger 51,776 (10 November 2023).

3. Consensus

XDB CHAIN uses the Stellar Consensus Protocol (SCP), an implementation of Federated Byzantine Agreement.

Each node declares which other nodes it will not proceed without — its quorum slice. Agreement emerges where those slices overlap across the network, rather than from a fixed, permissioned validator list or from proof of work or stake. There is no mining and no staking in the protocol.

The property that matters most in practice: SCP prioritises safety over liveness. Where nodes cannot safely agree — a partition, or misbehaving participants — the network halts rather than risk producing divergent histories. A halt is recoverable and visible; a fork is neither. Any operator building settlement on the network should understand that trade-off, because it means the correct failure mode is unavailability, not ambiguity.

Ledgers close on a fixed cadence. Across a twelve-ledger sample taken on 10 August 2026, close intervals were 5, 5, 5, 5, 5, 6, 5, 5, 5, 5 and 5 seconds. A transaction included in a closing ledger is final when that ledger closes; there is no probabilistic confirmation window and no reorganisation.

Verify:GET /ledgers?order=desc&limit=12 and compare closed_at values.

4. Native issuance

An asset on XDB CHAIN is a credit from a specific account. It is identified by a code plus the issuer’s account, and it exists as a ledger entry rather than as contract state.

Asset codes are alphanumeric, up to 4 characters or 5 to 12 characters. Balances are held as signed 64-bit integers scaled by 10⁷, giving 7 decimal places and a maximum single-asset amount of 922,337,203,685.4775807.

Before an account can hold a non-native asset it must establish a trustline to the issuer. A trustline is an explicit, on-chain statement of willingness to hold that asset up to a limit. Nothing can be pushed into an account that has not opted in — a property with obvious relevance to unsolicited-asset risk. Each trustline occupies a ledger entry and therefore raises the account’s minimum balance.

Issuing an asset is a protocol capability, available to anyone who can submit a transaction. That is a statement about the software, not about the law. Issuers remain responsible for determining and complying with the legal requirements applicable to the asset, the offer, its distribution and every jurisdiction in which it is made available. Nothing in the network’s design substitutes for that analysis.

Supply can be made immutable by locking the issuing account: setting the master key weight to zero after issuance leaves the account unable to sign further transactions, so no more of the asset can ever be created. This is the standard pattern for fixed-supply assets and for non-fungible items.

5. Asset controls

The protocol exposes controls at the issuer level. They are properties of the ledger, not of application code.

Authorization required — holders must be explicitly authorised by the issuer before they can hold or transact the asset. This is the mechanism underpinning permissioned assets.

Authorization revocable — the issuer can revoke a previously granted authorisation, freezing that holder’s balance for the asset.

Authorization immutable — flags are locked permanently and the account can never be deleted. Used to guarantee to holders that the controls above will not be introduced later.

Clawback — where enabled, allows an issuer to claw back a balance. Its presence or absence materially changes what a holder actually holds, and it should be disclosed by any issuer that enables it.

Two consequences worth stating plainly. First, these controls are visible on-chain: a prospective holder can inspect an issuing account’s flags before accepting the asset. Second, an issuer choosing them is choosing a relationship with holders, and that relationship — not the flag — is what any legal analysis will examine.

6. Native exchange

The order book is part of the protocol, not an application deployed on top of it.

Offers are stored on the ledger and behave as limit orders, matched on price-time priority. Prices are held as integer numerator/denominator pairs, so no rounding error is introduced by floating-point representation. A passive offer does not take an existing offer at an equal price, which allows two issuers of equivalent assets to maintain a market without crossing each other.

Path payments let a sender pay in one asset while the recipient receives another, converting across order books in a single atomic operation of up to 6 hops. Either the whole path executes or nothing does. Path discovery is performed by Horizon, off the critical consensus path.

Liquidity pools implement a constant-product market maker. The fee is 30 basis points, retained in the pool. Pool shares are non-transferable; the two assets in a pool are held in a defined order; and a pool-share trustline costs two base reserves and inherits its authorisation from the trustlines of the two underlying assets.

Because offers and trades are ledger entries, the full state of any market is queryable without relying on an operator’s reporting.

Verify:GET /order_book?selling_asset_type=native&buying_asset_type=…, GET /trades, GET /liquidity_pools.

7. Fees and reserves

Parameter	Value	Source
Smallest unit	1 bee = 0.0000001 XDB	protocol
Base fee	100 bees = 0.00001 XDB per operation	/fee_stats → last_ledger_base_fee
Transaction fee	(number of operations) × base fee	protocol
Base reserve	10 XDB	ledger header base_reserve_in_stroops = 100,000,000
Minimum account balance	(2 + number of subentries) × base reserve — a new account with no subentries: 20 XDB	protocol
Max operations per transaction set	100	ledger header max_tx_set_size
Max signatures per transaction	20	protocol
Asset precision	7 decimals	protocol
Liquidity-pool fee	30 bps	protocol
Max path-payment hops	6	protocol

Fees are charged in XDB and accrue to a fee pool held by the network rather than to any operator. At the observation point the fee pool held 13.97573 XDB.

Reserves are not a charge. They are a refundable minimum balance that must remain in an account for each ledger entry it occupies — the account itself, each trustline, each offer, each data entry. Removing the entry releases the reserve. Reserves exist to bound ledger growth: creating state has a cost, so state is not created carelessly.

At the observation point, fee_charged was 100 bees at both the 50th percentile and the maximum, and ledger capacity usage was 0 — fees were at the floor and no fee market was active.

8. XDB supply

Three quantities are used in this document. They are defined precisely, and each is derived from data on the ledger rather than from an internal report.

Definitions

maximum supply = 20,000,000,000 XDB (fixed)
total supply = maximum supply − burned
circulating supply = total supply − treasury

How the supply reached its current level

Stage	Amount	Basis
Created at genesis	100,000,000,000 XDB	full issuance at network creation
Hard burned at the outset	80,000,000,000 XDB	removed permanently
Maximum supply	20,000,000,000 XDB	the ceiling since that burn, and still the ceiling today
Less: held at the disclosed burn address	1,264,163,369.6070323 XDB	GET /accounts/GC7GH763…BBBRN
Total supply	18,735,836,630.3929677 XDB	maximum supply − burned
Less: held at the treasury address	1,609,599,837.9999000 XDB	GET /accounts/GBMOHKO3…R222
Circulating supply	17,126,236,792.3930677 XDB	total supply − treasury

Rounded for reading: maximum 20 billion, total 18.74 billion, circulating 17.13 billion.

Every figure above comes from one of four inputs: the fixed 20,000,000,000 ceiling, the burn-address balance, the treasury-address balance, and arithmetic. Both balances are queryable at GET /accounts/{address}, so the derived figures can be recomputed by anyone at any time. They are not assertions; they are arithmetic over public state.

Why the ledger header reads 100 billion. On a Stellar-derived network, burning does not delete coins from the ledger’s accounting. A burn transfers a balance to an address whose keys have been permanently invalidated: the coins continue to exist as a ledger entry but can never be moved again. The header field total_coins therefore retains its genesis value and does not decrease when a burn occurs. It records what was created, not what is available. total_coins has read 100,000,000,000 since ledger 51,776 (10 November 2023), the earliest ledger this network retains, and it will not change.

The practical reading: 100 billion is the genesis issuance; 20 billion is the maximum supply; 18.74 billion is the total supply; 17.13 billion is circulating. Any figure quoted without saying which of the four it is, is ambiguous. Total supply and circulating supply in particular must never be presented interchangeably.

Supply is derived from the ledger, not reported from an internal system. Where a third party publishes an XDB supply figure that differs from the derivation above, the ledger is authoritative.

9. Buy-back and burn

Branded Coins issued on XDB CHAIN allocate up to 2.5% of their supply to recurring XDB burns. Burns run quarterly through dedicated public burn addresses — every event is numbered, published, and auditable on-chain.

Mechanically, a burn is a transfer to an address whose keys have been invalidated. Setting all signer weights and thresholds to zero leaves the account permanently unable to authorise a transaction, so anything sent to it cannot be moved again. The balance remains publicly visible, which is what makes the event verifiable rather than merely asserted.

Seven burn events have been completed and published, each with its transaction reference. The cumulative balance at the disclosed burn address was 1,264,163,369.607 XDB at the observation point.

This paper describes the mechanism and reports executed events. It makes no statement about the effect of burns on the price or market value of XDB, and none should be inferred.

10. Validators and governance

Consensus is produced by independently operated nodes. Because SCP relies on quorum slices rather than a registry, there is no single authoritative validator list published by the network itself; the operative topology is what nodes actually declare.

XDB Atlas (atlas.xdbchain.com) renders the observed node and quorum topology, which is the practical way to inspect who is validating and how quorum sets overlap.

XDBee Labs Limited maintains the reference implementation, documentation and public infrastructure endpoints. It does not control consensus: an operator disagreeing with a change expresses that by choosing what software to run and whom to include in its quorum slices. Independent developers building on the network do so at arm’s length.

Present state, stated plainly: the network’s decentralisation should be assessed from the live topology in Atlas rather than from any claim in this document. Anyone performing that assessment is encouraged to do so directly.

11. Live infrastructure

Service	Endpoint	Function
Mainnet API (Horizon/Frontier)	https://horizon.livenet.xdbchain.com	transactions, accounts, ledgers, streaming
Mainnet passphrase	LiveNet Global XDBChain Network ; November 2023	network identity
Test network API	https://horizon.futurenet.xdbchain.com	development
Test network passphrase	Futurenet XDBChain Network ; October 2023	network identity
Test funding	https://friendbot.futurenet.xdbchain.com	funds test accounts
Explorer	https://explorer.xdbchain.com	accounts, transactions, ledgers, assets
Node & quorum explorer	https://atlas.xdbchain.com	topology
Laboratory	https://laboratory.xdbchain.com	build, sign and submit transactions
Developer documentation	https://developers.xdbchain.com	reference
Source	https://github.com/xdbchain	repositories

The test network is periodically reset and its balances are not persistent. It is for development only.

12. Security model

What the protocol guarantees. Transactions are authorised by ed25519 signatures. Accounts support multiple signers with weights and three operation thresholds — low, medium and high — so authority can be split across parties and operations of differing consequence can require differing consent. Two further signer types extend this: a pre-authorised transaction, where the hash of a specific future transaction is added as a signer, and a hash(x) signer, where revealing a preimage authorises a transaction, which is what allows hash-time-locked constructions.

Transactions are atomic. A transaction carries an ordered list of operations, and either all of them apply or none do. A failing operation rolls back the whole transaction; the fee is still charged, which is what prevents free retry spam.

Sequence numbers must increment exactly, preventing replay. Optional time bounds constrain when a transaction is valid.

What the protocol does not guarantee. It does not protect against a compromised key — signatures are the authority, so key management is the security boundary. It does not vouch for an issuer’s solvency or good faith: a credit on the ledger is exactly as good as the entity behind it. It does not review the assets that anyone issues. And it will halt rather than fork under conditions where safe agreement is impossible, which is a deliberate availability trade-off.

Composed-transaction patterns — multi-signature escrow with time-locked recovery, joint-entity arrangements with success and refund branches — are documented in the developer reference. The current protocol direction is the adoption of Soroban, Stellar’s WebAssembly smart-contract platform. That work is a good-faith plan and is described here as such: no date is promised, and nothing in this paper should be read as a commitment to deliver it on any timetable.

13. Developer interfaces

The fastest honest description of the developer experience is that it is Stellar’s, on an independent network.

Applications talk to Horizon over HTTP, or through an SDK. A first transaction requires: an account, funding, and a signed submission. On the test network, Friendbot funds an account; from there an asset can be issued, a trustline established, a payment sent, and the result inspected in the Explorer — all against documented endpoints.

Operations available (21): Create Account · Payment · Path Payment Strict Send · Path Payment Strict Receive · Manage Buy Offer · Manage Sell Offer · Create Passive Sell Offer · Set Options · Change Trust · Allow Trust · Account Merge · Manage Data · Bump Sequence · Create Claimable Balance · Claim Claimable Balance · Begin Sponsoring Future Reserves · End Sponsoring Future Reserves · Clawback · Clawback Claimable Balance · Set Trustline Flags · Liquidity Pool Deposit / Withdraw.

Integration metadata is published per domain at /.well-known/stellar.toml (SEP-0001), served as text/plain with CORS enabled, covering organisation details, contacts and currency metadata. An issuing account links to it through its home domain.

Muxed accounts (M… addresses) let a custodian route many users through one underlying account without a memo convention. They do not exist as ledger entries; only the underlying G… account does.

14. How to verify every claim in this paper

Each statement above is checkable. The commands below return the values quoted, at the time you run them.

# network identity, versions, protocol
curl https://horizon.livenet.xdbchain.com/ # base fee actually charged, and current ledger
curl https://horizon.livenet.xdbchain.com/fee_stats # ledger close cadence — compare closed_at across records
curl "https://horizon.livenet.xdbchain.com/ledgers?order=desc&limit=12" # base reserve, max tx set size, total_coins, fee pool (see §8)
curl "https://horizon.livenet.xdbchain.com/ledgers?order=desc&limit=1" # disclosed burn address balance
curl https://horizon.livenet.xdbchain.com/accounts/GC7GH763TKNVOWOOLOZR4ZYHHDSJIYJPP746ZFNEQZLJHB244WBBBBRN # treasury address balance
curl https://horizon.livenet.xdbchain.com/accounts/GBMOHKO3CVEJSMUXCJ3WZR5DIZAL33LVLH7CRRXLMV5X655WHPS5R222

Supply is derived, not quoted. Take 20,000,000,000, subtract the burn-address balance to obtain total supply, then subtract the treasury balance to obtain circulating supply. Both balances come from the two accounts calls above, so the whole of §8 can be reproduced from this page.

If a figure in this document no longer matches what these return, the network is right and the document is stale. Report it to marketing@xdbchain.com.

Document control

Field	Value
Title	XDB CHAIN Network Paper
Version	1.0
Published	10 August 2026
Entity	XDBee Labs Limited
Replaces	XDB CHAIN Official Whitepaper v1.0.0 (4 December 2023), retained as historical
Observation window	10 August 2026, 12:06 UTC, ledger 17,094,894
Supply definitions	max 20,000,000,000 · total = max − burned · circulating = total − treasury
Status	Approved for publication
Contact	marketing@xdbchain.com