Public & Private Keys Explained: Wallet Addresses, Seed Phrases, Signatures (Complete Guide)
Public and private keys explained properly means separating four things people often mix up: the private key (control), the public key (verifiability), the address (a shareable identifier), and the seed phrase (a backup that can generate many private keys). In this TokenToolHub guide, you’ll learn how keys are created, how wallets derive accounts, what signatures actually prove, why typed signing matters, how address formats differ across chains, and what modern attackers really exploit (hint: it’s usually authorization, not “guessing your key”).
Prerequisite reading: If you are still building core blockchain intuition, start with Blockchain Technology Guides. If you’re moving into safer wallet design, also review Smart Contract Wallets.
TL;DR
- Private key = control. It is a secret number used to create signatures. Whoever can sign can move funds.
- Public key = verifiability. Others can verify your signature using your public key, without knowing your private key.
- Address = shareable identifier. It is derived from the public key (or from a hash/encoding of it), and is what people send funds to.
- Seed phrase = backup + key factory. A 12 or 24-word mnemonic can deterministically generate many private keys and addresses.
- Signatures do not “send coins.” They authorize a state change that the network executes under protocol rules.
- Most real losses are authorization mistakes. Unlimited approvals, blind signatures, and phishing are bigger risks than key-guessing.
- For structured learning, continue in Blockchain Advance Guides.
In traditional finance, your security boundary is a password, a bank, and a help desk. In self-custody, your security boundary is keys + signing decisions. That is why understanding keys is not optional: it is the difference between “I clicked a button” and “I authorized something irreversible.”
This guide stays beginner-friendly while being developer-useful. You will leave with a clean mental model, practical setup patterns, and a threat map that reflects how drains happen today.
Private key → Public key → Address (the mental model)
Most modern chains use public-key cryptography. The pattern is simple: a private key is kept secret, a public key is derived from it, and an address is derived from the public key. People send funds to addresses. The network accepts transactions only if they are authorized by valid signatures created with the private key.
Beginners often think “my wallet holds my coins.” In reality, your wallet holds (or protects) the key material used to authorize on-chain state changes. Your assets exist on-chain as balances and ownership mappings.
Anyone can see your inbox and send to it. Only the private key can press the send button. A signature is the proof you pressed that button intentionally.
// High-level (not exact implementation details)
privateKey = secureRandom(32 bytes)
publicKey = curveMultiply(privateKey) // secp256k1 on ETH/BTC, Ed25519 on Solana
address = encodeOrHash(publicKey) // chain-specific
// Core idea:
signature = sign(messageHash, privateKey)
valid = verify(signature, messageHash, publicKey)
Entropy and secure key generation
A private key is only as strong as its randomness. “Randomness” here is called entropy: unpredictability. If keys were generated from predictable patterns, attackers could brute force them using dictionaries or precomputed lists.
Modern wallets generate keys from secure sources: OS random number generators, secure enclaves, or hardware RNGs. The biggest beginner trap is the idea that you can “invent” randomness. Humans are predictable.
Entropy checklist (what to do and what to avoid)
- Do: use reputable wallets and let the wallet generate keys internally.
- Do: prefer hardware wallets for holdings and long-lived accounts.
- Do not: create keys from quotes, lyrics, or “my own secret phrase.”
- Do not: use random key generators from unknown websites.
- Do not: screenshot, email, or cloud-store seed phrases.
Seed phrases and HD wallets (BIP-39, BIP-32, BIP-44)
Most wallets you use today are hierarchical deterministic (HD). That means one backup can generate many accounts in a predictable tree structure. The core pieces are widely used standards:
- BIP-39: defines mnemonic seed phrases (12 or 24 words) and how they convert into a master seed.
- BIP-32: defines deterministic key derivation from a master seed into child keys.
- BIP-44: defines a standard derivation path structure so wallets interoperate.
The practical takeaway is simple: Your seed phrase is not “one private key.” It is a generator that can reproduce many keys. This is why losing a seed phrase can be catastrophic, and why exposing it is worse than exposing one address.
No legitimate app needs your seed phrase. If a site asks for your seed phrase to “verify,” “sync,” “claim,” or “restore,” treat it as a theft attempt.
// Typical Ethereum-style path examples (common defaults)
m/44'/60'/0'/0/0 // first address
m/44'/60'/0'/0/1 // second address
m/44'/60'/1'/0/0 // second account branch (wallet-dependent)
Derivation paths and “missing funds” migrations
One of the most confusing moments for beginners is importing the same seed phrase into two different wallets and not seeing the same addresses. This usually happens because wallets can default to different derivation paths or account discovery strategies.
The fix is not panic. The fix is: check which derivation path each wallet uses and try the standard path presets. Some wallets provide account discovery that scans common paths. Others require manual selection.
If your address history exists on-chain, your funds are not “deleted.” You are likely just looking at a different derived address. Slow down, confirm the expected address from your records, and adjust derivation settings.
What a signature really is (and why it matters)
When you click “Confirm” in a wallet, you are not pushing a coin out of your phone. You are creating a signature over a specific message. That signature proves that the private key holder authorized the action. The network then validates the signature and, if the transaction follows protocol rules, applies the state change.
// High-level signing flow (conceptual)
messageHash = hash(transactionFields or typedData)
signature = sign(messageHash, privateKey)
if verify(signature, messageHash, publicKey) and protocolRulesPass:
include in block
update state
EIP-155: why chain ID exists
One classic risk is a replay attack: a signed transaction on one chain being replayed on another chain that interprets it the same way. EIP-155 introduces chain ID into the signature domain so a transaction signed for one chain is not valid on another. For everyday users, the takeaway is: modern wallets protect you against some cross-chain replay risks, but you still must confirm the chain you are on.
EIP-712: typed signing vs blind signing
Many real-world drains do not require stealing your private key. They require tricking you into signing something you do not understand. Typed signing aims to show human-readable structured data rather than raw hex. If your wallet shows unreadable data, treat it as high risk.
Safer signing checklist
- Prefer wallets and dApps that show readable signing prompts.
- Be suspicious of “Sign to continue” when no clear reason is provided.
- Separate “login signature” from “token approval” in your mind. Approvals can create long-lived permissions.
- When in doubt, stop and verify the contract and method on a block explorer or via simulation tools.
EIP-1271: contract wallets verify differently
In a typical wallet, a signature is verified against an EOA public key. In a smart contract wallet, “signature validity” can be defined by contract logic: multi-sig thresholds, guardians, time locks, spending policies. That is why smart contract wallets can be safer for high-value accounts, and why they require different mental models.
If you want to go deeper on how policy wallets change recovery and day-to-day safety, read Smart Contract Wallets.
Address formats and checksums (Ethereum, Bitcoin, Solana)
Addresses look similar to beginners: long strings of characters. But address formats are chain-specific and encode different assumptions. Mixing them up is a common operational mistake.
| Chain family | Key type (high level) | Address format | Checksum behavior | Practical takeaway |
|---|---|---|---|---|
| Ethereum (EVM) | secp256k1 | Hex, 20 bytes, often 0x… | EIP-55 mixed-case checksum (sometimes all-lowercase) | Use ENS to reduce copy errors, but still verify |
| Bitcoin | secp256k1 | Base58Check or bech32/bech32m (bc1…) | Checksums built into encoding | Address type affects fees and script behavior |
| Solana | Ed25519 | Base58 public key string | Encoding integrity helps, but chain context matters | Do not assume ETH-like rules apply |
The fact that a string “looks like an address” does not mean it is valid for your chain, wallet, or asset type. Always confirm the network, asset standard, and receiving address format before sending.
Wallet types: hot, cold, custodial, smart wallets
Wallet types are not a status symbol. They are different exposure models. The real question is: how exposed is the signing environment, and how large is the blast radius if something goes wrong?
Hot vs cold is operational security
A cold wallet reduces private-key extraction risk, but it cannot stop you from approving a malicious spender or signing away permission. That is why modern safety is a mix of: device security, domain verification, and permission hygiene.
Key management best practices
You do not need a perfect setup. You need a setup that fails safely, and habits that work when you are tired, distracted, or hyped by a market move. The best practices below are designed to reduce your worst-case outcomes.
Key management best practices
- Separate wallets by role: a vault wallet for holdings, a daily wallet for activity, and an experimental wallet for unknown dApps.
- Back up seed phrases offline: paper is fine short-term, metal is better long-term. Use two locations if you can.
- Never type seed phrases into a website: wallet restores happen in the wallet app or device, not in a browser form.
- Use minimal allowances: approve only what you need whenever possible.
- Revoke approvals periodically: treat approvals as ongoing permissions, not one-time actions.
- Verify domains: bookmarks beat search ads. Watch for lookalike URLs.
- Keep your vault boring: your vault wallet should not be the wallet you use for airdrops, random mints, or “try this new dApp.”
Recovery, rotation, and disaster planning
The moment to plan recovery is before anything goes wrong. Recovery is not only about “lost phone.” It also includes seed exposure, compromised devices, and inheritance planning.
A good plan assumes you will eventually lose a device or make a mistake. Your goal is to make that event annoying, not life-changing.
| Scenario | What it means | First actions | Long-term fix |
|---|---|---|---|
| Device lost | You lost the wallet app/device | Restore from seed on a clean device | Move holdings if you suspect exposure; improve backups |
| Seed exposed | Someone can recreate your keys | Generate new seed, move assets immediately | Rotate to fresh addresses; update records; revoke approvals |
| Phishing signature | You may have granted permission | Disconnect sessions, revoke approvals, move assets | Improve wallet separation; switch to safer signing habits |
| Team treasury risk | One signer compromise can drain | Pause policies, rotate signers, require threshold | Multi-sig or smart wallet with limits and delays |
Top threats: phishing, drainers, approvals, malware
Most losses are not cryptography failures. They are workflow failures. Attackers win by getting you to authorize something, not by “cracking” your private key.
Stop list: treat these as immediate red flags
- A website asks for your seed phrase.
- A wallet prompt shows unreadable data and pressure to sign.
- A dApp requires unlimited approvals for a token you care about.
- You arrived via an ad link and the domain looks slightly off.
- A “support agent” in DMs wants you to “connect” or “verify.”
Playbooks: personal, creator, and team setups
There is no single perfect setup. There is only a setup that matches your risk level and usage. Here are practical patterns that are easy to maintain.
Solo user setup (beginner to intermediate)
- Daily wallet: browser/mobile wallet for routine actions, low balances.
- Vault wallet: hardware wallet for holdings and long-term storage.
- Experiment wallet: separate address for airdrops, new dApps, mints, unknown contracts.
- Routine: revoke approvals monthly, and never connect the vault to random sites.
Creator or small business setup
- Revenue wallet: receive payments to a safer address (hardware or smart wallet).
- Ops wallet: low-balance wallet for day-to-day interactions and gas.
- Payout routine: sweep funds to vault regularly rather than keeping them in hot wallets.
Team or DAO treasury setup
- Multi-sig or policy wallet: require 2-of-3 or 3-of-5 signers for treasury moves.
- Limits and delays: consider spend limits and time delays for large withdrawals.
- Runbook: document incident response and signer rotation procedures.
Reading explorers and verifying what you sign
Explorers are your truth source. Interfaces can lie. The chain data is the final record. The fastest way to become “hard to scam” is learning how to read:
- Address page: balances, token holdings, transaction history, contracts interacted with.
- Transaction page: method, inputs, logs, gas used, status and confirmations.
- Contract page: whether code is verified, what functions exist, admin/upgrade indicators.
A phishing site can look identical to the real site. Your defense is verifying the actual contract addresses you are approving or calling. If you cannot verify, reduce risk: use a throwaway wallet or do not interact.
Gentle cryptography: why one-way derivation works
You do not need to do elliptic curve math to be safe, but you should understand the intuition: there is a one-way relationship between private keys and public keys. You can derive a public key from a private key, but reversing that derivation is computationally infeasible with current knowledge and computing power.
That is why attackers do not “guess keys” in real life. It is cheaper to trick humans than to break math.
// Intuition:
publicKey = oneWay(privateKey)
address = shorter(publicKey)
// Attacker reality:
breakMath is expensive
trickUser is cheap
Common myths and mistakes
- Myth: “My exchange login is my wallet.” Reality: that is custodial access, not self-custody.
- Mistake: storing seed phrases in screenshots or cloud notes. Fix: offline backup only.
- Myth: “If I know my address, I can recover.” Reality: you need the key or seed phrase.
- Mistake: unlimited approvals to unknown contracts. Fix: minimal allowances and routine revokes.
- Myth: “Higher gas fixes failing transactions.” Reality: gas cannot fix logical reverts, simulate and verify.
Turn key knowledge into safer habits
The fastest path to staying safe is combining the right wallet separation with permission hygiene. If you want deeper frameworks around modern wallet models and recovery, continue with Smart Contract Wallets and advanced guides.
Safety note: a hardware wallet reduces key extraction risk, but it cannot protect you from authorizing unsafe approvals. Make “verify and minimize permissions” your default routine.
Quick check
Use this to test your understanding before you move on.
- In one sentence, how do private key, public key, and address relate?
- Why is a seed phrase more powerful (and more dangerous) than a single private key?
- What does typed signing try to prevent?
- Name two reasons to separate a daily wallet from a vault wallet.
Show answers
1) Private key creates signatures, public key verifies them, address is a shareable identifier derived from the public key. 2) Seed phrases can regenerate many keys and accounts, so exposure compromises everything derived from it. 3) Typed signing reduces blind signing by showing human-readable structured intent. 4) It limits blast radius from phishing/drainers and keeps holdings away from risky interactions.
FAQs
Is a seed phrase the same as a private key?
No. A seed phrase is a backup that can deterministically generate many private keys (and therefore many addresses). A private key typically controls one specific account.
Can someone guess my private key from my address?
Not in any feasible way with current cryptography assumptions and computing resources. In practice, attackers target users through phishing and authorization tricks instead.
Why can importing the same seed into two wallets show different addresses?
Different wallets may use different default derivation paths or account discovery behavior. Your funds still exist on-chain at the original derived addresses, but the wallet may be looking at a different branch.
What is the safest simple setup for most users?
A daily hot wallet for small balances plus a hardware wallet for holdings, with an offline seed backup and regular approval revokes. Add a separate experiment wallet for unknown dApps to reduce risk.
Do smart contract wallets remove the need for seed phrases?
They can improve UX and recovery and can hide seed complexity from users, but key material and authorization still exist under the hood. The advantage is policy: multi-approval, limits, guardians, and recovery flows.
References
Foundational standards, specs, and reputable resources for deeper reading:
- Ethereum.org: Accounts
- Ethereum.org: Wallets
- Ethereum.org: Security
- EIP-155
- EIP-712
- EIP-1271
- BIP-39
- BIP-32
- BIP-44
- Bitcoin: A Peer-to-Peer Electronic Cash System (whitepaper)
- TokenToolHub: Blockchain Technology Guides
- TokenToolHub: Blockchain Advance Guides
- TokenToolHub: Smart Contract Wallets
Final reminder: your biggest enemy is not “someone cracking your key.” It is you authorizing something you did not verify. Slow down, verify domains, minimize approvals, and keep your vault away from experiments.
