# The Sealed Box: When a Crypto Address Shows Its Public Key

> One transaction can turn a hidden public key into a visible one. Learn how addresses relate to keys, what opens the box, and the seven results Bunker gives.

Canonical: https://nosistech.com/crypto-address-public-key-exposure-explained/
Published: 2026-10-27
Last updated: 2026-10-27
Author: Carlos Paredes, NosisTech LLC

Take two Bitcoin addresses in one hardware wallet. Both start with `bc1q`. Both came from the same seed phrase on the same day.

The first address has received coins for years and has never sent anything. The second address paid for one small purchase last spring. On a block explorer, the two look almost the same.

After you answer one question for each address, Bunker gives them different results. The first one is **Lock hidden**. The second one is **Lock visible**. The only difference is one transaction.

This article explains why one transaction changes the result. You will see how an address relates to its public key and what makes the key public. You will also see why Bunker asks you a question instead of a blockchain. At the end, you will know the seven named results that Bunker gives, and the action that goes with each one.

---

## Five words to know first

Every wallet uses the same five parts. Bunker uses each word with one meaning only:

| Word | Meaning | Who may see it |
| --- | --- | --- |
| Seed phrase | 12 or 24 words that make all your private keys. | Only you. Never share it. |
| Private key | The secret that moves your coins. | Only you. Never share it. |
| Public key | The value that lets anyone check your signature. Bunker calls it the lock. | Anyone, but it is safer when nobody has seen it. |
| Hash | A one-way fingerprint of data. Nobody can rebuild the data from the hash. | Anyone. |
| Address | The text that you give to other people so that they can send you coins. | Anyone. |

Each step goes one way. The seed phrase makes the private key, the private key makes the public key, and the public key makes the address. The step from a public key back to a private key is the step that nobody can do today.

That is why the public key matters. If someone finds a fast way back, every public key on a blockchain becomes a target. A public key that nobody has seen gives that person nothing to start from.

## Three ways an address relates to its key

Networks connect the address and the public key in three different ways. The way decides what a new address can do for you.

### 1. The address is a hash of the key

Bitcoin `bc1q` addresses, Ethereum `0x` addresses and Cosmos addresses work this way. The address is a fingerprint of the key, so the key itself stays out of view. It appears only when the address signs for the first time.

For this group, a new address hides the key again. The plan uses this fact in its step "Move to new addresses".

### 2. The address contains the key

Bitcoin Taproot (`bc1p`), Solana and Polkadot work this way. The address is the key, or it carries the key inside it. Anyone who sees the address sees the key, from the first day.

For this group, a new address of the same type does not help. The fix must come from the network itself.

### 3. The ledger stores the key

Hedera, Flow and NEAR named accounts work this way. The address is an account number or a name, and the ledger keeps the account keys where everyone can read them. These three networks can also change the key behind an account without moving the funds.

I ran examples of each group through the Bunker command-line tool. The last column is the exact explanation that Bunker printed:

| Group | Example | Explanation from Bunker |
| --- | --- | --- |
| Hash of the key | `bc1qw508...v8f3t4` (BIP-173 test vector) | Only a hash of the key is on chain until this address spends. |
| Hash of the key | `cosmos1xsmg...jfhkns` (account page on mintscan.io) | The address is a hash of the key. The network stores the key on chain after the first transaction. |
| Key in the address | `bc1p5cyx...kedrcr` (BIP-86 test vector) | Taproot puts the public key in the address. Ordinals and Runes use this type. |
| Key in the address | `15oF4uVJ...Sp5` (Polkadot development account Alice) | A Substrate address contains the public key. |
| Key on the ledger | `0xc84eefd049dd1b67` (account page on flowscan.io) | Flow stores account keys in public on chain. You can change the keys without moving funds. |

Every address in this article comes from a published standard, a developer account or a public explorer page. None of them belongs to a private person.

## What opens the box

For the first group, the key stays hidden until the address uses it. Many actions count as a use. Any action that needs your signature shows the public key, because a signature is checked with that key.

- **A transaction.** You send coins or tokens from the address.
- **A token approval.** You let an app spend a token for you. A permit is an approval that is only a signed message.
- **An NFT listing.** Marketplaces ask you to sign the listing.
- **"Sign in with wallet".** The website asks you to sign a message to prove that you own the address.

The last three often happen off chain. They leave no transaction on the blockchain, but they still show the key.

Some networks also have their own first step. Bunker names it in the explanation:

| Network | Explanation from Bunker |
| --- | --- |
| Tezos (`tz1`) | The address is a hash of the key. Tezos publishes the key with a "reveal" operation on the first send. |
| Starknet | The address comes from a hash. The key stays hidden until the first transaction deploys the account. Starknet accounts can change their key. |
| Internet Computer | An account identifier is a hash. The key behind it appears when its owner signs. |

