What is a Wallet & Blockchain Address?

Introduction

wallets and blockchain addresses are the basic interface between people and blockchains, but the names hide an important subtlety: a wallet is usually not the thing that holds assets, and an address is not the same kind of object on every chain. That confusion causes real mistakes. People think their funds “live in the app,” or that copying an address is mechanically simple, or that every blockchain uses addresses the way Bitcoin or Ethereum does. None of those assumptions is quite right.

The core idea is simpler than the jargon suggests. A blockchain records control rules over on-chain state. A wallet manages the cryptographic secrets and metadata needed to exercise that control. An address is a compact public identifier that tells other participants which control rule or destination you mean.

Once you separate those roles most wallet behavior starts to make sense.

• on-chain state
• private authorization
• public destination

That distinction also explains why wallets can be software, hardware, or even a split system across devices; why a 12- or 24-word backup can restore many addresses; why address formats differ so much between chains; and why sending to the wrong address is often irreversible. Here is the mechanism.

How does a blockchain wallet differ from a physical wallet?

In everyday language, a wallet is where money sits. On a blockchain, assets are tracked by the network’s ledger, not by your app or device. What your wallet really holds are the credentials and instructions that let you prove authority over some part of that ledger.

In Bitcoin terminology, even the word wallet already has two meanings. It can mean a wallet program; the software that generates keys, creates addresses, watches the chain, and signs transactions. Or it can mean a wallet file; the stored collection of private keys and related data. That distinction matters because “losing your wallet” could mean uninstalling an app, or it could mean losing the secret material that actually gives you control.

A good first approximation is this: a wallet does three jobs. It distributes public receiving information, it signs when you want to authorize a spend, and it talks to the network to learn balances and broadcast transactions. Bitcoin developer documentation explicitly notes that these functions can be separated into a public key distribution program, a signing program, and a networked program. That is not just an implementation detail. It is the reason watch-only wallets, hardware wallets, and air-gapped signing setups are possible.

If you use a full-service mobile wallet, all three roles often live in one app on one internet-connected device. That is convenient, but it is also why such wallets are more exposed: if the device is compromised, the attacker may gain access to signing capability. If you use a hardware wallet, the networked app and the signer are split. The computer prepares transactions, but the dedicated device keeps the signing key isolated and authorizes the signature separately.

This same separation shows up in institutional systems. In threshold signing, no single device or party ever reconstructs the whole private key. Cube Exchange, for example, uses a 2-of-3 threshold signature scheme for decentralized settlement: the user, Cube Exchange, and an independent Guardian Network each hold one key share, no full private key is ever assembled in one place, and any two shares are required to authorize a settlement. That is still a wallet system; just one where the signing authority is deliberately divided.

What is a blockchain address and how does it differ across chains?

An address is a public-facing identifier that helps other people or programs send assets to a destination you can later control. But “destination” means different things depending on the chain.

On Bitcoin, an address is primarily an encoding of spending conditions. In practice, wallet software creates public keys to receive satoshis and uses the corresponding private keys to spend them. The address is a shorter, more user-friendly representation of information that will become a locking condition in a transaction output. Different address types correspond to different script forms and encodings.

On Ethereum, an address identifies an account on-chain. Ethereum’s official docs define an account as an entity with an ETH balance that can send messages, and there are two kinds: externally-owned accounts (EOAs) controlled by private keys, and contract accounts controlled by code. So when someone says “my Ethereum address,” they often mean the address of an account whose state lives on-chain and whose authority usually comes from a private key.

On Solana, the picture is broader still. The network stores state in a key-value store where each key is a 32-byte address and each value is an account. A Solana address can identify an account backed by an Ed25519 public key, but it can also identify a program derived address (PDA); an address used by programs even though it is not just “a user public key” in the ordinary sense. So cross-chain intuition breaks easily: the same word, address, points to different underlying models.

That is the first thing smart readers often misunderstand. An address is always public, but it is not always “the hash of a user public key” and it is not always “a person’s account” in the same structural way. The wallet UI may make them look similar, yet the underlying object differs by chain.

How do private and public keys control access to funds?

The heart of a wallet is the keypair. A private key is secret and authorizes actions. A public key is derived from it and can be shared. The exact cryptography varies by chain, but the pattern is stable: control comes from proving knowledge of a secret without revealing it.

