Häufig gestellte
Fragen

SCP ist ein Federated Byzantine Agreement (FBA): Anstatt dass alle Knoten übereinstimmen (wie PBFT), wählt jeder Knoten eine "Quorum-Scheibe" (vertrauenswürdige Knoten) und benötigt nur Konsens innerhalb dieser Scheibe. Dies ermöglicht horizontale Skalierung, Toleranz gegenüber bösartigen Knoten und Finalität in 3-5 Sekunden ohne Mining oder PoS-Staking.

Eine Quorum-Scheibe ist die Menge von Knoten, denen Ihr Knoten vertraut, um Konsens zu erreichen. Für Benutzer ist dies transparent: Validatoren (SDF, Coinbase, Satoshipay usw.) konfigurieren ihre Scheiben. Ihre Transaktion ist final, wenn genügend Scheiben sich verbinden und ein globales Quorum bilden. In der Praxis: Sie konfigurieren nichts, es funktioniert einfach in 3-5s.

Stellar (XLM): Open-Source, dezentralisiert, fokussiert auf Einzelpersonen und Stablecoins, nativer DEX im Protokoll, gemeinnützig (SDF). Ripple (XRP): Privatunternehmen, fokussiert auf institutionelles Banking, zentralisierte Kontrolle über Validatoren. Beide entstanden von Jed McCaleb, aber Stellar wurde 2015 von Grund auf mit SCP neu gestaltet.

Horizon ist die REST-API für Stellar. Endpoints: Mainnet (horizon.stellar.org), Testnet (horizon-testnet.stellar.org). SDKs: stellar-sdk (JS/TS), stellar-base (Python), java-stellar-sdk. Einfaches Beispiel: GET /accounts/{address} gibt Guthaben, Sequenz, Trustlines zurück. POST /transactions zum Einreichen von XDR.

SEPs (Stellar Ecosystem Proposals) sind Interoperabilitätsstandards. Kritische: SEP-1 (stellar.toml), SEP-10 (Auth), SEP-24 (interaktive Ein-/Auszahlungen), SEP-31 (grenzüberschreitende Zahlungen). Für On/Off-Ramp mit EURC implementieren Sie SEP-24, damit Benutzer Euros einzahlen und direkt EURC erhalten können.

SEP-10 ist "Web-Authentifizierung für Stellar". Ablauf: 1) Server generiert eine Challenge (Transaktion mit manage_data op), 2) Client signiert mit seinem privaten Schlüssel, 3) Server validiert die Signatur und gibt ein JWT aus. Verwendung: Benutzer ohne Passwörter authentifizieren, nur mit ihrer Wallet.

Soroban ist Stellars Smart-Contract-Plattform, basierend auf Rust/WASM. Unterschiede zu Solidity: speichersicher (Rust), expliziter Zustand mit TTL (Daten verfallen), gemessene Ressourcen (CPU, I/O, Bandbreite), keine "Gas-Kriege" (vorhersagbare Gebühren). Vorteil: erbt Stellar-Sicherheit und Compliance.

1) Build: cargo build --release --target wasm32-unknown-unknown. 2) Optimieren: soroban contract optimize. 3) Deploy: soroban contract deploy --wasm target/.../contract.wasm --network mainnet --source SECRET. 4) Initialisieren: soroban contract invoke --id CONTRACT_ID --fn initialize. Kosten: ~100-500 XLM je nach Vertragsgröße.

Alle Soroban-Daten haben ein Ablaufdatum (TTL). Typen: temporary (verfällt und wird gelöscht), persistent (verfällt, kann aber wiederhergestellt werden). Zur Verlängerung: extend_ttl() im Code oder soroban contract extend. Kosten: proportional zu Datengröße × Zeit. Best Practice: Automatisieren Sie Erneuerungen für kritische Daten.

Klassische Assets (EURC, USDC, XLM) werden automatisch als SAC (Stellar Asset Contract) gewrappt. Um die Vertragsadresse zu erhalten: stellar contract id asset --asset EURC:ISSUER --network mainnet. Dann token::Client aus soroban-sdk für transfer, approve, balance verwenden. Interface ähnlich ERC-20.

payment: sendet exaktes Asset A an Empfänger. path_payment_strict_receive: "Ich möchte, dass der Empfänger genau X von Asset B erhält, mit meinem Asset A über die beste DEX-Route". path_payment_strict_send: "Ich sende genau X von A, Empfänger erhält, was an B resultiert". Verwenden Sie path_payment für Auto-Konvertierung EURC→XLM→USDC.

