Frequently Asked
Questions

SCP is a Federated Byzantine Agreement (FBA): instead of all nodes agreeing (like PBFT), each node selects a "quorum slice" (trusted nodes) and only needs consensus within that slice. This allows horizontal scaling, tolerance to malicious nodes, and finality in 3-5 seconds without mining or PoS staking.

A quorum slice is the set of nodes your node trusts to reach consensus. For users, this is transparent: validators (SDF, Coinbase, Satoshipay, etc.) configure their slices. Your transaction is final when enough slices interconnect forming a global quorum. In practice: you don't configure anything, it just works in 3-5s.

Stellar (XLM): open-source, decentralized, focused on individuals and stablecoins, native DEX in protocol, nonprofit (SDF). Ripple (XRP): private company, focused on institutional banking, centralized control over validators. Both emerged from Jed McCaleb, but Stellar was redesigned from scratch in 2015 with SCP.

Horizon is the REST API for Stellar. Endpoints: mainnet (horizon.stellar.org), testnet (horizon-testnet.stellar.org). SDKs: stellar-sdk (JS/TS), stellar-base (Python), java-stellar-sdk. Basic example: GET /accounts/{address} returns balances, sequence, trustlines. POST /transactions to submit XDR.

SEPs (Stellar Ecosystem Proposals) are interoperability standards. Critical ones: SEP-1 (stellar.toml), SEP-10 (auth), SEP-24 (interactive deposits/withdrawals), SEP-31 (cross-border payments). For on/off-ramp with EURC, implement SEP-24 to allow users to deposit euros and receive EURC directly.

SEP-10 is "web authentication for Stellar". Flow: 1) Server generates a challenge (transaction with manage_data op), 2) Client signs with their private key, 3) Server validates the signature and issues a JWT. Use: authenticate users without passwords, only with their wallet. The stellar-sdk has methods like buildChallengeTx() and verifyChallengeTxSigners().

Soroban is Stellar's smart contract platform, based on Rust/WASM. Differences from Solidity: memory-safe (Rust), explicit state with TTL (data expires), metered resources (CPU, I/O, bandwidth), no "gas wars" (predictable fees). Advantage: inherits Stellar security and compliance (asset flags, clawback work in Soroban).

1) Build: cargo build --release --target wasm32-unknown-unknown. 2) Optimize: soroban contract optimize. 3) Deploy: soroban contract deploy --wasm target/.../contract.wasm --network mainnet --source SECRET. 4) Initialize: soroban contract invoke --id CONTRACT_ID --fn initialize. Cost: ~100-500 XLM depending on contract size.

All Soroban data has an expiration date (TTL). Types: temporary (expires and is deleted), persistent (expires but can be restored). To extend TTL: extend_ttl() in code or soroban contract extend. Cost: proportional to data size × time. Best practice: automate renewals for critical data with a cron or keeper service.

Classic assets (EURC, USDC, XLM) are automatically wrapped as SAC (Stellar Asset Contract). To obtain the contract address: stellar contract id asset --asset EURC:ISSUER --network mainnet. Then use token::Client from soroban-sdk to transfer, approve, balance. The interface is similar to ERC-20.

payment: sends exact asset A to recipient. path_payment_strict_receive: "I want the recipient to receive exactly X of asset B, using my asset A through the best DEX route". path_payment_strict_send: "I send exactly X of A, recipient receives whatever B results". Use path_payment for auto-conversion EURC→XLM→USDC.

Stellar has native multisig with thresholds. Each signer has a weight (1-255), operations have thresholds (low, medium, high). Example 2-of-3: signers with weight=1, high_threshold=2. Operation set_options to add/remove signers. Business use case: joint accounts, DAO governance, escrow with release conditions.

Claimable balances allow sending assets even if the recipient doesn't have a trustline. You deposit EURC with conditions (who can claim, time window). The recipient claims when ready. Use case: onboarding new users, B2B payments with delivery confirmation, scheduled payments.

1) Create an issuing account (cold, offline). 2) Create a distributing account (hot). 3) Distribution establishes trustline for the asset. 4) Issuer sends tokens to distributor (this "mints"). 5) Optional: lock issuer with set_options(master_weight=0) to fix supply. Don't forget: stellar.toml for metadata.

Asset flags for regulatory compliance. AUTH_REQUIRED: issuer must approve each trustline (KYC). AUTH_REVOCABLE: issuer can freeze accounts (sanctions). AUTH_CLAWBACK: issuer can recover tokens (court order, fraud). For regulated tokens (security tokens, stablecoins), all three are typically enabled.

DEX is open: you don't need permission. Steps: 1) Create offers (manage_sell_offer / manage_buy_offer) for your pair TOKEN/XLM or TOKEN/USDC. 2) Publish stellar.toml with token metadata. 3) Request listing on frontends (StellarTerm, StellarX). Initial liquidity is crucial: without offers, no one can buy.

Public key (G...): your "Stellar address", shareable, used to receive funds. Secret key (S...): NEVER share, used to sign transactions. Derivation: Ed25519 asymmetric cryptography, secret → public (irreversible). Lose the secret = permanent loss of funds. Hardware wallet (Ledger) recommended for large amounts.

