📄️ 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 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.
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.
📄️ Fees, Surge Pricing, and Fee Strategies
Stellar requires a small fee for all transactions to prevent ledger spam and prioritize transactions during surge pricing. All fees are paid in lumens (XLM).
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
Users can trade and convert assets on the Stellar network with the use of path payments through Stellar’s decentralized exchange and liquidity pools.
📄️ 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 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.
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.