For Ethereum EOAs, the public key is generated from the private key using ECDSA, and the address is obtained by taking the last 20 bytes of the Keccak-256 hash of the public key, then prefixing it with 0x. That is why Ethereum addresses are 42-character hex strings including the 0x prefix. The address is not the public key itself; it is a derived identifier.

For Bitcoin, the public key also comes from a private key, but the address is an encoding tied to a script type rather than a single universal formula. Modern Bitcoin software prefers compressed public keys, which save almost 50% of the storage space compared with uncompressed keys. That does not change who controls the funds. It changes how the key is represented and, downstream, how wallets build outputs and addresses.

Notice the invariant across both systems. The blockchain does not need your private key. It needs a valid authorization artifact (typically a signature) that can be verified against public information already implied by prior outputs, account rules, or transaction structure. The private key stays off-chain. The signature is the proof.

This is why private key exposure is catastrophic. If someone gets the secret, they can usually create the same proof you can. Encryption helps only at rest. Bitcoin developer guidance is explicit that encrypting wallet files cannot stop an attacker who captures the decryption key or reads decrypted keys from memory. Security is not a magic property of “having a password on the app.” It depends on where signing authority actually exists and when it becomes available.

Why do modern wallets use a single seed to derive many addresses (HD wallets)?

Early wallets often behaved like loose collections of unrelated keys. That made backup awkward. If your wallet generated a new receiving address after your last backup, restoring from the old backup might miss funds tied to newer keys.

Modern wallets largely solve this with hierarchical deterministic, or HD, derivation. The basic idea is powerful: instead of generating each key independently, derive a whole tree of child keys from a single root seed. Backup the seed once, and you can recreate the same tree later.

In practice, that seed is often represented to humans as a mnemonic phrase; commonly 12 to 24 words. BIP-39 specifies how computer-generated entropy is encoded into such a mnemonic, and how the mnemonic plus an optional passphrase is transformed into a 512-bit binary seed using PBKDF2 with HMAC-SHA512. The phrase is not the key itself; it is a human-friendly transport and recovery format for the randomness from which the wallet’s hierarchy is rebuilt.

BIP-32 then defines how extended keys work. An extended private key is not just a private key. It is a pair of a private key and a 32-byte chain code. The matching extended public key contains the public key and the same chain code. That extra chain code is what lets the system derive child keys deterministically in a structured tree.

The reason this matters is not only backup convenience. It changes architecture. You can derive a public branch for generating receiving addresses without handing over the branch that can spend. That enables watch-only wallets, accounting tools, donation pages, merchant frontends, and other systems that need to produce addresses but should not be able to sign.

Here is a concrete example. Imagine a merchant who wants the website to display a fresh Bitcoin receiving address for every order, while keeping spending authority offline. With HD derivation, the merchant can put an extended public key on the webserver. The server derives a new child public key and corresponding address for each order. It can watch incoming payments and label them correctly. But because it only has the public branch, it cannot spend the received funds. The offline signer, which has the corresponding private branch, can later authorize withdrawals. The mechanism is simple: deterministic derivation preserves the relationship between public and private descendants, so both systems can stay synchronized without constantly exchanging new keys.

This is the point where notation like xpub and xprv comes from in Bitcoin ecosystems. BIP-32 serializes extended keys into Base58Check-encoded strings that commonly begin with xpub or xprv on mainnet. They are not ordinary public keys and private keys. They represent entire derivation subtrees.

Hardened vs non‑hardened derivation: what are the trade‑offs?

HD wallets come with a tradeoff that becomes important once keys are shared across systems. BIP-32 defines normal child derivation and hardened child derivation.

With normal derivation, an extended public key can derive child public keys. That is what makes watch-only systems practical. But it introduces a security caveat: knowledge of a parent extended public key plus any non-hardened child private key descending from it is effectively equivalent to knowing the parent extended private key. In other words, some combinations of “public” and “descendant secret” leak more than people expect.

Hardened derivation exists to block that class of cross-generational compromise. Hardened children cannot be derived from the parent extended public key alone. You need the parent private side. That makes hardened paths less convenient for public-only address generation, but safer for boundaries where key isolation really matters.

