TDGOLD has no contract address. It has an issuer.

TDGOLD is a classic Stellar asset: a ledger entry created by one account, not code deployed at an address. The asset code and the issuing account do every job a contract address does elsewhere, in a wallet, an explorer, a payment and a trustline. The same pair turns up at step three of the buying walkthrough, which is where most people meet it first.

On an EVM chain a token is a program, and the address is where that program lives. Stellar puts the same behaviour in the protocol instead: balances, payments, the order book and the opt-in that lets an account hold an asset are all ledger operations, identical for every classic asset on the network.

So there is no per-token code, nothing to deploy, and no address to deploy it at. Every balance is stored to seven decimal places whatever the asset, which means there is not even a decimals field to look up. Creation follows the same logic: Stellar has no mint operation, and the issuing account brings supply into circulation by sending a payment.

An asset code on Stellar is not unique and was never meant to be. Any account can issue a token called TDGOLD, so the issuing account is the half that separates them, and it is why wallets, explorers and SEP-1 files always ask for the two together.

Some interfaces take one string rather than two separate fields. Stellar documentation and most tooling write a classic asset as the code, a colon, then the issuing account.

Length alone decides the format. One to four characters is credit_alphanum4, five to twelve is credit_alphanum12. TDGOLD is 6 characters, so Horizon reports credit_alphanum12 in its asset_type field, which the glossary entry on code formats unpacks in full.

The distinction surfaces where a URL encodes it. Stellar.Expert asset URLs end with a numeric suffix for the type, 1 for alphanum4 and 2 for alphanum12, so the TDGOLD link ends in 2. Use the other suffix and the link is dead, which looks the same as an asset that does not exist.

Soroban, the smart contract environment on Stellar, cannot reach a classic asset directly, so the protocol supplies a wrapper for it: the Stellar Asset Contract, the same standard implementation for every classic asset.

Its address is a contract strkey, 56 characters beginning with C, and nobody assigns it. It is derived from the asset code, the issuing account and the network passphrase, so it is fixed in advance, computable offline, and different on testnet than on the public network. The wrapper still has to be deployed once before a contract can call it, and any account may do that.

No value is printed here, deliberately. A C address on a web page is the easiest thing in this document for an impersonator to swap, and a wallet holding, sending or trading TDGOLD never needs one.

A classic payment has no approve step and leaves no allowance sitting on your account. The asset moves in a payment signed by the account holding it, and no other account can be given standing permission to spend that balance.

There is no proxy and no admin key either, because there is no upgradeable code to sit behind one. The nearest equivalent is the flags object Horizon returns on the issuing account: auth_required, auth_revocable, auth_immutable and auth_clawback_enabled. The TDGOLD issuance procedure rejects all four, and that object is where you confirm it.

There is no hidden mint, because issuance is a payment and a locked account cannot sign one. When you check that on an explorer, read the signer list rather than the key weight alone: an account can look locked and still have a second signer able to act.

TDGOLD is issued on the Stellar public network and nowhere else. There is no bridge and no wrapped version, so a TDGOLD contract on Ethereum, BSC, Base or Solana is a different token that took the name.

The shapes do not match either. An address on Ethereum, BSC or Base is 0x followed by 40 hexadecimal characters, and a Solana address is base58. A Stellar issuing account is 56 characters starting with G, a Stellar contract 56 characters starting with C. Reusing a name across networks costs nothing, so the issuing account is the only part worth comparing.

Stellar keys are base32 over the letters A to Z and the digits 2 to 7. The digits 0, 1, 8 and 9 do not exist in that alphabet, so an address containing one of them is not a Stellar key at all. A strkey also ends in a checksum, so most single character typos decode as invalid rather than as a working account.

What no checksum catches is a substitution: another valid account, belonging to somebody else. Settlement takes about five seconds and is final, so paste both values rather than retyping them, then close the loop with the four checks that read from the ledger.