Muxed account = base account (G...) + numeric ID (u64). Format: M.... Use: exchanges can have one G... account and millions of virtual sub-accounts for users. When receiving a payment to M..., the memo is unnecessary—the ID is embedded in the address. SDK: MuxedAccount.fromAddress().

Sponsorship allows one account to pay another's reserves. Use case: new users don't need XLM to start, you sponsor their account and trustlines. Operations: begin_sponsoring_future_reserves + action + end_sponsoring_future_reserves. You can also revoke sponsorship later to recover funds.

For hot wallets (automated): HSM (AWS CloudHSM, Azure HSM) or KMS with envelope encryption. For cold/multisig: Ledger + air-gapped signing. Never in plain text in code/config. Practice: separate accounts for operations (hot, limited balance) and treasury (cold, multisig). Automatic rotation of hot keys.

Pre-auth tx is a transaction hash added as a signer with set_options. It can only be executed once and is automatically removed. Use case: escrow without active intermediary, release scheduled payments, migration between accounts. Caution: if the tx expires (sequence) or fails, the pre-auth remains useless.

Stellar has native protections: 1) Sequence number: strictly incremental per account, a tx cannot be reused. 2) Network passphrase: different between mainnet/testnet, impossible to replay between networks. 3) Timeout: timeBounds for limited validity. Additional: validate all input parameters before signing.

Base fee: 100 stroops (0.00001 XLM) per operation. A transaction with 3 operations = 300 stroops. In congestion, fees can rise (fee bump mechanism), but historically they've remained at the minimum. Soroban: additional metering for CPU/memory/storage, typically 10-100x classic, but still low ($0.01-0.10).

SDF (Stellar Development Foundation): nonprofit, develops core-stellar and ecosystem tools. CAPs (Core Advancement Proposals): community proposals for protocol changes. Validators: independent, vote by configuring quorum slices. Decisions are de facto decentralized, although SDF has significant influence as main developer.

For development: use horizon.stellar.org (rate limited). For production with volume: your own Horizon + PostgreSQL (16GB RAM, 2TB SSD minimum). Advantages: no rate limit, faster responses, transaction privacy. Alternative: commercial providers (Blockdaemon, Infura planned).

Stellar Core: consensus node, validates and closes ledgers, network backbone. Horizon: REST API for queries and transaction submission, consumes Core via captive-core. Soroban RPC: specific API for smart contracts (simulations, preflight, invocations). For complete app: Horizon for classic + Soroban RPC for contracts.

Checklist: 1) Change network passphrase ("Public Global Stellar Network ; September 2015"), 2) Change Horizon URL (horizon.stellar.org), 3) Generate NEW accounts (don't reuse testnet keys), 4) Fund accounts with real XLM, 5) Redeploy Soroban contracts (new contract IDs), 6) Validate integrations with small amounts.

Strategy: maintain buy/sell orders around mid-price with spread. Ops: manage_sell_offer / manage_buy_offer for updates. Stream: Horizon streaming /order_book for price changes. Risks: impermanent loss, slippage in volatile moves. Tools: kelp (SDF's market maker), custom bots with stellar-sdk.

Stellar has native AMM (constant product, like Uniswap v2). Pools of 2 assets, proportional deposit, pool shares. Advantages: provides liquidity without actively managing orders, earns swap fees. Ops: liquidity_pool_deposit, liquidity_pool_withdraw. Consideration: impermanent loss applies in high volatility.

1) Check result_codes in Horizon response (tx_failed, op_failed). 2) Common errors: op_underfunded (insufficient balance), op_no_trust (trustline missing), op_line_full (hit limit), tx_bad_seq (wrong sequence). 3) Soroban: check simulation before submit. 4) stellar.expert to visualize full transaction. 5) Soroban logs via stellar contract logs.

MiCA (Markets in Crypto-Assets) is EU regulation effective from June 2024 for stablecoins and December 2024 for all CASPs. For Stellar developers: tokens issued in the EU must comply depending on their classification (EMT, ART, utility). EURC is already compliant as an E-Money Token from Circle.

For KYC (legal requirement): name, ID, proof of address. Public on-chain: addresses, transaction hashes. NEVER store: private keys, seed phrases. GDPR basis: legal obligation (AML) and legitimate interest (fraud prevention). Retention: 5 years after account closure (legal requirement).

Implementation measures: 1) SEP-10 authentication (verifies wallet ownership), 2) URL validation in frontend (warn if impersonation domain), 3) User education about NEVER sharing seed phrases, 4) Signing alerts in hardware wallets, 5) Allowlisting of known recipient addresses.

Yes. In Spain: CNMV sandbox for fintech. In EU: MiCA allows member states to offer sandboxes. SDF also has the Stellar Community Fund (SCF) for funded projects. Advantage: test with real users under supervision before full licensing.

Depends on jurisdiction and use case. Soroban contracts, as immutable and auditable code, can serve as digital evidence, but are not inherently "legal contracts." For real estate, the Soroban contract complements (not replaces) the public deed. In Spain, the smart contract can be attached as electronic evidence under Law 6/2020.