Ga naar inhoud
BitcoinToolkit

Stellar (XLM): hoe betalingen, anchors en trustlines werken

Stellar is een op accounts gebaseerd netwerk ontworpen voor het uitgeven van activa, het wisselen en betalingen. De lumen, of XLM, is het native activum, de vergoedingsvaluta en het reserveactiva; niet-native activa worden uitgegeven door geïdentificeerde accounts en vereisen gewoonlijk trustlines. Deze pagina richt zich op hoe Stellar-betalingen, ankers en trustlines werken en de controles die gebruikers moeten uitvoeren voordat ze geld verzenden, vergoedingen betalen of het netwerk gebruiken.

Bereid een Stellar-betaling voor, rekening houdend met XLM-reserves, vergoedingen en trustlines voor uitgegeven activa.

Onderwerp:
Stellar
Marktmodus:
Alleen momentopname
Kostenactivum:
XLM
Tijdzone:
UTC

Deze pagina valideert geen uitgever, geeft geen padbetaling aan, berekent geen Soroban-voetafdruk of beveelt geen validator-quorum aan.

Eigendom van inhoud: BitcoinToolkit Redactieteam Technische referenties: officiële protocol- en ontwikkelaarsdocumentatie. Beoordelingsaanpak: technische uitleg wordt gecontroleerd tegen primaire bronnen en bijgewerkt wanneer het netwerk of activum verandert. Laatste inhoudsreview: Laatste dataintegratietest:

Hoe Stellar-betalingen, ankers en trustlines werken

Een tokennaam alleen is niet voldoende om een Stellar-activum te identificeren.

Stellar-workflow met Adres verifiëren, Bedrag kiezen, Vergoeding instellen, Uitzenden, Status bevestigen
Stellar-workflow van de eerste gebruikersbeslissing tot een geverifieerd resultaat.

Code plus uitgever

Niet-native Stellar-activa worden geïdentificeerd door een activacode en een uitgevend account. Een trustline machtigt een account om een specifiek uitgegeven activum aan te houden en voegt een grootboekvermelding toe. Twee activa kunnen dezelfde code delen terwijl ze verschillende uitgevers hebben, dus ontvangen of handelen op basis van alleen de ticker kan het verkeerde activum selecteren.

Stellar-transacties kunnen verschillende bewerkingen bundelen, waaronder betalingen, trustline-wijzigingen en gedecentraliseerde beursacties. Padbetalingen kunnen converteren tussen activa terwijl ze een gevraagd bestemmingsbedrag leveren, maar de route en limieten moeten worden beoordeeld. Netwerkfinaliteit compenseert niet voor het kiezen van een frauduleuze uitgever of een ongunstig pad.

Stellar-risico's vóór voltooiing

XLM ondersteunt betalingen, maar houdt ook accounts en grootboekvermeldingen economisch begrensd.

Native activum, vergoedingen en minimumsaldi

XLM is het enige Stellar-activum zonder uitgever of trustline. Het betaalt transactiekosten, financiert huur en draagt bij aan minimumsaldovereisten. Een account begint met een basisreservevereiste, en extra vermeldingen zoals trustlines, aanbiedingen of ondertekenaars kunnen de XLM verhogen die gereserveerd moet blijven.

Een portemonnee kan een XLM-saldo weergeven dat groter is dan het onmiddellijk besteedbare bedrag, omdat een deel is vergrendeld door reserveregels. Voordat u het maximale saldo verzendt of een activum toevoegt, moeten gebruikers de huidige grootboekvermeldingen inspecteren en voldoende XLM overlaten voor de bewerking en het resulterende minimumsaldo.

Stellar en Cardano: belangrijkste verschillen

Vergoedingen, Soroban-bronnen en finaliteit

Klassieke bewerkingen en slimme contracttransacties delen XLM-vergoedingen, maar gebruiken verschillende bronnenboekhouding.

Stellar-beslissingsdiagram dat identiteits-, uitvoerings- en voltooiingscontroles scheidt
Stellar-bevestiging lost niet elke latere operationele vraag op.

Opname en bronnenkosten

Elke transactie betaalt een opnamevergoeding in XLM. Tijdens congestie bepaalt de ingediende vergoeding de concurrentie voor grootboekruimte. Soroban slimme contracttransacties betalen ook bronnenkosten op basis van berekening en statusgebruik, inclusief opslaghuur. Een klassieke XLM-betalingsschatting is daarom geen betrouwbare schatting voor een contractoproep.

Stellar-validators gebruiken quorumsneden onder het Stellar Consensus Protocol om overeenstemming te bereiken over de grootboekstatus. Zodra een grootboek via consensus wordt gesloten, kunnen applicaties de resultaten als definitief behandelen volgens hun operationele beleid. Diensten moeten nog steeds het transactieresultaat en elk bewerkingsresultaat inspecteren voordat ze tegoeden crediteren.

