2. Keys, wallets, and addresses

The previous chapter showed Alice signing a transfer. This chapter explains what that signature proves, what an address represents, and how a program can control an address that has no private key.

Begin with three ideas

private key = secret ability to authorize
public key = public identity used to verify
signature = proof that a particular message was authorized

A signature does not hide the transaction. It lets anyone verify that the holder of the matching private key approved the exact message.

The irreversible boundary

Anyone who obtains a seed phrase or private key may be able to authorize transactions. Never place secrets in frontend code, Git, screenshots, tickets, chat, or AI prompts.

What the wallet actually does

When Alice presses Send, the wallet does not send a private key to the application.

Application builds message
  ↓
Wallet shows a signing request
  ↓
Alice approves
  ↓
Wallet signs locally
  ↓
Application receives the signature or signed transaction

A trustworthy dApp asks for a signature, not for a seed phrase. A hardware wallet can keep key material inside the device while still producing signatures.

Hashing, signing, and encryption are different

• A hash creates a fixed-length fingerprint of data.
• A signature proves authorization and message integrity.
• Encryption protects confidentiality.

Solana transactions are normally public. Signing a transaction does not encrypt its accounts, amount, or program calls.

Solana addresses

Solana account addresses are 32-byte values commonly displayed in Base58. Base58 is a readable encoding, not a security mechanism.

Two address families matter:

1. Public-key addresses can correspond to an Ed25519 private key.
2. Program Derived Addresses, or PDAs, are derived addresses designed not to have ordinary private keys.

An address alone does not reveal the account’s purpose. Read the account’s owner, executable flag, and data to understand what it is.

Keypair, wallet, and account are not synonyms

A keypair is cryptographic material. A wallet manages keys and signing. An account is on-chain state.

One wallet may control:

• a system account holding SOL;
• many token accounts;
• authorities stored inside program data;
• stake accounts;
• program upgrade or mint authorities.

Some accounts, such as PDAs, are controlled by program rules rather than by an external private key.

Why PDAs exist

Suppose a profile program needs exactly one profile per user. A central database could assign IDs, but an on-chain program can derive a predictable address:

seeds = ["profile", user public key]
program id = Profile Program
result = profile PDA

Any client can derive the same address. The program can verify the same seeds when the account is used.

A bump value is included during derivation to find a valid off-curve address. Because the result is off the Ed25519 curve, there is no normal private key for the PDA.

How a PDA authorizes actions

A PDA cannot produce a wallet signature. During a Cross-Program Invocation, the program that owns the PDA namespace can present the correct seeds and bump to the runtime. The runtime then treats the PDA as signed for that invocation.

User signs transaction
  ↓
Profile Program verifies user
  ↓
Profile Program invokes Token Program
  ↓
Runtime recognizes profile-vault PDA seeds
  ↓
PDA acts as token authority for that CPI

This is why PDAs are widely used as vault authorities, escrow authorities, configuration addresses, and user-specific state addresses.

Do not confuse three forms of control

Account owner

The base account owner field identifies the program allowed by runtime rules to modify account data or debit lamports.

Application authority

A program can store an authority public key inside account data and require that key to sign future updates.

Token authority

A token account is owned at the runtime level by a Token Program, while a wallet or PDA is recorded inside token data as the authority allowed to transfer tokens.

Example

A vault token account can be owned by the Token Program, hold USDC, and name an application PDA as its transfer authority. All three statements can be true at the same time.

What a program must verify

For a sensitive instruction, checking is_signer is not enough. The program may need to verify:

• the signer is the expected authority;
• the account address or PDA seeds are correct;
• the account owner program is correct;
• the account data type and version are correct;
• the account is writable only when necessary;
• the token mint and token authority match expectations.

Safe development practice

Use disposable Devnet keys. Browser applications should request signatures from a wallet adapter rather than generating and storing user secrets in local storage. Backend authorities should use managed secret storage or dedicated signing infrastructure, not a plaintext keypair in the repository.

Check your understanding

You are ready to continue when you can answer:

1. Why does changing a transaction after signing invalidate its signature?
2. Why is Base58 not encryption?
3. Why can a PDA have authority without having a private key?
4. Why can the Token Program own an account while a wallet controls transfers?

Next, learn how thousands of validators agree on one accepted history in Network, validators, and consensus.