Open Bitcoin Receive twice and you may see the same address. Receive a payment, let the wallet discover it, and the next address changes. Nothing was moved. No second wallet was created. Your recovery phrase did not change. Aperture simply advanced to the next public destination in a deterministic address chain.
That distinction is the key to understanding modern Bitcoin wallets: a wallet is not an address. It is a system that can control many transaction outputs, often through many public addresses, from one protected recovery credential. Fresh addresses reduce the easiest form of on-chain correlation while the wallet keeps the result looking like one balance.
Fresh address, same wallet, same recovery credential, separate on-chain destination.
A fresh capture from Aperture 2.40.12 in the iOS Simulator. This public BIP84 address belongs to an empty article-only wallet. No recovery phrase, private key, or real funds appear in any image in this article.
A Bitcoin balance is really a set of spendable outputs
Bitcoin does not keep an account balance beside your name. Transactions create discrete unspent transaction outputs, usually called UTXOs. Each output locks a precise amount of bitcoin to spending conditions encoded in a script. Your wallet watches for outputs it can unlock, adds their values for display, and selects some of them as inputs when you send.
Suppose three customers each pay a different receiving address generated by the same wallet. The blockchain records three separate outputs to three separate scripts. Aperture recognizes all three as members of one deterministic wallet, so the portfolio can display one combined balance. An outside observer sees public transactions and scripts; they do not automatically receive the private map that says every destination belongs to the same person.
This is why “my Bitcoin address” is often misleading. You may have a currently published address, many older receiving addresses, a reserve of unused receiving addresses, a separate chain for change, and optionally a reusable Silent Payment address. The wallet—not any single string—is the durable object.
Why address reuse reveals more than it needs to
If one public address is printed on every invoice, profile, and donation page, anyone can search that address and see every output sent directly to it. They can total those payments, watch their timing, and know with certainty that those particular outputs shared the exact same destination script. Reuse creates a simple public join key.
Giving each payment a fresh destination removes that easiest join. A customer who sees one invoice address cannot immediately search it and find all other payments made to the same published address. The improvement is practical privacy hygiene, not invisibility.
Fresh does not mean anonymous. Combining several UTXOs in a later transaction can create a strong common-input clue. Amounts, timing, change-output patterns, exchange records, and information shared off-chain can also reconnect activity.
Fresh does not mean disposable. An older address remains a valid destination. Aperture continues monitoring generated addresses because delayed or repeated payments can still arrive.
Fresh does not divide ownership. All discovered outputs remain spendable by the same wallet under the same recovery scope.
One seed can deterministically produce a tree of keys
Hierarchical deterministic wallets, standardized by BIP32, derive a tree of child keys from one root. A recovery phrase is converted into protected seed material; account branches then produce an ordered sequence of child public keys and Bitcoin addresses. Because the process is deterministic, restoring the same recovery credential can reconstruct the same tree.
Aperture persists public account descriptors and public child metadata so it can prepare and monitor addresses without copying recovery phrases or private keys into the portfolio database. Protected wallet secrets stay in the app’s Keychain vault. The public descriptor is useful, but it is privacy-sensitive: someone with an account-level extended public key can often observe a large part of that account’s address history even though they cannot spend it. Treat an xpub, ypub, or zpub as private account metadata.
Real Simulator output from the article-only wallet. The BIP84 account path is m/84'/0'/0'. Aperture shows one public descriptor and independent Receive and Change chains; the screenshot contains public wallet data only.
External for receiving, internal for change
The common account structure defined around BIP44 separates two non-hardened child branches beneath an account: branch 0 for external receiving addresses and branch 1 for internal change addresses. An address index advances within each branch. In shorthand, the shape is: purpose, coin type, account, branch, then address index.
External branch 0. Destinations you can show to another person or service so they can pay you.
Internal branch 1. Destinations the wallet reserves for change created by your own outgoing transaction.
Address index. The ordered child number inside that branch: 0, 1, 2, and so on.
The two rails never need to reuse the same destination. Their keys still descend from the same account, and their outputs still contribute to the same spendable wallet.
What Aperture prepares before the first payment
For a recovery-phrase Bitcoin wallet, Aperture creates account-zero public descriptors for four interoperable address families. It derives 20 external and 20 change children for each family before any address has been used. That is 4 types × 2 branches × 20 children = 160 generated public addresses.
Real Simulator output before the first payment. The empty wallet has 160 generated addresses: 40 per BIP44, BIP49, BIP84, and BIP86 account, with BIP84 selected for Receive.
These are not 160 recovery phrases or 160 backups. They are deterministic public destinations inside one wallet. Pre-generating the discovery window lets the Receive screen show a locally prepared address immediately and lets synchronization scan a bounded public range without exposing secret material to a server.
“Fresh” means unused after discovery—not changed for decoration
Aperture does not rotate the receive address merely because you reopen the screen, refresh the app, or tap Receive again. It publishes the next unused external child after discovery proves an earlier child has transaction history or balance. That keeps the address stable long enough to complete a payment while avoiding reuse after on-chain activity.
You can also inspect the generated external chain and select an unused address as the current Receive destination. It remains a known member of the wallet and stays selected until use advances the chain or you choose another unused child.
Real Simulator output. Address 0 is current and the following children are unused. The article-only wallet begins with 20 external addresses in its active discovery window.
When an address becomes used or reserved, Aperture replenishes the public pool so 20 consecutive unused children remain beyond the highest relevant index. Discovery likewise continues until it encounters a full 20-address unused window. This mirrors the gap-limit model described by BIP44, where history—not merely a current zero balance—determines whether an address has been used.
Four standard address families, one Bitcoin account
Bitcoin address formats evolved as script capabilities and efficiency improved. Aperture supports four deterministic account-zero families for recovery-phrase wallets:
BIP44 Legacy. P2PKH addresses commonly beginning with 1. This is the broadest legacy-compatibility option.
BIP49 Nested SegWit. P2SH-wrapped SegWit addresses commonly beginning with 3, useful for older senders that support P2SH but not native SegWit presentation.
BIP84 Native SegWit. P2WPKH addresses beginning with bc1q. Aperture uses BIP84 as the default Receive family.
BIP86 Taproot. Single-key P2TR addresses beginning with bc1p for compatible senders.
Real Simulator output. The Types menu exposes Silent Payments plus BIP86 Taproot, BIP84 Native SegWit, BIP49 Nested SegWit, and BIP44 Legacy. Choose a format the sender supports; changing type changes the published destination, not the wallet owner.
Selecting another family atomically publishes that family’s current fresh external address and saves the preference. Funds discovered across BIP44, BIP49, BIP84, and BIP86 remain part of one spendable Bitcoin account. The formats describe locking scripts and derivation branches; they are not separate portfolios.
Change belongs on its own fresh chain
Bitcoin inputs are normally spent in full. If a wallet spends a 0.010 BTC UTXO to pay 0.003 BTC, the transaction can create the payment output and return the remainder—minus the network fee—to a new output controlled by the sender. That returned output is change.
Reusing the public receiving address for change would make the relationship easier to infer and blur the distinction between an incoming request and an internal return. Aperture instead reserves a fresh address from the change branch when building a Bitcoin send. The reservation is atomic so concurrent preparation cannot accidentally assign the same intended change child twice.
Real Simulator output. These 20 change children are distinct from the 20 Receive children. No transaction was created, signed, or broadcast to make this article.
A change address may look unfamiliar in a block explorer because you never copied it from the Receive screen. That is expected. The wallet derived it, reserved it, and knows how to spend its output. For a complete walkthrough of transaction review, read Send Crypto Without Guesswork: From Recipient to Finality; for miner fees and fee-rate selection, read Where Crypto Network Fees Actually Go.
Old receiving addresses do not expire
Publishing address 8 does not disable addresses 0 through 7. Bitcoin has no “make this address stale” command. If someone sends to an older valid address, the blockchain can still create an output there, and Aperture continues discovering and tracking it.
That property protects delayed payments and saved invoices, but it is not a reason to deliberately reuse an address. When possible, request a fresh destination for each payment. If a merchant, exchange, or contact has saved an older address, verify that the wallet controlling it is still the intended recipient before sending again.
The 20-address window makes recovery discoverable
A restored wallet has no private list saying which child indices were used. It derives public children in order and queries their history. A gap limit gives the scan a stopping rule: after enough consecutive unused addresses, the wallet can reasonably conclude the active range has ended.
Used means history, not current balance. An address that received and later spent funds is still used and must advance discovery.
Aperture maintains 20 unused children ahead. Use or reservation extends the corresponding branch through the highest relevant index plus 20.
Avoid creating large unused gaps casually. If addresses far beyond a standard discovery window are handed out without the earlier range ever being used, another recovery tool may stop scanning too soon.
The recovery phrase remains the essential backup for a full wallet. The generated public addresses can be reconstructed; they do not each need their own backup. See Lose Your Phone, Not Your Wallet: Backup and Restore in Aperture and Recovery Phrase, Private Key, iCloud, or iPhone Transfer? for the difference between recovery scopes.
A standalone private key cannot create the same HD tree
Fresh child-address rotation is a property of an HD recovery-phrase wallet, not every possible Bitcoin import. A standalone WIF contains one private key. Aperture can derive the standard spendable script encodings supported by that key—a compressed WIF can expose legacy, nested SegWit, native SegWit, and Taproot forms, while an uncompressed WIF is restricted to legacy—but all are fixed encodings of one key at index 0.
There is no account-level seed behind that import from which Aperture can derive child 1, child 2, and onward. Switching the visible address type therefore does not create a fresh HD destination. To restore a complete rotating address tree, import the recovery phrase or another supported full-wallet backup that actually contains that scope—not one exported child private key.
Silent Payments: one reusable instruction, unique on-chain outputs
A fresh conventional address works well when the receiver can provide a new invoice each time. A public profile or static donation page needs something reusable. BIP352 Silent Payments approaches that problem differently: the receiver shares one reusable sp1 address, while a compatible sender uses that instruction and transaction data to derive a unique Taproot output for the payment.
Real Simulator output from the same empty article-only wallet. The visible sp1 string is a reusable payment instruction, while compatible payments produce unique on-chain destinations. Sender support is required.
The reusable instruction is not itself the ordinary output address that repeats on-chain. Aperture scans compatible transactions locally to recognize outputs it can spend. This reduces the need to publish a new conventional address for each asynchronous payment, but it does not make every transaction private or erase correlations elsewhere in the transaction graph. When the sender does not support Silent Payments, use one of the conventional BIP44, BIP49, BIP84, or BIP86 destinations instead.
What a fresh address does—and does not—protect
It does reduce direct address reuse. Separate payers no longer receive the same obvious public identifier.
It does preserve one wallet experience. Aperture discovers every generated branch and aggregates the controlled UTXOs.
It does not hide the blockchain. Amounts, times, transaction inputs, outputs, and scripts remain public.
It does not prevent later clustering. Spending several received outputs together may reveal a relationship that separate receive addresses initially obscured.
It does not change the recovery credential. The same deterministic root reconstructs the supported account branches.
It does not revoke older destinations. Old addresses can still receive funds and must remain monitored.
A practical receive checklist
Choose Bitcoin in Aperture and confirm the screen says Bitcoin Network.
Use BIP84 Native SegWit by default unless the sender requires another supported format.
Copy or scan the full address; compare the beginning and ending characters through a separate channel for meaningful value.
Create a new payment request for a new payer when practical instead of recycling an old address.
Do not worry when Aperture advances after discovering payment activity. Earlier addresses and their funds remain in the wallet.
Never share the recovery phrase, private key, or account extended public key merely to receive bitcoin. A public receiving address is sufficient.
Use a small supported test payment when the route, sender, or address-format compatibility is uncertain.
The address changes so the wallet can stay yours
Fresh receiving addresses are not a cosmetic trick and not evidence that funds disappeared. They are the public leaves of a deterministic key tree: separate enough to avoid the simplest reuse pattern, organized enough to recover, and controlled by one protected wallet. Aperture makes that structure visible with independent receive and change chains, four standard address families, a maintained 20-address discovery window, and a reusable Silent Payments option for compatible senders.
The rule worth remembering is simple: save the wallet’s recovery credential, verify the network and address you share, and let the wallet manage the address sequence. Your current address can change. Your ownership does not.
One recovery credential can control many public destinations. Privacy improves when those destinations are not unnecessarily reused.