Stellar hat natives Multisig mit Schwellenwerten. Jeder Unterzeichner hat ein Gewicht (1-255), Operationen haben Schwellenwerte (low, medium, high). Beispiel 2-von-3: Unterzeichner mit Gewicht=1, high_threshold=2. Operation set_options zum Hinzufügen/Entfernen von Unterzeichnern. Anwendungsfall: Gemeinschaftskonten, DAO-Governance, Treuhand.

Claimable Balances ermöglichen das Senden von Assets, auch wenn der Empfänger keine Trustline hat. Sie hinterlegen EURC mit Bedingungen (wer beanspruchen kann, Zeitfenster). Der Empfänger beansprucht, wenn er bereit ist. Anwendungsfall: Onboarding neuer Benutzer, B2B-Zahlungen mit Lieferbestätigung, geplante Zahlungen.

1) Emittentenkonto erstellen (cold, offline). 2) Verteilungskonto erstellen (hot). 3) Verteilung richtet Trustline für das Asset ein. 4) Emittent sendet Token an Distributor (dies "prägt"). 5) Optional: Emittent mit set_options(master_weight=0) sperren, um das Angebot zu fixieren. Nicht vergessen: stellar.toml für Metadaten.

Asset-Flags für regulatorische Compliance. AUTH_REQUIRED: Emittent muss jede Trustline genehmigen (KYC). AUTH_REVOCABLE: Emittent kann Konten einfrieren (Sanktionen). AUTH_CLAWBACK: Emittent kann Token zurückfordern (Gerichtsbeschluss, Betrug). Für regulierte Token (Security-Token, Stablecoins) sind typischerweise alle drei aktiviert.

DEX ist offen: Sie brauchen keine Genehmigung. Schritte: 1) Angebote erstellen (manage_sell_offer / manage_buy_offer) für Ihr Paar TOKEN/XLM oder TOKEN/USDC. 2) stellar.toml mit Token-Metadaten veröffentlichen. 3) Listing auf Frontends anfordern (StellarTerm, StellarX). Anfängliche Liquidität ist entscheidend.

Öffentlicher Schlüssel (G...): Ihre "Stellar-Adresse", teilbar, zum Empfangen von Geldern. Geheimer Schlüssel (S...): NIEMALS teilen, zum Signieren von Transaktionen. Ableitung: Ed25519 asymmetrische Kryptografie, geheim → öffentlich (irreversibel). Verlust des Secrets = permanenter Verlust der Mittel.

Muxed-Konto = Basiskonto (G...) + numerische ID (u64). Format: M.... Verwendung: Börsen können ein G...-Konto und Millionen virtueller Unterkonten für Benutzer haben. Beim Empfang einer Zahlung an M... ist das Memo unnötig—die ID ist in der Adresse eingebettet. SDK: MuxedAccount.fromAddress().

Sponsorship ermöglicht einem Konto, die Reserven eines anderen zu bezahlen. Anwendungsfall: Neue Benutzer brauchen kein XLM zum Starten, Sie sponsern ihr Konto und Trustlines. Operationen: begin_sponsoring_future_reserves + Aktion + end_sponsoring_future_reserves. Sie können das Sponsorship später auch widerrufen.

Für Hot Wallets (automatisiert): HSM (AWS CloudHSM, Azure HSM) oder KMS mit Envelope-Verschlüsselung. Für Cold/Multisig: Ledger + Air-Gapped-Signierung. Niemals im Klartext in Code/Config. Praxis: Separate Konten für Operationen (hot, begrenztes Guthaben) und Tresor (cold, multisig).

Pre-Auth tx ist ein Transaktions-Hash, der mit set_options als Unterzeichner hinzugefügt wird. Sie kann nur einmal ausgeführt werden und wird automatisch entfernt. Anwendungsfall: Treuhand ohne aktiven Vermittler, geplante Zahlungsfreigabe, Migration zwischen Konten.

Stellar hat native Schutzmaßnahmen: 1) Sequenznummer: strikt inkrementell pro Konto, eine Tx kann nicht wiederverwendet werden. 2) Network-Passphrase: unterschiedlich zwischen Mainnet/Testnet, Replay zwischen Netzwerken unmöglich. 3) Timeout: timeBounds für begrenzte Gültigkeit.

Basisgebühr: 100 Stroops (0,00001 XLM) pro Operation. Eine Transaktion mit 3 Operationen = 300 Stroops. Bei Überlastung können Gebühren steigen (Fee-Bump-Mechanismus), aber historisch sind sie auf dem Minimum geblieben. Soroban: zusätzliche Messung für CPU/Speicher/Storage, typischerweise 10-100x klassisch, aber immer noch niedrig.

