Keys, signatures and addresses

A private key is secret cryptographic material used to create signatures. A corresponding public key allows signatures to be verified. A valid signature demonstrates satisfaction of a cryptographic authorisation condition for the signed data; it does not independently demonstrate informed commercial consent.

An address identifies a destination or account under a network's conventions. Its relationship to keys depends on the system. For a conventional Ethereum externally owned account, the address is derived from the public key. A contract account has an address but is governed by code rather than simply by a private key corresponding to that address.¹

Bitcoin addresses specify how a payment output should be constructed. Different address forms can refer to different spending conditions. Avoid treating every address as a public key written in another format.²

For operational purposes, distinguish the identifiers:

In practice: what each identifier does

Suppose a treasury pays a supplier from an Ethereum account. The supplier sends an address through an agreed communication channel. The treasury verifies that address, constructs a transaction and signs it. After submission, the wallet displays a transaction hash. The supplier later sees a credit in its account with a custodian.

Each identifier answered a different question:

• The supplier's address told the treasury where to direct the transaction.

• The public key and signature allowed the network to verify the sender's cryptographic authority.

• The transaction hash allowed both parties to locate the submitted transaction.

• The supplier's customer account reference told the custodian which customer to credit.

None could safely substitute for another. A transaction hash sent by email is not a payment instruction. A valid address is not proof of the beneficiary's identity. A blockchain transaction arriving at a custodian does not identify the customer unless its allocation process can connect the transfer to the correct account.

Authenticated intent can still be wrong

Suppose a treasury employee approves payment to a verified counterparty, but compromised software constructs a transaction to a different address. The signing system signs that transaction. The network can correctly verify the signature and process an economically unauthorised payment.

No cryptographic forgery is required in this example. The failure occurred when the commercial instruction was translated into signed data, or when the signer verified what it was authorising.

A signature-control process must therefore bind the approved intent to the actual network instruction. For a simple payment, this includes the destination, asset, amount, network and fee conditions. For a contract call, it also includes the contract and action being invoked. The details visible in a wallet are a presentation of the signed content, not a separate guarantee of its correctness.

Checksums help detect some transcription errors. Ethereum's ERC-55 specifies a mixed-case checksum convention for addresses. A correctly checksummed address can nevertheless belong to the wrong recipient. A checksum is not beneficiary verification.³

Likewise, proving control of an address through a challenge signature may support an onboarding process, but it does not establish the signer’s entire authority, exclusive control or the address's future safety. Treat the challenge as evidence of a specified capability at a specified time.