A public key is the outward-facing half of your blockchain keypair. It is derived mathematically from your private key and cannot be reversed to expose that private key. Your wallet address is itself derived from the public key through a separate hashing step. Understanding the chain private key → public key → address explains why blockchain identity works without a central registrar and why you can share your address freely without risk. This article explains each link in that chain: how the math works, why reversal is infeasible, and what the practical difference is between the public key and the address you hand to someone who wants to pay you.
​

A public key is a point on an elliptic curve derived from your private key using asymmetric cryptography. In Ethereum and most EVM chains it is 64 bytes long (128 hex characters). It is mathematically bound to your private key but cannot be reversed to reveal it. Every wallet address you share with others traces back to this public key. See what a private key is and how key pairs work for the full context on the other half of this relationship.
​

Blockchain ownership is not based on usernames or passwords. It is based on mathematical relationships between numbers. Your private key is a random 256-bit integer stored only in your wallet. Your public key is computed from that integer using a one-way function defined by the secp256k1 elliptic curve that both Bitcoin and Ethereum use. Because the function is strictly one-way, the public key can be freely shared. Anyone can use it to verify that a signature came from you, but nobody can use it to reconstruct your private key.
​

In practice, your public key acts as a permanent cryptographic credential you publish to the world. When you receive funds, the sender uses your address (which is derived from your public key) to lock value to your account. When you spend funds, you prove ownership by producing a signature that only your private key could have generated, and the network verifies that proof against your public key without you ever revealing the private key itself. The secp256k1 specification at bitcoin.it covers the curve parameters underlying this system.
​

Deriving a public key from a private key uses elliptic curve multiplication on the secp256k1 curve. The operation takes a fixed generator point G and multiplies it by your private key integer k, producing a new point on the curve. This multiplication is computationally fast in one direction and computationally infeasible to reverse, which is why the public key can be published without risk.
​

The secp256k1 curve is defined by the equation y² = x³ + 7 over a 256-bit prime finite field. The generator point G is a specific (x, y) coordinate hardcoded in the protocol spec. "Multiplying" G by k means adding G to itself k times using elliptic curve point addition, a geometric operation where each addition reflects a chord across the x-axis to produce a new curve intersection. After k additions, the resulting point is your public key, expressed as the 64-byte concatenation of its x and y coordinates.
​

Why is reversal computationally infeasible? Given the public key point P = k × G, finding k requires solving the elliptic curve discrete logarithm problem. No known algorithm solves this in polynomial time on a 256-bit curve. The secp256k1 field has roughly 2^256 possible values, a number larger than the estimated count of atoms in the observable universe. Even coordinated supercomputer attacks cannot exhaust this keyspace.
​

Some wallets store a compressed public key (33 bytes) rather than the full 64-byte uncompressed form. Compression drops the y coordinate and stores only a parity prefix byte (0x02 or 0x03) because y can be recomputed from x using the curve equation. Both forms represent the same key; the distinction is storage and encoding efficiency. Ethereum uses the uncompressed form internally during address derivation even when wallets display compressed keys.
​

This derivation happens entirely inside your wallet software or hardware device. The private key never leaves the secure environment; only the resulting public key (and the address derived from it) is broadcast or shared. The same mathematical foundation underlies cryptographic proofs and ZK verification used throughout modern blockchains.
​

An Ethereum address is not the public key itself. It is a 20-byte fingerprint of the public key produced by hashing and truncating. The derivation takes three steps: serialize the 64-byte uncompressed public key, hash it with Keccak-256 to produce a 32-byte digest, then keep only the last 20 bytes. Those 20 bytes, prefixed with "0x", become your Ethereum address.
​

Step 1: Serialize the public key as 64 raw bytes, which is the concatenation of the x and y coordinates each 32 bytes long. The 0x04 uncompressed prefix byte is not included in the hash input.
​

Step 2: Apply Keccak-256 to those 64 bytes. Keccak-256 is a sponge-construction hash function. It is similar to but not identical to SHA3-256; Ethereum adopted the pre-standardization version of Keccak before NIST finalized SHA-3. The output is always 32 bytes regardless of input length.
​

