Most developers walk into web3 assuming the blockchain "encrypts" their data. It doesn't. Almost nothing on a public chain is encrypted at the protocol level, and understanding why that's true is the difference between a working mental model and a confused one. This lesson starts with what encryption actually is, then explains where it lives in your stack and where it doesn't.

Ask a backend engineer what protects their data on a blockchain and most will answer "encryption." It sounds right. The space is full of cryptographic jargon, transactions are signed, addresses look like cryptographic gibberish, the chain is described as "secure," so encryption must be doing the work somewhere.

It isn't. Public blockchains do not encrypt transactions, balances, contract storage, or anything else at the protocol level. Every byte of state on a public chain is readable by anyone with a node. Your balance, every transaction you've ever sent, every piece of data you've stored on-chain: all public, all permanently visible.

What protects you on a blockchain is authentication (proving you authorized an action) and integrity (proving data wasn't tampered with). These properties come from hashing and from another cryptographic primitive covered later in this module. They don't come from encryption.

That said, encryption is real infrastructure on the internet, and it does show up around the edges of blockchain systems at specific places. Knowing where is the goal of this lesson.

Encryption transforms data using a key so that only someone with the right key can transform it back. The transformed data is called ciphertext and looks like random noise. The original data is plaintext. Without the key, ciphertext is meant to be useless, with the key, it returns to the exact original byte for byte. The strength of an encryption scheme is the gap between those two outcomes: how expensive it is to recover the plaintext without the key.

This is what makes encryption different from encoding. Encoding has no key and anyone can reverse it. Encryption has a key and nobody without it can reverse it in any practical amount of time.

There are two families of encryption schemes that differ in how the key works.

The simplest model. There is one key. Whoever has the key can encrypt new data and decrypt existing data. Both directions use the same key.

The standard algorithm here is AES (Advanced Encryption Standard), specifically AES-256, which uses a 256-bit key. AES-256 is what your operating system uses to encrypt your disk, what password managers use to encrypt their vaults, and what almost every "encrypted at rest" system you've ever heard of relies on under the hood.

Symmetric encryption is fast. AES-256 can encrypt gigabytes per second on modern hardware. It's the right tool for bulk data.

The catch is key distribution. Symmetric encryption only works if both ends already share the key. If Alice and Bob want to communicate securely and they've never met, how does Alice send Bob the key without an attacker intercepting it? You can't encrypt the key with symmetric encryption because they don't have a shared key yet. This is the classic chicken-and-egg problem of secure communication, and it's exactly the problem the other family of encryption was invented to solve.

Also called public-key encryption. Each participant has a key pair: two mathematically linked keys that work in opposite directions. One key encrypts, the other decrypts. The two keys are different.

The participant keeps one key secret (the private key) and publishes the other (the public key) freely. Anyone in the world can take your public key and use it to encrypt a message that only your private key can decrypt. The public key cannot be used to decrypt, only to encrypt.

The asymmetry solves the key-distribution problem. Bob publishes his public key on his website. Anyone can encrypt a message to him without ever meeting him. Only Bob, holding the private key, can decrypt.

The price is speed. Asymmetric encryption is dramatically slower than symmetric, typically 100 to 1000 times slower depending on the algorithm and the data size. You wouldn't use it to encrypt a large file. The standard algorithms here are RSA (older, key sizes 2048 to 4096 bits), and elliptic curve schemes like ECDH (newer, smaller keys with equivalent security).

In practice, almost every "encrypted" connection on the modern internet uses both schemes together in a pattern called hybrid encryption.

Asymmetric encryption is used briefly at the start to exchange a fresh symmetric key. Then the symmetric key encrypts everything else.

This is how TLS works (the protocol behind HTTPS). When your browser connects to a website, it uses the site's public key from its certificate to negotiate a short-lived symmetric key, then encrypts the rest of the session symmetrically. The asymmetric work happens once per session, the symmetric work handles the bulk traffic. Best of both: no pre-shared secret needed, and fast enough for real volume.

Back to the opening misconception. Encryption is critical infrastructure for the internet but plays a small and specific role in public blockchains. Three places it shows up in practice:

At rest, in your wallet file. When you install a wallet, the application encrypts your private key on disk using a password you choose. That encryption is symmetric (AES under the hood, with the password run through a key-derivation function first). This is why "remember your password" matters. If you forget it, the wallet file is encrypted and unreadable. The blockchain itself doesn't know or care about this, it's a local security measure done by the wallet software.

In transit, when you talk to a node. When your wallet sends commands to a remote node over the internet, the connection is usually wrapped in TLS, which uses the hybrid encryption you just saw. Again, this is standard internet infrastructure, the blockchain protocol doesn't specify it.

In specialised chains that opt into it. A few chains are designed around encrypted transactions where the amounts and recipients are hidden from public view. These are the exception, not the rule, and they involve genuine cryptographic engineering beyond what plain AES or RSA provide.

If you've been told "everything on the blockchain is encrypted," the more accurate phrasing is "everything on the blockchain is authenticated and tamper-evident." Those are different security properties, and conflating them is the misconception that opened this lesson.