## Why Bunker asks you, not the blockchain

For a hash-type address, the result depends on one fact: has the address ever signed? A blockchain lookup can find transactions. So why does Bunker ask a question instead?

There are two reasons. First, a lookup sends your addresses to an API provider, together with your IP address. A list of addresses linked to one person shows who owns what. Second, a lookup cannot see off-chain signatures. The decision record says it directly:

> **From ADR-008, "Ask the user instead of a blockchain lookup":**
>
> Privacy comes first.
>
> Off-chain signatures (permits, "sign in with wallet", NFT listings) also show the key. No blockchain lookup can find them. Only the user knows.

So the card asks one question: "Has it ever sent a transaction or signed a message?" You can answer Not sure, No or Yes. If you are not sure, the card gives a link to a block explorer, where you can look for outgoing transactions. Opening the link sends that one address to the explorer, so you decide when it happens.

## How your answer becomes a result

I scanned the BIP-173 test address three times, with a different answer each time. The command-line tool takes the answer with the `--sent` option:

```
node cli/bunker.js --text --sent bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4=no addresses.txt
```

| Answer | Result | Plan step | Advice from Bunker |
| --- | --- | --- | --- |
| Yes | Lock visible | Move to new addresses | Send to a new bc1q receive address from a Native SegWit account on your hardware wallet. Send a small test amount first. |
| No | Lock hidden | Keep these locks hidden | Use it only to receive. When you spend, your wallet sends the change to a new address, and the rest stays hidden. |
| Not sure | Check needed | Check or ask | Look for an outgoing transaction or a signed message on a block explorer. If you find one, select "Yes". |