This is why standards like BIP-44 use hardened derivation at upper levels of the wallet tree. BIP-44 defines the common path shape m / purpose' / coin_type' / account' / change / address_index, where the apostrophe means hardened derivation. The organizing logic is clear: harden the levels that define major isolation boundaries (wallet purpose, blockchain, account identity) while leaving the lower public derivation levels available for practical address generation.

That path also explains how one seed can organize many coins and many accounts. coin_type' separates Bitcoin from other cryptocurrencies so the same seed does not casually reuse the same branch across chains. account' separates identities or sub-wallets. change distinguishes receiving addresses from internal change addresses. address_index steps through fresh addresses in sequence.

There is one caveat worth keeping in mind. Bitcoin developer docs warn that HD wallet programs are not expected to be fully compatible in every setting. So a seed alone is not always the entire story; derivation choices and conventions matter too. The fundamental idea is standard, but exact interoperability depends on shared assumptions.

Why do address formats (Bech32, hex) matter for safety and compatibility?

To users, address formats often look like branding differences. In reality, they encode technical decisions about error detection, script semantics, compatibility, and even QR efficiency.

Bitcoin’s Bech32 format is a good example. BIP-173 defines Bech32 as a checksummed base32 encoding and standard address format for native SegWit outputs. A Bech32 string has a human-readable part, a separator 1, and a data part whose last six characters are a checksum. The character set intentionally avoids visually confusing symbols, and the checksum is designed to detect any error affecting up to four characters, with a very low probability of missing larger errors for the target lengths.

That means the format itself is part of the wallet safety model. A better checksum reduces the chance that a mistyped address silently becomes another valid destination. The spec even warns implementers not to do automatic error correction beyond possibly indicating where an error may be, because “correcting” an invalid address into the wrong valid one could destroy funds irreversibly.

Bech32 also has casing rules that matter for interoperability: encoders must output lowercase, and decoders must reject mixed case. This is not stylistic fussiness. It prevents ambiguous parsing and supports cleaner QR behavior.

Ethereum’s hex addresses make a different tradeoff. The cited account documentation explains the derivation, but does not itself focus on a checksum-oriented display standard. The important lesson is that “an address string” is not a universal concept. Some systems optimize for compactness, some for script expressiveness, some for human transcription robustness, and some inherit historical constraints.

Why do wallets use address formats and import/export standards instead of raw keys?

From first principles, you could imagine users exchanging raw public keys or script bytecode directly. Address formats exist because that is a terrible human interface. They compress, label, and checksum public destination information so software and humans can handle it with fewer mistakes.

This is also why wallet import and export formats exist beyond bare keys. In Bitcoin, Wallet Import Format (WIF) is a Base58Check encoding of a private key with network/version information and an optional compression marker. Its job is not new cryptography. Its job is safer transport with fewer copy errors.

In Ethereum ecosystems, an analogous human-and-software transport format is the Web3 Secret Storage keystore JSON. Instead of showing the raw private key directly, it stores an encrypted version plus KDF parameters, cipher details, and a MAC. The spec requires support for AES-128-CTR, defines PBKDF2 support, and uses a Keccak-based MAC over derived-key material and ciphertext to verify password correctness before decryption. Again, the structure is not decorative. It exists because “here is a naked hex private key in a text file” is operationally fragile.

Still, these formats do not eliminate the core risk. If someone obtains the plaintext secret, custody is gone. If you forget the password and have no other backup, access may be gone for you as well. The format can reduce error and improve storage hygiene; it cannot change the underlying authority model.

What happens on-chain when you receive cryptocurrency?

Receiving funds feels simple because wallets hide most of the mechanics. Under the hood, the process depends on the chain’s model.

On Bitcoin, your wallet derives or selects an address corresponding to some spend condition, usually tied to a public key or script template. The sender creates a transaction output locked to that condition. Your wallet watches the chain, recognizes that output as one it can later satisfy, and updates your displayed balance. Nothing has entered your phone. The network has recorded an output whose future spending rule matches keys your wallet controls.

On Ethereum, if someone sends ETH to your EOA address, the chain updates the balance field of that account. If someone interacts with a contract address, the effect may involve code execution as well as balance changes. The same-looking act of “sending to an address” can therefore mean either “update a user-controlled account balance” or “invoke contract logic at this location.”