SDF (Stellar Development Foundation): gemeinnützig, entwickelt core-stellar und Ökosystem-Tools. CAPs (Core Advancement Proposals): Community-Vorschläge für Protokolländerungen. Validatoren: unabhängig, stimmen durch Konfiguration ihrer Quorum-Scheiben ab. Entscheidungen sind de facto dezentralisiert.

Für Entwicklung: horizon.stellar.org verwenden (Rate-limitiert). Für Produktion mit Volumen: eigener Horizon + PostgreSQL (16GB RAM, 2TB SSD Minimum). Vorteile: kein Rate-Limit, schnellere Antworten, Transaktionsprivatsphäre. Alternative: kommerzielle Anbieter (Blockdaemon, Infura geplant).

Stellar Core: Konsensknoten, validiert und schließt Ledger, Netzwerk-Backbone. Horizon: REST-API für Abfragen und Transaktionseinreichung, konsumiert Core via captive-core. Soroban RPC: spezifische API für Smart Contracts (Simulationen, Preflight, Invocations). Für vollständige App: Horizon für klassisch + Soroban RPC für Verträge.

Checkliste: 1) Network-Passphrase ändern ("Public Global Stellar Network ; September 2015"), 2) Horizon-URL ändern (horizon.stellar.org), 3) NEUE Konten generieren (Testnet-Schlüssel nicht wiederverwenden), 4) Konten mit echtem XLM finanzieren, 5) Soroban-Verträge neu deployen (neue Contract-IDs), 6) Integrationen mit kleinen Beträgen validieren.

Strategie: Kauf-/Verkaufsorders um den Mittelpreis mit Spread aufrechterhalten. Ops: manage_sell_offer / manage_buy_offer für Updates. Stream: Horizon-Streaming /order_book für Preisänderungen. Risiken: Impermanent Loss, Slippage bei volatilen Bewegungen. Tools: kelp (SDFs Market Maker), benutzerdefinierte Bots mit stellar-sdk.

Stellar hat native AMM (konstantes Produkt, wie Uniswap v2). Pools mit 2 Assets, proportionale Einzahlung, Pool-Anteile. Vorteile: Liquidität bereitstellen ohne aktive Order-Verwaltung, Swap-Gebühren verdienen. Ops: liquidity_pool_deposit, liquidity_pool_withdraw. Beachtung: Impermanent Loss gilt bei hoher Volatilität.

1) result_codes in Horizon-Antwort prüfen (tx_failed, op_failed). 2) Häufige Fehler: op_underfunded (unzureichendes Guthaben), op_no_trust (fehlende Trustline), op_line_full (Limit erreicht), tx_bad_seq (falsche Sequenz). 3) Soroban: Simulation vor Submit prüfen. 4) stellar.expert zur Visualisierung der vollständigen Transaktion.

MiCA (Markets in Crypto-Assets) ist eine EU-Verordnung, gültig ab Juni 2024 für Stablecoins und Dezember 2024 für alle CASPs. Für Stellar-Entwickler: In der EU emittierte Token müssen je nach ihrer Klassifizierung (EMT, ART, Utility) compliant sein. EURC ist bereits als E-Money Token von Circle konform.

Für KYC (gesetzliche Anforderung): Name, Ausweis, Adressnachweis. Öffentlich on-chain: Adressen, Transaktions-Hashes. NIEMALS speichern: private Schlüssel, Seed-Phrasen. DSGVO-Grundlage: rechtliche Verpflichtung (AML) und berechtigtes Interesse (Betrugsprävention). Aufbewahrung: 5 Jahre nach Kontoschließung.

Implementierungsmaßnahmen: 1) SEP-10-Authentifizierung (verifiziert Wallet-Besitz), 2) URL-Validierung im Frontend (warnen bei Imitations-Domain), 3) Benutzeraufklärung über NIE Seed-Phrasen teilen, 4) Signierwarnungen in Hardware-Wallets, 5) Allowlisting bekannter Empfängeradressen.

Ja. In der EU: MiCA erlaubt Mitgliedstaaten, Sandboxes anzubieten. In Deutschland: BaFin bietet regulatorische Sandboxes für Fintech. SDF hat auch den Stellar Community Fund (SCF) für geförderte Projekte. Vorteil: Mit echten Benutzern unter Aufsicht testen, bevor volle Lizenzierung.

Hängt von Jurisdiktion und Anwendungsfall ab. Soroban-Verträge können als unveränderlicher und auditierbarer Code als digitaler Beweis dienen, sind aber nicht inhärent "Rechtsverträge". Für Immobilien ergänzt der Soroban-Vertrag die notarielle Urkunde (ersetzt sie nicht). Der Smart Contract kann als elektronischer Beweis angehängt werden.