Vergelijk vergoedingen, uitvoering, beveiliging en gebruikersworkflow voordat u kiest tussen Stellar en Hedera.

Controles vóór een Stellar-overboeking

Een correcte bestemming kan een niet-ondersteund activum nog steeds weigeren of verkeerd afhandelen.

Activa- en accountvoorbereiding

Bevestig de bestemmingsrekening, memo-vereisten en of de ontvanger een trustline heeft voor het exacte code-en-uitgever-paar. Controleer de besteedbare XLM van de afzender na reserves, schat het juiste vergoedingstype en beoordeel alle gebundelde bewerkingen. Beurzen vereisen vaak een memo, zelfs als het netwerkadres zonder geldig is.

Voor Soroban-interacties, simuleer de transactie met behulp van huidige netwerktools en beoordeel de resourcelimieten. Voor uitgegeven activa, onderzoek de uitgever en autorisatie-instellingen onafhankelijk. Een succesvolle Stellar-afwikkeling bewijst protocoluitvoering, niet de solvabiliteit van de uitgever of de bereidheid om in te lossen.

  • Match activacode en uitgever.
  • Houd voldoende XLM over voor reserves en vergoedingen.
  • Voeg een vereiste beursmemo toe.
  • Inspecteer elk bewerkingsresultaat.

Blader door gerelateerde crypto-referenties

Stellar-transactie- en vergoedingscontroles

Het XLM-resultaat heeft context nodig

Validators bereiken overeenstemming via het Stellar Consensus Protocol. Transacties bevatten geordende bewerkingen, betalen opnamevergoedingen in XLM, en kunnen interageren met uitgegeven activa of Soroban slimme contracten die bronnenkosten en opslagvereisten toevoegen.

Een Stellar-transactie kan geldig zijn terwijl de ontvanger nog wacht op meer bevestigingen of het geselecteerde adrestype niet kan gebruiken. XLM is het marktactief dat in de momentopname wordt getoond. XLM betaalt opname- en smart-contract-resourcekosten.

Wat Stellar-gebruikers moeten verifiëren en waarom dit ontwerp verschilt

Basisreserve- en vergoedingsparameters kunnen wijzigen. De pagina beoordeelt geen activa-uitgever.

Voor Stellar is de praktische volgorde: Adres verifiëren, Bedrag kiezen, Vergoeding instellen, Uitzenden, Status bevestigen. Bevestig de officiële bestemming en het huidige netwerk, inspecteer vervolgens het uiteindelijke saldo, de positie, het ontvangstbewijs of de gedocumenteerde uitgangsstatus die de taak daadwerkelijk voltooit: Bereid een Stellar-betaling voor, rekening houdend met XLM-reserves, vergoedingen en trustlines voor uitgegeven activa.

Stellar-transacties FAQ

Waarom kan ik mijn volledige XLM-saldo niet verzenden?

Een deel van het saldo kan worden gereserveerd voor de rekening en de grootboekposten ervan, en voor vergoedingen is ook XLM vereist.

Hoe wordt een Stellar-token geïdentificeerd?

Een uitgegeven asset wordt geïdentificeerd door zowel de assetcode als het uitgevende account.

Gebruiken Soroban-transacties XLM-kosten?

Ja. Zij betalen inclusief vergoedingen en extra resourcekosten in XLM.

Wat betaalt transactiekosten bij gebruik van Stellar?

Lumen (XLM) betaalt de toepasselijke netwerkvergoeding. XLM betaalt opname- en smart-contract-resourcekosten. Verifieer het geselecteerde netwerk voordat u ondertekent, omdat een latere goedkeuring, brug, claim of uitgang een andere transactie kan vereisen.

Bekende beperkingen

Marktgegevensmethodologie

De pagina gebruikt een CoinGecko geaggregeerde XLM/USD-momentopname. Voor deze entiteit wordt geen wisselkoersgrafiek weergegeven.

Bron van marktoverzicht
CoinGecko geaggregeerde marktgegevens (XLM/USD)
Cache
Snapshot cache is ongeveer 60 seconden.
Foutafhandeling
Geverifieerde gecachte gegevens zijn gelabeld als Cached of Delayed. Ontbrekende waarden blijven niet beschikbaar.
Overzichtstatus
Vertraagd
Probleem melden
Een marktgegevensprobleem melden →

Technische bronnen

Geselecteerde primaire bronnen ondersteunen de operationele uitleg. Marktprovider-attributie blijft afzonderlijk.

Redactionele informatie

Geverifieerde technische inhoud, beoordeelde bronnen en updategeschiedenis.

Gepubliceerd
Laatste beoordeling
Gegevensverificatie
Bronnen
Officiële documentatie