Private Key vs Public Key vs Address: What Each One Actually Does

A private key is a secret 256-bit number whose only job is signing transactions, which on a blockchain is ownership; the public key is derived from it and lets anyone verify those signatures without ever seeing the secret; and the address is a short public identifier derived from the public key that exists so people can pay you. Derivation runs one way only — private key → public key → address — so nobody can work backwards from an address to the private key that controls it. The practical rule falls straight out of that math: your address and public key are safe to publish, and your private key and seed phrase are never safe to share with anyone, for any reason. In WATS the private key is generated on your device and stays there — WATS is fully non-custodial across all four products and never holds a key — and the WATS NFC Metal Card stores no private keys at all; it tap-authenticates to keys that live inside the WATS apps.

Three names, one chain of math

Wallets blur all three objects into a single interface, which is why the words get used interchangeably. They should not be. Each one sits at a different point in the same one-way chain of math, and each has a completely different security profile: one is the master secret, one is a public verification tool, one is a mailbox label. Knowing which is which is the difference between sharing safely and losing everything.

What does the private key actually do?

A private key is an enormous random number — 256 bits on Bitcoin and Ethereum, drawn from a space of about 2^256 possibilities, a 78-digit number, which is why guessing one is not a realistic attack. Its only job is signing: producing a cryptographic proof that authorizes one specific transaction. On a blockchain, the ability to sign is ownership. There is no account behind the key, no password reset, no recovery desk — whoever knows the number controls the funds, instantly and irreversibly.

What is the public key for?

The public key is computed from the private key with elliptic-curve math — the secp256k1 curve on Bitcoin and Ethereum, Ed25519 on Solana. Its job is verification. This is asymmetric cryptography in one sentence: the private key creates signatures, and the matching public key lets anyone on the network check them without ever seeing the secret. That single asymmetry is what makes a blockchain possible — thousands of strangers can confirm you authorized a payment while learning nothing that would let them forge the next one.

Is the address the same as the public key?

No — on most chains the address is a fingerprint of the public key, produced by hashing it and encoding the result into something shorter and checksummed. On Ethereum it is the last 20 bytes of a Keccak-256 hash of the public key; on Bitcoin the key is hashed and encoded, and on legacy and SegWit address types the full public key is only revealed the first time you spend from an address (Taproot addresses instead place a tweaked public key directly on-chain).

Not every chain hashes, though. A Solana address is the ed25519 public key itself, simply encoded in base58; a TON address encodes a hash of the account's initial state, which commits to the public key rather than to the key alone. So the rule that always holds is about direction, not hashing: the address is derived from the public key, and no chain lets you run that chain backwards to the private key. The three objects line up like this:

Object	What it is	Its job	Safe to share?
Private key	A 256-bit secret number	Signs transactions	Never — sharing it is handing over the funds
Public key	Derived from the private key	Verifies signatures	Yes — that is its purpose
Address	Derived from the public key — a hash of it on Ethereum and Bitcoin, the key itself on Solana	Receives funds, labels history	Yes — with a privacy trade-off

Why can't anyone work backwards from your address?

Because the derivation runs through one-way functions. Where the address is a hash — Ethereum, Bitcoin — turning it back into a public key would mean finding a hash preimage; where the address simply is the public key, as on Solana, that first step is no barrier at all. Either way the wall that actually protects you is the same one: recovering a private key from a public key means solving the elliptic-curve discrete-logarithm problem. As of 2026, no known technique does that at these key sizes in any feasible time. Large-scale quantum computers could eventually threaten that step — one reason the way Bitcoin's legacy and SegWit address types hide the public key until first spend has quiet defensive value — but that threat remains theoretical today.

What does a signature actually prove?

