Encyclopedia
In-depth explanations and articles concerning specific topics of interest.
📄️ Anchors
An anchor is a Stellar-specific term for the on and off-ramps that connect the Stellar network to traditional financial rails, such as financial institutions or fintech companies. Anchors accept deposits of fiat currencies (such as the US dollar, Argentine peso, or Nigerian naira) via existing rails (such as bank deposits or cash-in points), then sends the user the equivalent digital tokens on the Stellar network. The equivalent digital tokens can either represent that same fiat currency or another digital token altogether. Alternatively, anchors allow token holders to redeem their tokens for the real-world assets they represent.
📄️ Channel Accounts
Channel accounts provide a method for submitting transactions to the network at a high rate.
📄️ Claimable Balances
Claimable balances were introduced in CAP-0023 and are used to split a payment into two parts.
📄️ Clawbacks
Clawbacks were introduced in CAP-0035 and allow an asset issuer to burn a specific amount of a clawback-enabled asset from a trustline or claimable balance, effectively destroying it and removing it from a recipient’s balance.
📄️ Error Handling
It’s important to anticipate errors your users may encounter as you develop on Stellar. In many tutorials throughout our developer documentation, we leave out error handling code to focus on the example. In this section, we will do the opposite and talk specifically about the errors.
📄️ Federation
The Stellar federation protocol maps Stellar addresses to an email-like identifier that provides more information about a given user. It’s a way for Stellar client software to resolve email-like addresses such as name*yourdomain.com into account IDs like: GCCVPYFOHY7ZB7557JKENAX62LUAPLMGIWNZJAFV2MITK6T32V37KEJU. Federated addresses provide an easy way for users to share payment details by using a syntax that interoperates across different domains and providers.
📄️ Fee-Bump Transactions
Fee-bump transactions were introduced in CAP-0015 and enable an account to pay the transaction fees for an existing transaction without having to re-sign the transaction or manage sequence numbers.
📄️ Inflation
The inflation operation is deprecated. Here’s why:
📄️ Ledger Headers
Every ledger has a header that references the data in that ledger and the previous ledger. These references are cryptographic hashes of the content which behave like pointers in typical data structures but with added security guarantees. Think of a historical ledger chain as a linked list of ledger headers:
📄️ Liquidity on Stellar: SDEX and Liquidity Pools
This section is scoped specifically to liquidity regarding the AMM and SDEX built into the Stellar protocol and does not include information regarding smart contracts.
📄️ Lumen Supply Metrics
This section explains how lumen supply metrics are calculated and made available via API. This information can be useful for products and services that track the distribution of XLM, including market cap aggregators and some exchanges, or to anyone who wants to investigate the distribution of XLM defined by the SDF mandate.
📄️ Memos
Memos are an optional unstructured data field that can be used to embed any additional identifying information about the transaction relevant to the sender or receiver.
📄️ Network Passphrases
Stellar’s Mainnet, Testnet, and Futurenet each have their own unique passphrase. These are used when validating signatures on a given transaction. If you sign a transaction for one network but submit it to another, it won’t be considered valid. By convention, the format of a passphrase is ‘[Network Name] ; [Month of Creation] [Year of Creation]’.
📄️ Path Payments
In a path payment, the asset received differs from the asset sent. Rather than the operation transferring assets directly from one account to another, path payments cross through the SDEX and/or liquidity pools before arriving at the destination account. For the path payment to succeed, there has to be a DEX offer or liquidity pool exchange path in existence. It can sometimes take several hops of conversion to succeed.
📄️ Pooled Accounts: Muxed Accounts and Memos
When building an application or service on Stellar, one of the first things you have to decide is how to handle user accounts.
📄️ Securing Web-Based Projects
Any application managing cryptocurrency is a frequent target of malicious actors and needs to follow security best practices. The below checklist offers guidance on the most common vulnerabilities. However, even if you follow every piece of advice, security is not guaranteed. Web security and malicious actors are constantly evolving, so it’s good to maintain a healthy amount of paranoia.
📄️ Signatures and Multisig
Signatures are authorization for transactions on the network. Transactions always need authorization from at least one public key to be valid and generally, the signature comes from the source account. Sometimes transactions require more signatures, which we’ll get into in the multisig section.
📄️ Sponsored Reserves
Sponsored reserves were introduced in CAP-0033 and allow an account (sponsoring account) to pay the base reserves for another account (sponsored account). While this relationship exists, base reserve requirements that would normally accumulate on the sponsored account now accumulate on the sponsoring account.
📄️ Transaction Lifecycle
This is the transaction lifecycle for a classic Stellar transaction. Adding smart contract components to this section is currently a work in progress.
📄️ XDR
Stellar stores and communicates ledger data, transactions, results, history, and messages in a binary format called External Data Representation (XDR). XDR is optimized for network performance but not human readable. Horizon and the Stellar SDKs convert XDRs into friendlier formats.