Step 3: Discard the first 12 bytes (24 hex characters) of the 32-byte hash. Keep the remaining 20 bytes. These are your Ethereum address in lowercase hex.
​

EIP-55 adds a checksum layer by selectively capitalizing letters in the address based on another Keccak hash of the lowercase address string. If a user accidentally transposes a character, the checksum capitalization pattern will not match and wallets can flag the address as invalid before funds move. This does not change the underlying bytes; it is a formatting convention that adds error detection. Modern wallets display and accept EIP-55 checksummed addresses by default. The full standard is at EIP-55 on eips.ethereum.org.
​

Because address derivation is a one-way hash, you cannot reconstruct the public key from an address alone. This layered one-way design means the worst case for address exposure reveals nothing about your public key, and the worst case for public key exposure reveals nothing about your private key. Each layer adds its own cryptographic boundary. For a closer look at how cryptographic proofs secure these operations at the protocol level, see what cryptographic proofs are and how blockchain verification works.
​

Sharing your public key exposes no exploitable information about your private key. The mathematical relationship between the two is strictly one-directional: computing a public key from a private key takes milliseconds, but reversing it requires solving the elliptic curve discrete logarithm problem, which has no known efficient solution. Current estimates place the compute cost of a brute-force secp256k1 attack far beyond any plausible hardware budget.
​

This asymmetry is not a provisional assumption. It is the foundational security guarantee of asymmetric cryptography. Every HTTPS connection, every code-signing certificate, and every blockchain transaction relies on the same principle. The NIST FIPS 186-5 standard for digital signatures endorses elliptic curve schemes precisely because the discrete log problem remains computationally hard on approved curves.
​

Practically, sharing your public key or the address derived from it is required to receive funds. When you give someone your Ethereum address to send USDC, you are giving them a hash of your public key. You are not giving them anything that could sign transactions, drain a wallet, or impersonate you. The only things someone can do with your address are send funds to it and view its transaction history on a block explorer.
​

The one future risk worth naming is quantum computing. A sufficiently powerful quantum computer running Shor's algorithm could theoretically solve the discrete logarithm problem. Ethereum researchers are actively tracking post-quantum cryptography standards. Addresses where funds have never been spent are particularly protected because they expose only the hash of the public key, not the public key itself, adding one more computation layer an attacker would need to defeat.
​

There is a common misconception that giving someone your public key is equivalent to giving them partial access. It is not. Even if an attacker holds your public key alongside thousands of observed signatures from your account, they still cannot produce a new valid signature. The ECDSA signature scheme requires the private key for every signing operation. Observed signatures are mathematically useless for forging new ones. This is different from password-based systems, where observing repeated logins could eventually leak credential information. Elliptic curve cryptography has no equivalent exposure mechanism.
​

This safety guarantee is also why self-custody wallets can operate without trusting any third party. You share your address publicly, the network uses it to verify your signatures, and nobody in between needs to hold your keys. For more on the self-custody model this enables, see what a non-custodial wallet is and how self-custody works.
​

A public key and a wallet address are two distinct objects that are often used interchangeably but are not the same. The public key is 64 bytes of raw elliptic curve data. The wallet address is 20 bytes produced by Keccak-256 hashing the public key and keeping only the last 20 bytes of the digest. Neither can be reversed to produce the other, and neither can be reversed to reach the private key.
​

In daily use you share your address, not your public key. Addresses are shorter (42 characters including the 0x prefix compared to 130 characters for an uncompressed public key), human-readable enough to double-check visually, and protected by EIP-55 checksum capitalization. Block explorers, payment forms, and wallet UIs all work with addresses.
​

The public key becomes visible to the network only when you broadcast a signed transaction. The ECDSA signature attached to the transaction mathematically encodes enough information for nodes to recover the public key and confirm it hashes to the sending address. Until that first outbound transaction, only your address is publicly known. Wallets that have only received funds but never sent any have their public keys unexposed, though this is a practical observation, not a guaranteed cryptographic protection.
​

