Public keys, private keys and addresses: what each one actually does

Almost every serious crypto mistake traces back to confusing three things that sound similar and behave nothing alike. Once the distinction is clear, most security advice stops being a list of rules to memorise and becomes obvious.

The private key signs

A private key is a very large secret number. Its only function is to produce signatures: given a transaction, it generates a proof that the holder of the key authorised it. That is the whole job.

The critical property is that a signature can be verified by anyone without revealing the key that produced it. This is what makes the system work at all. It is also why the private key is the only one of the three that must remain secret, and why anyone who obtains it can move your funds without any further step. There is no password layer beneath it and no authority who can reverse the result.

The public key verifies

The public key is derived from the private key by a one-way calculation. Given the private key you can compute the public key trivially; given the public key you cannot recover the private key by any practical means. That asymmetry is the entire foundation.

Its job is verification. Anyone holding the public key can check that a signature was produced by the matching private key, which is how the network confirms that a transaction was authorised by whoever controls the funds. Publishing it costs you nothing.

The address receives

An address is derived from the public key, usually by hashing it and adding a checksum. It is shorter, includes error detection so a mistyped address is almost always rejected rather than accepted, and on most networks it does not reveal the public key until you first spend from it.

Its job is to be given out. An address is a destination, nothing more. Sharing one exposes no risk to your funds; the worst outcome is a loss of privacy, because anyone with the address can see its transaction history on a public ledger.

Where the seed phrase fits

A seed phrase is not a fourth key. It is a human-readable encoding of the number that generates your private keys — usually all of them, across many addresses, deterministically. This is why one phrase can restore an entire wallet.

It follows directly that a seed phrase is strictly more sensitive than any single private key, because it is equivalent to all of them at once. Every rule about seed phrases — never type it into a website, never photograph it, never store it in a password manager you do not control — follows from that one fact rather than from superstition. Our glossary entry covers the encoding itself.

What this makes obvious

With the three roles straight, several pieces of standard advice stop needing to be memorised:

• Sharing an address is safe, because an address only receives. Sharing a private key is total loss, because a private key signs.
• A hardware wallet is valuable specifically because it performs signing inside the device, so the private key never exists on an internet-connected computer.
• “Verify the address” is about the checksum and about clipboard-replacing malware, not about secrecy.
• A service that asks for your seed phrase to “validate” or “restore” anything is asking for every key you have. There is no legitimate version of that request.

The one-way relationship

The direction of derivation is worth holding onto: seed phrase to private key to public key to address, each step easy forwards and infeasible backwards. Every practical consequence follows from that arrow. You can hand out the far end freely and must protect the near end absolutely, and nothing in between changes that.

Why one seed produces many addresses

Modern wallets are hierarchical and deterministic, which is a precise way of saying that a single seed generates an entire tree of keys by a defined procedure. Each branch produces a fresh private key, and each of those produces its own public key and address.

Two useful consequences follow. A wallet can hand out a new address for every payment without needing a new backup, because every one of those addresses descends from the same seed. And restoring that seed on different software recovers the same addresses, because the derivation procedure is standardised rather than proprietary.

It also explains a common confusion: seeing many addresses in a wallet does not mean many separate secrets exist. There is one secret, and everything else is derived from it. That is convenient and it is precisely why the seed phrase is the single point of total failure.

Signing does not reveal the key

It is worth being explicit about the property everything rests on. A signature is produced from the private key and the message, and can be checked against the public key — but observing any number of signatures does not let an attacker reconstruct the private key that made them.

This is what makes it safe to sign repeatedly with the same key rather than needing a fresh one each time. It also explains why signing a message to prove ownership of an address is a normal, safe operation, while entering a seed phrase never is. One is the intended use of the system and the other is handing over the system.

Where the model gets stretched

Two developments complicate the clean picture, and both are worth knowing about because they change what a signature means.

Multi-signature arrangements require several private keys to authorise a transaction, so no single key is sufficient. This removes the single point of failure at the cost of a more complex recovery story — you now have several secrets to protect and a policy about how many are needed.

Account abstraction, on networks that support it, allows the rules governing an account to be programmed rather than fixed: spending limits, time delays, or recovery by a designated party. Useful, and it means “whoever holds the key controls the funds” is no longer strictly true on those networks. The base mechanism is unchanged; what has changed is who is permitted to invoke it.