The rule behind this table is 14 lines long. It is the function `statusOf()` in [src/model.js](https://github.com/nosistech/nosis-bunker/blob/main/src/model.js). It takes one address with its model and your answer, and it returns the status that the card shows:

```
export function statusOf(entry) {
  switch (entry.model) {
    case MODEL.VISIBLE: return STATUS.EXPOSED;
    case MODEL.MOVE_POOL: return STATUS.EXPOSED;
    case MODEL.HASH_SAFE: return STATUS.PROTECTED;
    case MODEL.XPUB: return STATUS.WARNING;
    case MODEL.ASK_PROVIDER: return STATUS.CHECK;
    case MODEL.HIDDEN_UNTIL_USED:
      if (entry.sent === 'yes') return STATUS.EXPOSED;
      if (entry.sent === 'no') return STATUS.HIDDEN;
      return STATUS.CHECK;
    default: return STATUS.UNKNOWN;
  }
}
```

Read it from top to bottom:

1. The model describes the network. It comes from the address alone, for example `visible` for Taproot.
2. Five models give a status at once. Your history cannot change them.
3. Only `hidden-until-used` reads your answer. "Yes" gives `EXPOSED`, "No" gives `HIDDEN`, and anything else gives `CHECK`.
4. Any model that the function does not know gives `UNKNOWN`. An unknown case never gets a confident result.

The design keeps two things apart: the network and the person. The decision record ADR-007 states it in one line: "A model describes the network, not the person."

## After you send: change addresses and vaults

Look again at the advice for the "No" answer. It mentions change. The word explains why Bitcoin users can spend and still keep most keys hidden.

Bitcoin is a UTXO network. UTXO means unspent transaction output: coins sit in separate pieces, not in one balance. When you spend, your wallet sends the change to a new address. The key of the address that spent becomes public. The change sits behind a new key that nobody has seen.

Account networks such as Ethereum work differently. One address holds the whole balance, and every payment comes from that same address. Bunker knows the difference and gives different advice. Here is the advice for the EVM test address with the answer "No":

```
2. Keep these locks hidden
   - 0x5aAeb6...1BeAed (EVM networks | Vault): Use it as a vault that only receives. When you need the funds, move all of them to a new vault in one step.
```

The rule is simple. On an account network, a vault address never sends small payments. When you need the money, you move everything at once to a new vault.

## The extended public key: one value, every key

An extended public key, or xpub, is one value that makes every address of a wallet. Some portfolio trackers and apps use it to follow a whole wallet at once.

The same property makes it sensitive. Anyone with the xpub can compute the public key of every address, including the addresses that have never sent. I scanned the public xpub from the first test vector of BIP-32:

```
"type": "Extended public key",
"model": "xpub",
"status": "warning",
"explanation": "An xpub shows the public key of every address in that wallet. Do not share it with trackers or websites.",
```

The card shows **Shows every key**. The plan adds a step for it:

```
2. Stop sharing extended public keys
   - xpub661M...GMcet8 (Bitcoin): Remove this xpub from portfolio trackers and apps. Anyone with it can see the public key of every address it makes.
```

The scan shows the risk and nothing more. Bunker does not compute the addresses behind the xpub, and it sends the xpub nowhere.

## The seven named results

Bunker sorts every input into one of seven models. Each model leads to one card label and one place in the plan. The examples are real scans. Some formats have no public example yet. For those, I built sample addresses with the project's own encoders, the same way its tests do:

| Model | Example | Card label | Place in the plan |
| --- | --- | --- | --- |
| `visible` | Taproot `bc1p`, Solana, Monero | Lock visible | Visible with no hidden option yet |
| `hidden-until-used` | `bc1q`, `0x`, Cosmos | Check needed, then your answer decides | Move, Keep hidden, or Check or ask |
| `hash-safe` | BIP-360 sample (`bc1z`) | Hash-protected | No step needed |
| `move-pool` | Zcash Sapling sample (`zs1`) | Lock visible | Move to new addresses or a safer pool |
| `ask-provider` | Canton sample, Zcash unified sample | Ask your provider, or Check your pool | Check or ask |
| `xpub` | BIP-32 test xpub | Shows every key | Stop sharing extended public keys |
| `unknown` | QNT token contract, typos, test networks | Not rated | No step; the card explains why |

Three of these models cover special cases. A BIP-360 address shows no curve key at all, so there is nothing to protect. A Zcash Sapling address sits in a pool that has a safer successor. A Canton party belongs to a permissioned network, so the operator decides who sees the keys. Article 9 of this series explains these hard cases in detail.

## Why names and not a score

A score from 0 to 100 would be shorter. I considered it and rejected it. ADR-007 records the options:

| Option | For | Against |
| --- | --- | --- |
| Yes or no ("safe" or "not safe") | Very simple | Wrong: "hidden until used" is neither; it depends on the user's history |
| A score from 0 to 100 | One number | Looks exact when it is not; hides the reason; users argue about the number |
| A small set of named models, plus the user's answer | Each model has a clear rule and a clear action | More categories to explain |

A score of 62 tells you nothing to do. "Lock visible, move to a new address" tells you the next step.

## Who would be a target first

A visible key is not an empty wallet. As of October 25, 2026, nobody has shown a break of ECDSA or of the Solana signature system. The background document of the project describes what an early break would look like:

> **From docs/01-background.md:**
>
> An early break would be slow and expensive for each key. An attacker would start with the largest open boxes. Thousands of early Bitcoin addresses hold 50 BTC each, and their locks are public. They give smaller holders time. They do not give protection forever.

Time is the reason to act calmly. A rushed migration can lose more money than the risk that it avoids. Wrong addresses, fake tools and lost keys are real dangers today.

## Check your own addresses

1. Write down the public addresses that you use, one on each line.
2. Open [bunker.nosistech.com](https://bunker.nosistech.com) and paste the list.
3. Select **Scan addresses**.
4. For each card with a question, answer it.
5. If you are not sure, open the explorer link and look for an outgoing transaction.
6. Before each large move, send a small test amount.

## Read the sources

- The tool: [bunker.nosistech.com](https://bunker.nosistech.com)
- The background: [docs/01-background.md](https://github.com/nosistech/nosis-bunker/blob/main/docs/01-background.md)
- The models and the question: [docs/02-how-it-works.md](https://github.com/nosistech/nosis-bunker/blob/main/docs/02-how-it-works.md)
- The decisions: [ADR-007](https://github.com/nosistech/nosis-bunker/blob/main/docs/decisions/ADR-007-exposure-model.md) and [ADR-008](https://github.com/nosistech/nosis-bunker/blob/main/docs/decisions/ADR-008-ask-instead-of-lookup.md)
- Every word in the project: [docs/09-glossary.md](https://github.com/nosistech/nosis-bunker/blob/main/docs/09-glossary.md)

In the next article, I take a tour of the networks. You will see how Bitcoin, Ethereum, Solana, Monero and more than 100 other networks handle the public key, with a real scan for each family.

Have a question or feedback about Bunker? [Contact NosisTech](https://nosistech.com/connect/).

### Keep reading: Bunker by NosisTech

Previous article: [Which of Your Crypto Addresses Show Their Public Key? Bunker Answers in 30 Seconds](https://nosistech.com/bunker-crypto-address-public-key-scanner/)

Next article: [Bitcoin, Ethereum, Solana and 100 More: How Each Network Shows the Public Key](https://nosistech.com/crypto-networks-public-key-exposure-rules/)

All articles: [NosisTech Writing](https://nosistech.com/blog/)

*This post is general information, not financial, legal or security advice. Bunker is an educational tool with no warranty. Examine each address on a block explorer, and send a small test amount before you move funds.*