On Solana, transferring value may involve multiple accounts with explicit ownership and program rules. Since accounts are the fundamental state unit and only an account’s owner program can modify its data or debit lamports, what looks like a simple destination often sits inside a richer state model. That is why wallet developers moving across chains need to stop assuming that every address is “just where tokens live.”

How does spending work on different chains (UTXO vs account models)?

Spending is where the wallet’s private authority becomes active. The wallet constructs a transaction, gathers the necessary context, and produces signatures or other authorizations that satisfy the chain’s rules.

In Bitcoin, transaction creation and signing can be split cleanly. A networked program can assemble an unsigned transaction, an offline signer can authorize it, and the signed result can then be broadcast.

The PSBT standard formalizes this workflow by carrying the information a signer needs and allowing multiple roles to cooperate.

• creator
• updater
• signer
• combiner
• finalizer
• extractor

This is a direct consequence of the wallet architecture discussed earlier: distribution, signing, and networking are separable.

In Ethereum, the EOA signs a transaction that includes a nonce. Ethereum’s account model tracks a nonce field precisely so only one transaction with a given nonce can execute per account, preventing replay in the ordinary account flow. Here the address is tied to account state more directly than in Bitcoin’s UTXO model, but the root principle is the same: spending requires proving control of the relevant authority.

What are common address‑handling security mistakes and how can I avoid them?

Because addresses are meant to be shared, users often treat them as harmless text strings. That is mostly true in the sense that sharing an address does not reveal your private key. But address handling is still a major security surface.

The simplest failure mode is sending to the wrong chain or wrong format. If a wallet or exchange expects one network’s address semantics and you provide another’s, funds may be lost or require difficult recovery. Since chains assign different meanings to addresses, “it looks valid” is not enough.

A more subtle failure is address poisoning. Research cited here describes a scam in which attackers generate look-alike addresses and seed a victim’s transaction history with tiny transfers, hoping the victim later copies the attacker’s address by mistake. The attack works because humans often verify only the first and last few characters. The address is public, but the surrounding UX and memory habits are exploitable.

That threat explains why wallets increasingly show ENS-like names where available, warn on suspicious patterns, emphasize full-address verification, and encourage test transfers for large payments. A small test payment is not mathematically required by the protocol. It is a response to the reality that blockchain transfers are often irreversible and human copy-paste habits are unreliable.

Key takeaway: wallet authority vs on‑chain state; what should I remember?

If you remember only one thing, remember this: a wallet is an authorization tool, and an address is a public locator for where authorization will matter later. The blockchain holds the state. The wallet manages the secrets, derivation paths, metadata, and transaction workflows that let you act on that state. The address is the user-facing handle that points others toward the right on-chain destination or rule.

Everything else follows from that. HD wallets exist because managing many keys manually is brittle. Different address formats exist because different chains and script systems need different encodings and error checks. Hardware wallets and threshold signing exist because keeping signing authority isolated is safer than leaving it exposed on a networked device. Cross-chain confusion happens because “address” is a surface label for different underlying state models.

Tomorrow, the short version is this: **your funds are on-chain, your wallet manages control, and your address tells the network which control point you mean. **

How do you secure your crypto setup before trading?

Secure your crypto setup before trading by protecting keys, verifying destination addresses, and testing transfers. On Cube Exchange (a non-custodial platform that uses MPC (threshold signing) for settlement) use this checklist to prepare your wallets and deposits before you trade.

1. Deposit funds into your Cube account via the fiat on-ramp or by sending a supported crypto token to your Cube deposit address.
2. Secure and verify your recovery seed: write your BIP‑39 12/24‑word mnemonic to an offline backup (paper or metal), record the wallet’s derivation path (e.g., m/84'/0'/0'), and restore it to a hardware or offline software wallet to confirm it reproduces the expected addresses.
3. Do a small test transfer on the exact chain and token you plan to use (for example, a tiny ETH or BTC amount). Confirm the test arrives before moving larger amounts.
4. Before any large transfer or withdrawal, copy and verify the full destination string (use checksum-aware formats like Bech32 or EIP‑55, or an ENS/verified name) and confirm the selected network matches the token.
5. For high-value operations, sign with an isolated device or a PSBT/hardware-signing workflow where available to keep private signing authority off your internet-connected machine.