Solana addresses, keys, transaction signatures and token mints

An address is a label for finding account state

Solana represents an account address as a 32-byte value, usually displayed as a base58 string. Base58 is a way of turning bytes into printable characters. You can copy the string into an explorer or supply it to an RPC method that expects an account address.

The address tells the network which record you mean. It does not, by itself, tell you what the record does. A user's ordinary SOL account, a token mint and an executable program all have addresses. Open the record to learn its type and owning program.

You can also calculate or display an address before an account exists there. A newly created wallet can show a receiving address while a network lookup finds no funded account yet. The address is the intended location; the account is the state that exists at that location.

For an ordinary SOL payment, your recipient supplies their receiving address. For a token, a wallet normally resolves the appropriate token account. An exchange can impose its own deposit instructions, so use the address and network from the exact asset's deposit flow.

Public keys and private keys do different work

A keypair links a private signing key with a public verification key. The private part creates a signature over a message. The public part lets other participants check that signature. In a normal user account, the public key is also the familiar receiving address.

The key is useful because the network can verify an approval without receiving the secret. If you send your public address to a friend, they can use it to pay you. Sending your private key gives them the ability to produce approvals under that key.

A recovery phrase is a backup mechanism used by many wallets to recreate keys. One phrase can derive multiple accounts, depending on the wallet's derivation scheme. That is why an app's profile name, a selected account and a complete wallet recovery are different levels of information.

Not every Solana address has a corresponding private key. Programs also use program derived addresses, or PDAs, whose signing privileges work through the runtime. You will meet them in token accounts and application state; the PDA guide explains the mechanism.

A transaction signature identifies a signed attempt

After you approve a transaction, a wallet or application can show its signature, often labelled a transaction ID or hash. Solana commonly uses the first signature of the transaction as this lookup identifier.

Paste that identifier into an explorer for the correct cluster to read the operation. The result can show programs, instructions, the execution error, fees and balance changes. An account address opens an account view; it is not a substitute for the signature of one particular transfer.

Consider two attempts to pay the same invoice. If an application rebroadcasts the same signed bytes, the transaction identity stays the same. If it builds a new message with a new blockhash and signs again, it creates another attempt with another signature. Your invoice ID should link both attempts so a late result can still be reconciled.

A signature can exist before successful execution. The signer can calculate it locally, and an RPC can acknowledge submission before the network accepts a result. Use the signature to investigate status, then read execution success separately.

Verify a token by its mint

A mint identifies a token issuance

A token's mint account holds issuance-level information such as decimals, supply and applicable authorities. Token holding accounts refer to that mint and record balances under particular authorities.

The mint is the reliable identifier for choosing between tokens with the same ticker. Anyone can create another token with a familiar display name. Matching the word USDC or an image in a wallet does not establish that you found the issuer's asset.

Circle publishes this mainnet Solana USDC mint: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v. Compare the complete address with the issuer's current publication. That address describes the asset's mint; do not use it as your personal receiving address.

Asset identity is network-specific. A test token with a similar name on devnet has separate state. A bridged representation can also have a different mint and backing mechanism from a token issued directly on Solana.

Choose the identifier for the job

You want a friend to send SOL. Give the receiving address shown for your intended Solana account. Do not send recovery material. After the payment, obtain the transaction signature if you need to inspect the transfer.

You want to check a swap's output token. Open the output mint from the quote or transaction. Confirm the issuance and relevant token program. A screenshot of the token's name is insufficient to reproduce that check.

You need support for a missing transfer. Provide the cluster and transaction signature, plus the receiving address and asset identity. This lets support distinguish a failed execution, a wrong network and an internal service-credit delay.

You are inspecting a program. Use the program's published address and read its executable and loader information. Do not assume a public profile's creator address is the executable program ID.

A useful record keeps identifiers in named fields: network, sender, recipient, mint and transaction signature. Clear names prevent a technically valid string from answering the wrong question.

Common questions