A signature proves exactly two things: that the signer possesses the private key matching a given public key, and that they approved this precise message — this recipient, this amount, this nonce. Change a single byte of the transaction and the signature no longer verifies. It does not reveal the key itself; you can sign forever without leaking the secret. Ethereum leans on this elegantly: nodes recover the public key from the signature itself and check that it hashes to the sending address — the signature carries its own identification.

This is also why no legitimate process ever needs your key. Verification is something the network does with your signature, using only public information. Any site, DM or "support agent" that asks for the key or the phrase behind it is not verifying anything — it is collecting.

Where does the seed phrase fit in?

One level above the private key sits the seed. A seed phrase — those 12 or 24 words — encodes the master entropy from which a modern wallet deterministically derives every private key it will ever use, across accounts and across chains. That is the HD-wallet design: one secret upstream, unlimited key pairs downstream, all regenerable on any compatible wallet — the full derivation path is covered in what an HD wallet is. The practical consequence fits in one line: protect the seed and every key is protected; leak the seed and every key is leaked.

What is safe to share — and what never is

The sharing rules fall straight out of the math:

• Address — safe to share; it is how people pay you. The cost is privacy, not security: anyone can watch an address's entire history on a public chain.
• Public key — safe to share; verification is its purpose. It reveals nothing that enables forgery.
• Private key or seed phrase — never, to anyone, for any reason. No legitimate wallet, support agent or airdrop will ask. Entering a seed on a website is not a risk — it is the loss itself, merely undated.

This is also what "not your keys, not your coins" literally means. On an exchange, the exchange's keys sign — you hold a promise, not crypto, as FTX's customers learned in 2022. In a non-custodial wallet, your key signs, so the asset is yours in the only sense a blockchain recognizes.

Where WATS fits

Everything above describes a boundary, and a wallet's honesty is measured by which side of it the wallet sits on. WATS sits on the self-custody side across all four of its products — the Chrome extension, the mobile app, the Hot Wallet and the NFC Metal Card. The private key is generated on your device, it stays with you, and WATS never holds a key. There is no WATS-side copy to leak and no WATS-side recovery to request, which is precisely why the sharing rules above are not optional advice.

Two specifics are worth stating plainly, because both are common points of confusion in any article about keys:

• The WATS NFC Metal Card does not store private keys. It is a tap-to-authenticate companion, closer to a physical security key than to cold storage: each card carries a unique ID, pairs to exactly one device, and uses an NTAG 216 chip with AES-128 over ISO/IEC 14443 in a military-grade metal body rated IP68 and tested to MIL-STD-810. The keys stay inside the WATS apps and the card proves it is you tapping. Details are on the NFC card page.
• WATS covers Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana and TON. One seed, one derivation tree, keys on all eight. Bitcoin appears throughout this article because secp256k1 and hash-based addresses are the clearest teaching examples for how keys become addresses; WATS does not natively support Bitcoin.

Covering eight chains has one practical consequence for fees. Normally each of those networks wants its own native gas token in hand before your signature can even be broadcast. WATS lets network fees be paid in a single token, ATS, instead of each chain's native gas token, using ERC-4337 account abstraction on EVM chains and LayerZero OFT so one ATS balance moves omnichain. That is not a discount — it changes which token pays, not what the network charges — and collected ATS is burned from a 100M supply toward a 30M floor. WATS is the first and only wallet to combine ERC-4337 + OFT single-token fees, charged instead of native gas, with that burn.

Bottom line

The private key signs, the public key verifies, the address receives — and because derivation runs one way only, the last two are safe to publish while the first never is. A signature proves possession of the key and approval of one exact transaction, nothing more, and the seed phrase sits one level above it, regenerating every private key the wallet will ever derive. Get those relationships straight and most "send your key to verify" attacks simply stop working on you, because you already know that verifying a signature has never required the secret. If you want that model enforced by the wallet rather than only by your own discipline, install WATS from the download page: the private key is generated on your device, WATS never holds it, a single recovery phrase covers all eight supported chains, and the NFC Metal Card authenticates rather than stores.