Private key

In brief

A private key is secret cryptographic material, often 32 bytes, that forms the secret half of a cryptographic key pair; its exact representation depends on the signature scheme. The corresponding public key is derived from it via elliptic-curve mathematics that is easy in one direction and computationally infeasible to reverse. Blockchain addresses may be produced from the public key through hashing or encoding steps that differ by network, but not every address is a public-key-derived signer address. Digital signatures created with the private key authorize transactions without revealing the key itself. Possession of the private key generally confers the ability to control the associated assets, subject to any additional controls such as multisignature schemes or smart-contract logic. Modern wallets often derive many private keys from a single seed phrase rather than storing isolated keys. A network cannot “reset” a lost key for an ordinary key-controlled account, although a multisig or programmable account may have a separately designed recovery path.

What a private key is

In public-key cryptography used by major blockchains, a private key is secret cryptographic key material. Wallets and protocols do not all represent that material the same way internally.

In secp256k1 systems such as Bitcoin and Ethereum, the private key is commonly a secret integer chosen uniformly from the valid scalar range 1 through (n-1). The curve order is (n=\mathtt{0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141}), which is slightly less than (2^{256}). The public key is the corresponding curve point.

Ed25519 systems, including Solana, begin from 32 bytes of high-entropy secret key material. RFC 8032 specifies that this 32-octet string is hashed and pruned to derive an internal signing scalar; that derived scalar, not the raw 32-byte string interpreted as a secp256k1-style integer, is what is used for signing. Implementations therefore must not treat every private key as the same kind of integer.

A correctly constructed transaction does not contain or transmit the private key. Wallets should keep that material secret and protect it at rest rather than expose it as ordinary plaintext. Its main role in this context is to produce digital signatures that prove authorization to spend or control assets under the applicable account, script or program rules.

Relationship to the public key

On secp256k1, the public key is computed from the private scalar by multiplication on the elliptic curve:

[ K = k \cdot G ]

where (k) is the private key and (G) is a fixed generator point defined by the curve parameters. This operation is deterministic and efficient; recovering (k) from (K) is the elliptic-curve discrete-logarithm problem, for which no efficient classical algorithm is known. On Ed25519, the public key is likewise a curve point, but it is computed from the derived signing scalar described above, not by treating the stored 32-byte secret as (k) in the secp256k1 sense.

Bitcoin has traditionally used ECDSA over secp256k1 and also supports BIP-340 Schnorr signatures for Taproot spends. Ethereum transaction signatures use ECDSA over secp256k1. Solana transaction signers use Ed25519. Consequently secret material generated and encoded for one curve or signing scheme must not simply be treated as a key for another.

From keys to addresses and accounts

The mapping from public key to the identifier used on-chain is not uniform:

• Bitcoin typically hashes the public key (SHA-256 then RIPEMD-160 for legacy addresses, or other constructions for SegWit/Taproot) and encodes the result.
• Ethereum takes the Keccak-256 hash of the uncompressed public key (without the 0x04 prefix) and retains the last 20 bytes, prefixed with “0x”.
• On Solana, every account address is a base58-encoded 32-byte value. A signer-controlled address can be an Ed25519 public key, while a program-derived address (PDA) has no corresponding private key.

Thus “private key,” “public key,” “address” and “account” are related but distinct concepts. An address identifies a destination or on-chain object; where a public-key signer controls it, the private key can authorize spending under the relevant rules. Smart-contract accounts on Ethereum and program-derived addresses on Solana are important examples of addresses that are not controlled by a single matching private key.

How signatures work

When a wallet creates a transaction, it uses the private key to produce a digital signature that authorizes the transaction according to the network’s serialization and signing rules. Anyone can verify the signature with the corresponding public key and confirm that the signer possessed the private key, without learning the private key itself. This property allows decentralized networks to accept transactions as authorized while keeping the secret material undisclosed.

Private keys versus seed phrases and wallets

Many modern wallets use deterministic key derivation. For BIP-39-style wallets the sequence is:

• High-entropy random data (entropy) is generated.
• That entropy is encoded as a mnemonic phrase, commonly 12 or 24 words.
• The mnemonic is converted via PBKDF2 into a BIP-39 seed.
• From that seed, a derivation scheme such as BIP-32 for secp256k1 or SLIP-0010 for Ed25519 derives a master private key and then child keys. Wallets may apply path conventions such as BIP-44 or ecosystem-specific variants.

One seed phrase can therefore regenerate many private keys and addresses across multiple chains and accounts when the restoring wallet supports the same derivation schemes and paths. The mnemonic, the seed, and the individual private keys are distinct.

A wallet application or hardware device is the software or hardware that stores or derives these keys and constructs signatures. The wallet is not itself the private key. Hardware wallets aim to isolate private-key material from the general-purpose host environment; some designs use secure elements and others use different isolation architectures. During normal signing, the design goal is to return a signature or signed transaction to the host without exposing the signing key, though backup and export models differ.

Loss and compromise

If a private key, or the seed that derives it, is permanently lost and no backup or separately configured recovery path exists, assets controlled solely by that key become inaccessible. The network cannot reset or re-issue control of an ordinary key-controlled account.

If an attacker obtains a private key that solely controls an account or set of UTXOs, the attacker can generally create valid signatures and transfer the assets. The practical impact depends on the account model:

• Simple single-signature externally-owned accounts or UTXOs are fully controlled by one key.
• Multisignature setups, smart-contract wallets, and programmable account abstractions can require additional signatures or conditions, so compromise of one key does not automatically grant full control.

Users should never paste private keys or seed phrases into websites, chat applications, AI assistants, support forms or any untrusted interface. Doing so hands control to whoever receives the data.

Cross-chain and practical notes

Many multi-chain wallets abstract differences between curves and networks by deriving chain-specific keys from a common seed along distinct derivation paths. This is a wallet convention, not a universal blockchain feature, and restoration requires compatible derivation rules. Reusing the same private-key material across different curves or chains is strongly discouraged for security and operational reasons.

Security ultimately rests on the quality of the randomness used to generate the original entropy or private key and on protecting that material. For secp256k1, the valid private-scalar range contains (n-1) values—extremely close to, but not exactly, (2^{256})—so exhaustive search is infeasible with classical computers when keys are generated uniformly. Ed25519 also starts from 32 bytes of cryptographically secure random data, but RFC 8032 processes those bytes differently.