En token er ikke længere blot en digital mønt med et navn og et antal enheder. Moderne blockchains kan koble en token sammen med identitet, dokumentation, rettigheder, gebyrer, valideringer, kontrolmekanismer og programmerbare regler. En token kan derfor repræsentere alt fra én dollar eller et gram guld til en obligation, en faktura, en ejendom, en adgangsret eller et helt sæt kontraktlige rettigheder. Vi ser på TOP10 og blivere klogere på den høje innovationsevne som kan ligge hos dig selv med WEB3, Blochchain og Digital Suverænitet.
Stellar er langt fremme, men sandheden er, at Ethereum, Solana, Cardano, Hedera, Tezos og flere andre har udviklet sig forskelligt, og på nogle områder mere omfattende modeller. Derfor bør man vælge en OPEN STANDARD, der ikke lukker om få stablecoins, kan have flere handelspar og kan connecte til WEB3 med alle standarder.
Heldigvis er vi ikke lukket til enkelte standarder, stablecoins og AutoAPI kan tage faciliteter efter dine behov. Som udgangspunkt bruger vi XLM som er en stablecoin der kan benyttes af Stellar. I “gamle dage kaldte man XLM for LUMEN. Stellar-netværket eller XLM stablecoin er dog aldrig blevet hacket og tømt/manipuleret af en angriber. Ikke at der nogen der hele tiden forsøger, men der er en stærk sikkerhed i Stellar.
En token består i virkeligheden af flere lag
Det er vigtigt at skelne mellem hvad der fysisk ligger i tokenstrukturen, hvad der ligger andre steder på blockchainen, og hvad tokenet blot henviser til.
En moderne token kan principielt bestå af følgende lag:
| Lag | Eksempel |
|---|---|
| Identifikation | Token-ID, asset code, symbol, issuer |
| Økonomi | Supply, decimaler, mint, burn, gebyrer |
| Ejerskab | Wallet, balance, ejerhistorik |
| Metadata | Navn, beskrivelse, billede, aktivtype |
| Dokumentation | Link eller hash til kontrakt, revision, certifikat |
| Kontrol | Freeze, pause, clawback, administrator |
| Overførselsregler | Hvem må købe, sælge eller modtage |
| Programmering | Smart contracts, automatiske betalinger, tidsregler |
| Eksterne data | Pris, reserve, renter, markedsdata via oracle |
| Juridisk betydning | Hvad tokenet repræsenterer og hvilke rettigheder der følger med |
Det afgørende er derfor ikke alene spørgsmålet “hvilke oplysninger ligger i tokenet?”, men snarere:
Hvilke oplysninger, rettigheder og regler er kryptografisk knyttet til tokenet?
Det er en langt større konstruktion.
Stellar er langt mere avanceret end den klassiske XLM-model antyder
Den oprindelige Stellar-model er forholdsvis enkel. En klassisk Stellar Asset identificeres grundlæggende ved kombinationen af:
Asset code + issuer account
Det er denne kombination, der gør eksempelvis en bestemt USD forskellig fra en anden USD udstedt af en anden Stellar-konto. Asset code kan sammen med issuerens adresse identificerer aktivet entydigt.
Det er derfor lidt misvisende at sige, at selve den klassiske Stellar-token “indeholder” eksempelvis virksomhedens adresse, logo, reserveattestation og vilkår.
De oplysninger findes i stedet i et andet lag.
Stellar.toml fungerer som aktivets digitale identitetskort
Issuer-kontoen kan knyttes til et home_domain, og på dette domæne offentliggøres en stellar.toml efter SEP-1.
Her kan blandt andet angives:
- organisationens juridiske navn
- hjemmeside
- logo
- fysisk adresse
- supportadresse
- asset code
- issuer
- beskrivelse
- om aktivet er backed af et andet aktiv
- hvilken aktivtype der ligger bag
- eksempelvis fiat, aktie, obligation, råvare eller fast ejendom
- indløsningsinstruktioner
- reserveattestation
- øvrige oplysninger om aktivet
Stellar Development Foundation har udarbejdet både den officielle dokumentation og tillige er der fri support m.v.
Man kan derfor forenklet sige:
Blockchainen siger: “Dette er aktiv ABC udstedt af konto XYZ.”
Metadata siger: “ABC repræsenterer 1 gram fysisk guld, opbevaret i Zürich, og kan indløses efter disse betingelser.”
Det er en MEGET vigtig forskel.
Stellar har nu tre egentlige tokenmodeller
Stellar beskriver i 2026 selv tre hovedmodeller:
| Stellar-model | Hvad den egner sig til |
|---|---|
| Stellar Asset + SAC | Betalinger, stablecoins og simple udstedte aktiver |
| SEP-41 Contract Token | Programmerbare tokens og speciallogik |
| SEP-57 / T-REX | Regulerede aktiver og institutionelle RWA’er |
SAC betyder Stellar Asset Contract og gør klassiske Stellar-assets tilgængelige for smart contracts.
SEP-41 går længere. Her implementeres tokenet som en kontrakt, og udvikleren kan tilføje sin egen logik.
SEP-57 bygger videre på denne model med T-REX, Token for Regulated EXchanges, og er målrettet regulerede og institutionelle real-world assets med indbyggede compliance-regler. Stellar beskriver modellen som fuldt programmerbar med udvidelig compliance-logik.
Det betyder eksempelvis, at der kan konstrueres regler som:
Tokenet må kun overføres til wallets, der opfylder regel A.
eller:
Ved hver overførsel tilbageholdes et bestemt gebyr.
eller:
Administrator kan blokere bestemte overførsler.
eller:
Ejerskabet må kun overgå, hvis en ekstern betingelse er opfyldt.
Det er her, en token begynder at ligne et programmerbart digitalt værdipapir eller aktiv frem for blot en kryptovaluta.
Top 10: hvor avancerede er de forskellige tokenmodeller?
Nedenstående Top 10 er ikke en rangliste efter markedsværdi. Det er en teknisk sammenligning af ti førende blockchainmiljøers muligheder for metadata, regler og aktivtokenisering.
| Netværk og model | Metadata | Programmerbare regler | Issuer-kontrol | Særligt interessant |
|---|---|---|---|---|
| 1. Stellar, SAC, SEP-41, SEP-57 | Meget høj | Meget høj | Meget høj | Kombinerer betalingsnetværk, issuer-identitet, ekstern metadata, smart contracts og regulerede RWA-modeller. |
| 2. Ethereum, ERC-20/721/1155 | Meget høj | Meget høj | Afhænger af kontrakten | Smart contract kan i princippet definere næsten vilkårlig tokenlogik. ERC-1155 kan håndtere fungible, non-fungible og semi-fungible aktiver i samme kontrakt. |
| 3. Solana Token Extensions | Meget høj | Meget høj | Meget høj | Metadata, transfer fees, transfer hooks, permanent delegate, confidential transfers, non-transferable tokens og flere andre funktioner findes som extensions. |
| 4. Cardano CIP-68 | Meget høj | Høj | Høj | Metadata kan ligge on-chain i et datum, opdateres og læses direkte af Plutus smart contracts. |
| 5. Hedera Token Service | Høj | Høj | Meget høj | Native KYC, freeze, pause, wipe, supply control, custom fees og metadata keys uden krav om egen Solidity-kontrakt. |
| 6. Tezos FA2 | Meget høj | Meget høj | Afhænger af kontrakten | Én kontrakt kan håndtere flere token-typer. Metadata kan indeholde brugerdefinerede felter, og transferregler kan programmeres. |
| 7. Algorand ASA | Høj | Middel til høj | Meget høj | Native manager, reserve, freeze og clawback samt URL og kryptografisk metadata-hash. |
| 8. Polkadot Hub Assets | Middel | Høj via Polkadot SDK | Meget høj | Rollebaseret owner, admin, issuer og freezer samt on-chain asset metadata og cross-chain anvendelse. |
| 9. XRP Ledger | Middel | Middel | Meget høj | Trust-line tokens understøtter authorization, freeze, clawback og automatiske transfer fees. Den nyere MPT-model udvider tokenarkitekturen yderligere. |
| 10. Cosmos SDK | Middel | Meget høj på kædeniveau | Afhænger af kæden | x/bank registrerer denomination, navn, symbol, beskrivelse, enheder, supply og om overførsel er tilladt. Yderligere logik kan bygges i blockchainens egne moduler. |
Solana har måske den tydeligste “alt-i-tokenet”-model
Solanas Token Extensions er særlig interessant i forhold til selve spørgsmålet om, hvor meget information og funktionalitet der kan følge et token.
Token Extensions kan blandt andet omfatte:
TokenMetadataMetadataPointerTransferFeeConfigPermanentDelegateTransferHookNonTransferableInterestBearingConfigConfidentialTransferMemoTransfer- token groups og group members
Solana viser endda et officielt eksempel, hvor et NFT kan have dynamiske data som en spilfigurs level og inventory lagret on-chain i et key-value-system.
Det er meget tæt på idéen om tokenet som et egentligt digitalt objekt.
Cardano kan gøre metadata levende
Cardanos CIP-68 er interessant af en anden årsag.
I stedet for kun at have en statisk metadatafil kan CIP-68 benytte et reference NFT, hvor metadata ligger i et on-chain datum.
Det betyder, at metadata kan:
- læses af smart contracts
- opdateres
- have brugerdefinerede felter
- ændre tilstand
- knyttes sikkert til selve brugerens token
Cardano nævner selv brugen til dynamiske NFT’er og andre aktiver, hvor metadata skal kunne udvikle sig.
Det åbner eksempelvis mulighed for et aktiv, hvis registrerede status ændrer sig fra:
CREATED
til:
INSPECTED
til:
APPROVED
til:
DELIVERED
uden at man behøver udstede et nyt token.
Eksempel 1: Et token for fysisk guld
Forestil dig, at et selskab udsteder én token for hver ounce fysisk guld.
Tokenmiljøet kunne være struktureret således:
| Oplysning | Eksempel |
|---|---|
| Asset ID | GOLD-84721 |
| Aktivtype | Physical gold |
| Vægt | 31,1035 gram |
| Renhed | 999,9 |
| Serienummer | ABC92831 |
| Vault | Zürich |
| Udsteder | Gold Company AG |
| Ejer | Wallet 0x… |
| Reservebevis | Hash + link til dokument |
| Revision | Hash + revisionsdato |
| Forsikring | Police-ID + dokumenthash |
| Redemption | Ja |
| Minimum redemption | 1 token |
| Transfer restriction | Kun godkendte wallets |
| Freeze | Ja |
| Clawback | Ja |
| Seneste kontrol | 14.08.2026 |
Det er ikke nødvendigt eller hensigtsmæssigt at gemme hele revisionsrapporten på blockchainen.
En bedre arkitektur kan være:
Blockchain: ejer, token-ID, regler og dokumenthash.
Metadata: beskrivelse af guldbarren.
Dokumentlager: revisionsrapport, forsikring og certifikat.
Hvis PDF-filen senere ændres med blot ét tegn, vil dens kryptografiske hash være anderledes.
Tokenet kan derfor fungere også som et digitalt bevislag oven på det fysiske aktiv.
Dette har især hensyn til svindlere der netop bliver fældet af vores samarbejdende kryptovalutarevisor.dk eller f.eks. klimarevision.dk da de live kan se regnskaber, tilstande, volumens og f.eks. validering eller værdier.
Eksempel 2: En tokeniseret virksomhedsobligation eller medarbejderobligation
En obligationstoken kunne eksempelvis være knyttet til:
| Felt | Eksempel |
|---|---|
| Issuer | ABC Holding S.A. |
| Instrument | Senior secured bond |
| ISIN | LUxxxxxxxxxx |
| Nominalværdi | EUR 1.000 |
| Kupon | 5,50 % |
| Udstedelsesdato | 01.09.2026 |
| Udløb | 01.09.2031 |
| Valuta | EUR |
| Jurisdiktion | Luxembourg |
| Prospekt | Dokumenthash |
| Pant | Security document hash |
| Betalingsdato | Automatisk beregnet |
| Transferregel | Kun kvalificerede adresser |
| Status | Active |
| Indfrielse | Automatisk ved maturity |
Her kan smart contract-logikken i princippet håndtere mere end blot ejerskabet.
Den kan eksempelvis beregne betalinger, kontrollere transferregler, registrere corporate actions eller udløse handlinger på bestemte datoer.
Tokenet er dermed ikke alene bevis på et aktiv.
Det kan også være en maskinlæsbar model af aktivets rettigheder og regler.
Eksempel 3: En ejendom kan få en digital tvilling
Et tokeniseret ejendomsaktiv kunne eksempelvis være knyttet til:
Property ID: DK-84721
Address: Example Street 10
Asset type: Commercial property
Ownership share: 0.001 %
Valuation: DKK 125,000,000
Valuation date: 01.08.2026
Land registry reference: ...
Insurance hash: ...
Lease document hash: ...
Audit status: VERIFIED
Distribution right: 0.001 %
Transfer status: ACTIVE
Det interessante er, at værdien kan opdeles. Ejendommen kan eksempelvis repræsenteres af 100.000 identiske fungible tokens, mens selve ejendommens dokumentation og identitet ligger i et andet token eller metadataobjekt.
Dermed kan man kombinere:
Asset identity + fractional ownership + rettigheder + dokumentation + programmering. Der er kun ganske få der kan se fordele i dette, eller forstå det. Men dem der forstår det er f.eks. kollektiver der dele lån, agronomer, minere og ganske få advokater og revisorer.
Hvad bør ligge på blockchainen, og hvad bør ikke?
At noget teknisk kan lagres på blockchainen betyder ikke, at det bør gøres.
| Type information | Bedste placering |
|---|---|
| Token-ID | On-chain |
| Ejer/wallet | On-chain |
| Balance | On-chain |
| Mint/burn | On-chain |
| Transferregler | On-chain |
| Freeze/clawback | On-chain |
| Dokumenthash | On-chain |
| Status | Ofte on-chain |
| Kort metadata | On-chain eller metadata |
| Store PDF-dokumenter | Eksternt lager/IPFS |
| Fotos og video | Eksternt lager/IPFS |
| Personoplysninger | Normalt ikke offentligt on-chain |
| Pas eller identitetsdokumenter | Ikke offentligt on-chain |
| Fortrolige kontrakter | Krypteret/off-chain |
Det sidste er også juridisk vigtigt.
GDPR artikel 5 kræver blandt andet dataminimering, og artikel 17 indeholder retten til sletning under de betingelser, bestemmelsen fastsætter. Permanent lagring af identificerbare personoplysninger på en offentlig og praktisk uforanderlig blockchain kan derfor skabe betydelige databeskyttelsesproblemer. Jf. Europa-Parlamentets og Rådets forordning EU 2016/679 artikel 5 og 17.
Den teknisk mere robuste model er derfor ofte at gemme beviset for informationen, eksempelvis en hash, credential eller attest, frem for selve personoplysningen.
Tokenet selv behøver heller ikke kende hele sandheden
Der er yderligere en vigtig sondring og strategisk bestbreed sikkerhedspolitik.
En blockchain-token ved ikke automatisk:
- hvad et hus er værd
- om en guldbarrer stadig ligger i boksen
- om et selskab er solvent
- hvad EUR/USD-kursen er
- om et skib er ankommet til Rotterdam
- om en obligation er misligholdt
Sådanne informationer kommer fra den virkelige verden. Man kan tillade det, men vi bruger ikke AI i disse sammenhænge, og anbefaler det ikke.
De skal leveres via eksempelvis:
oracle → smart contract → tokenstate
Det betyder, at en token kan være ekstremt avanceret, men den er stadig afhængig af kvaliteten af de oplysninger, der føres ind i systemet.
Fra “token” til digitalt aktiv med egen identitet
Udviklingen går derfor fra den simple model:
TOKEN = navn + antal
til:
TOKEN = identitet + ejerskab + metadata + dokumentation + rettigheder + regler + tilstand + ekstern information.
Og netop her er Stellar interessant. Stellar begyndte som en meget effektiv model for udstedte aktiver og betalinger. Med stellar.toml, SAC, Soroban=nu er det nye navn SmartContracts, SEP-41 og SEP-57 kan samme økosystem nu bevæge sig fra en simpel USD-token til programmerbare institutionelle real-world assets.
Men Stellar er ikke alene og Stellar samarbejde med alle andre i de økosamfund der er opstået indenfor de store stablecoins og altcoins. Ethereum og Tezos giver meget stor frihed gennem smart contracts. Solanas Token Extensions flytter usædvanligt mange funktioner ind i selve tokenstandarden. Cardano CIP-68 gør metadata dynamiske og on-chain. Hedera har bygget en stor del af administrations- og kontrolfunktionerne direkte ind i sin native Token Service.
Det interessante spørgsmål i næste generation af Web3 er derfor næppe alene:
“Hvad er tokenets kurs?”
Det bliver i stigende grad:
“Hvad repræsenterer tokenet, hvilke oplysninger kan verificeres, hvilke rettigheder følger med, og hvilke regler kan selve aktivet håndhæve digitalt?”
Kilde: #StellarDevelopmentFoundation, #Ethereum, #Solana, #Cardano, #Hedera, #Tezos, #Algorand, #Polkadot, #XRPL, #Cosmos, Jesper.Christiansen@agiludvikling.dk
Fotokredit: agiludvikling.dk, stock.adobe.com
Personer/Firmaer/Emner/#: #Token, #Tokenisering, #Stellar, #XLM, #Soroban, #SEP41, #SEP57, #TREX, #Ethereum, #ERC20, #ERC721, #ERC1155, #Solana, #TokenExtensions, #Cardano, #CIP68, #Hedera, #HTS, #Tezos, #FA2, #Algorand, #Polkadot, #XRPL, #Cosmos, #RWA, #RealWorldAssets, #Blockchain, #WEB3, #SmartContracts, #DigitalAssets
Copyrights: Ⓒ 2026 Copyright by agiludvikling.dk, kan deles ved aktivt link til denne artikel.