Understanding this distinction matters in two contexts beyond everyday use. First, when using hardware wallets or multi-sig setups, you sometimes share an extended public key (xpub) rather than individual addresses, and understanding that the xpub can derive all child addresses but not any private key matters for privacy decisions. Second, when interacting with smart contracts that perform signature-based authentication, the contract may recover and verify the public key directly rather than checking the address. Understanding this distinction also explains how recovery phrases generate entire trees of key pairs deterministically from a single seed.
​

The three objects in a blockchain identity stack are often described together but serve completely different roles. The table below covers five dimensions that matter for anyone building intuition about how they relate. The derivation chain is private key → public key → address, and each arrow is irreversible.
​

The NIST comparison of key types and their security properties is documented in NIST SP 800-186 on elliptic curve cryptography.
​

When you send a transaction, your wallet signs the transaction data with your private key using ECDSA. Any node on the network can then verify that signature using only the public key, confirming you authorized the transaction without ever learning your private key. This verification is what makes trustless transaction finality possible without a central authority.
​

The signing process works as follows. Your wallet hashes the transaction data (recipient, amount, nonce, gas parameters) to produce a fixed-length digest. It then uses your 32-byte private key and a random nonce to compute a signature consisting of two 32-byte integers, conventionally labeled r and s. A third value, v (1 byte), encodes enough information for a verifier to recover the correct public key from r and s without needing you to supply it separately. This is called ECDSA public key recovery.
​

When the transaction reaches a full node, the node uses the r, s, and v values to algebraically recover the candidate public key, hashes it to derive the candidate address, and checks that the candidate address matches the "from" field of the transaction. If they match, the signature is valid. If they do not, the transaction is rejected. No trusted intermediary is needed at any step. The entire verification runs in microseconds on commodity hardware, which is why a global network of thousands of nodes can independently validate every transaction without relying on any single authority.
​

Smart contracts extend this through the ecrecover precompile, which exposes ECDSA recovery as an onchain function. This allows contracts to verify off-chain signatures submitted as calldata, enabling patterns like gasless meta-transactions, permit-based token approvals (EIP-2612), and multi-sig authorization schemes where multiple private keys must sign before a contract will execute.
​

The security guarantee behind all of this is that forging a valid signature requires knowing the private key. Given only the public key and a signature, an attacker can verify that the signature is authentic but cannot produce a new one that will pass verification. This asymmetry is what makes trustless blockchain interaction possible: every transaction carries its own cryptographic proof of authorization that any participant can independently verify.
​

No. A public key can only be used to verify signatures, not produce them. It cannot be reversed to produce the private key, and it cannot authorize any onchain transaction. The only information an exposed public key leaks is the ability to link it to your transaction history, which is already visible onchain via your address on any block explorer.
​

They are different objects derived from the same private key. Your public key is 64 bytes of raw elliptic curve data. Your wallet address is 20 bytes produced by applying Keccak-256 to the public key and retaining the last 20 bytes of the output. You cannot reconstruct the public key from the address alone, and neither can be reversed to the private key.
​

Your public key is embedded in the ECDSA signature of every transaction you broadcast. Until you send your first outbound transaction, only your address appears onchain. After any signed transaction, your public key can be mathematically recovered from the signature by anyone inspecting that transaction data. An address that has only received funds exposes only the address hash, not the underlying public key.
​

Most EVM chains (Ethereum, Polygon, Arbitrum, Base, Optimism) use secp256k1 ECDSA with identical derivation logic, so the same private key produces the same address on all of them. Bitcoin also uses secp256k1 but a different address encoding (Base58Check or Bech32). Solana uses Ed25519 on the Curve25519 elliptic curve, producing 32-byte public keys used directly as addresses. The cryptographic principles are the same; the curve parameters and encoding formats differ.
​

An xpub is a public key used in hierarchical deterministic wallets to derive all child public keys and addresses in a branch of the wallet tree. Sharing your xpub lets someone derive every address in that branch and monitor your full onchain activity, but it still cannot produce any private key or sign any transaction. Share xpubs only with services that explicitly require them, such as watch-only wallets or accounting integrations.
​