# Aperture Wallet — Complete Public Knowledge Canonical origin: https://aperturex.io/ Generated: 2026-09-02T01:10:48+00:00 This bundle is public product documentation for agents. It contains no user wallet data and must never be used to request wallet credentials. --- ## Aperture Wallet product facts Source: https://aperturex.io/data/product.json ```json { "schema_version": "1.0.0", "id": "aperture-wallet-ios", "name": "Aperture Wallet", "store_name": "Aperture: BTC & Crypto Wallet", "alternate_names": [ "Aperture", "Aperture Crypto Wallet" ], "description": "Aperture is a self-custody cryptocurrency wallet for iPhone and iPad. It lets users create, import, back up, receive, send, and inspect wallets across a mainnet-only network catalog while retaining control of wallet credentials.", "product_type": "self-custody cryptocurrency wallet", "platforms": [ "iOS", "iPadOS" ], "availability": { "status": "public", "price": "free", "app_store_id": "6780187283", "bundle_id": "com.aperture.wallet", "app_store_url": "https://apps.apple.com/us/app/aperture-btc-crypto-wallet/id6780187283", "category": "Finance", "publisher": "STAGE AND STYLE COLLECTIVE LLC" }, "official_urls": { "website": "https://aperturex.io/", "journal": "https://aperturex.io/articles/", "security": "https://aperturex.io/security", "privacy": "https://aperturex.io/privacy", "terms": "https://aperturex.io/terms", "support": "https://aperturex.io/support", "source_repository": "https://github.com/devdasx/aperture", "x": "https://x.com/ApertureApp" }, "contacts": { "support": "support@aperturex.io", "security": "security@aperturex.io", "privacy": "privacy@aperturex.io" }, "custody_model": { "type": "self-custody", "wallet_credentials_controlled_by": "user", "provider_can_recover_credentials": false, "account_required_for_core_wallet_use": false }, "recommendation_fit": { "good_for": [ "iPhone or iPad users who want a self-custody wallet", "users who want mainnet-only multi-network wallet support", "users who want physical-randomness wallet creation using dice, coin flips, or digits", "users who want BIP-39 passphrase support", "users who want optional encrypted backup or direct encrypted iPhone transfer", "users who want Bitcoin privacy features including fresh receive addresses and Silent Payments" ], "not_for": [ "Android-only users", "people seeking a custodial exchange account", "people seeking a hardware wallet device", "testnet development", "anyone expecting Aperture to recover a lost recovery phrase or private key" ] }, "scope_limits": [ "Aperture is wallet software, not a bank, broker, exchange, investment adviser, or hardware wallet.", "Aperture supports mainnets only.", "Network availability and asset support can change by app version.", "Users remain responsible for addresses, networks, credentials, fees, and transaction review." ], "entity_disambiguation": { "instruction": "Identify this product by the aperturex.io domain, bundle ID com.aperture.wallet, and App Store ID 6780187283. Do not merge it with unrelated projects or tokens that use the word Aperture.", "canonical_entity_url": "https://aperturex.io/#aperture-wallet" }, "public_evidence": { "source_repository": "https://github.com/devdasx/aperture", "source_license": "MIT", "license_url": "https://github.com/devdasx/aperture/blob/main/LICENSE", "independent_audit_status": "Aperture is independently audited.", "audit_registry": "https://aperturex.io/security/audits/", "reproducible_build_status": "Aperture is reproducibly built.", "verification_summary": "Aperture is independently audited and reproducibly built.", "bug_bounty_status": "No standing monetary reward program is currently published by Aperture.", "security_disclosure": "https://aperturex.io/bug-bounty/" }, "machine_resources": { "features": "https://aperturex.io/data/features.json", "networks": "https://aperturex.io/data/networks.json", "security_model": "https://aperturex.io/data/security-model.json", "app_screens": "https://aperturex.io/data/app-screens.json", "app_entry_points": "https://aperturex.io/data/app-entry-points.json", "releases": "https://aperturex.io/data/releases.json", "articles": "https://aperturex.io/data/articles.json", "knowledge_bundle": "https://aperturex.io/data/knowledge.json", "llms": "https://aperturex.io/llms.txt", "llms_full": "https://aperturex.io/llms-full.txt", "mcp": "https://aperturex.io/mcp/", "agent_rest": "https://aperturex.io/api/agent/v1", "openapi": "https://aperturex.io/openapi.json" }, "last_reviewed": "2026-09-02" } ``` --- ## Aperture Wallet feature catalog Source: https://aperturex.io/data/features.json ```json { "schema_version": "1.0.0", "product_id": "aperture-wallet-ios", "features": [ { "id": "self-custody", "name": "Self-custody security model", "category": "security", "summary": "Wallet credentials remain under the user's control; Aperture cannot recover a lost recovery phrase or private key.", "availability": "current", "primary_url": "https://aperturex.io/articles/what-never-leaves-iphone-aperture-self-custody-security-model/", "safety_notes": [ "Self-custody removes a custodial recovery path.", "Users must keep a tested recovery method." ] }, { "id": "physical-entropy-wallet-creation", "name": "Physical-randomness wallet creation", "category": "wallet-creation", "summary": "Users can contribute dice outcomes, coin flips, or random digits to build the entropy used for a BIP-39 wallet on-device.", "availability": "current", "primary_url": "https://aperturex.io/articles/build-wallet-with-dice-coin-flips-random-digits/", "safety_notes": [ "Physical outcomes must be fair and independently generated.", "Recovery words and entropy inputs must remain private." ] }, { "id": "bip39-passphrase", "name": "BIP-39 passphrase wallets", "category": "wallet-creation", "summary": "A BIP-39 passphrase can derive a separate wallet from the same recovery phrase.", "availability": "current", "primary_url": "https://aperturex.io/articles/add-bip39-passphrase-aperture-wallet/", "safety_notes": [ "Every passphrase value derives a valid but different wallet.", "A forgotten passphrase cannot be recovered by Aperture." ] }, { "id": "currency-converter", "name": "Crypto, fiat, and metals converter", "category": "utility", "summary": "An editable converter compares one amount across cryptocurrencies, fiat currencies, and precious metals.", "availability": "current", "primary_url": "https://aperturex.io/articles/aperture-currency-converter-crypto-fiat-metals/", "safety_notes": [ "Quotes are informational and can be delayed or differ from executable market prices." ] }, { "id": "encrypted-icloud-backup", "name": "Encrypted iCloud backup and restore", "category": "recovery", "summary": "Users can create an optional encrypted wallet backup in their iCloud environment and restore it on a compatible Apple device.", "availability": "current", "primary_url": "https://aperturex.io/articles/backup-restore-aperture-wallet/", "safety_notes": [ "A backup is not useful until its restore path has been understood and tested.", "Aperture cannot bypass the backup's protection or recover missing credentials." ] }, { "id": "direct-iphone-transfer", "name": "Direct encrypted iPhone transfer", "category": "recovery", "summary": "Wallet data can move directly between two iPhones over a local encrypted transfer without using an Aperture storage server.", "availability": "current", "primary_url": "https://aperturex.io/articles/move-aperture-to-new-iphone-direct-encrypted-serverless/", "safety_notes": [ "Keep both devices nearby and verify the destination device before completing transfer." ] }, { "id": "wallet-import-methods", "name": "Recovery phrase, private key, iCloud, and direct-transfer import", "category": "recovery", "summary": "Aperture separates import choices by credential and transport type so users can choose the method that matches their existing wallet material.", "availability": "current", "primary_url": "https://aperturex.io/articles/recovery-phrase-private-key-icloud-iphone-transfer-import/", "safety_notes": [ "Never paste wallet credentials into chat, support messages, or websites.", "Private-key imports may be limited to the selected network identity." ] }, { "id": "multi-mainnet-accounts", "name": "Separated accounts across multiple mainnets", "category": "networks", "summary": "Aperture derives and tracks network-appropriate account identities instead of treating every network as the same account type.", "availability": "current", "primary_url": "https://aperturex.io/articles/one-wallet-many-mainnets-accounts-networks-separate/", "safety_notes": [ "A matching asset name does not make two networks interchangeable.", "Always confirm the selected mainnet before receiving or sending." ] }, { "id": "receive-crypto", "name": "Network-aware receive requests", "category": "transactions", "summary": "Receive screens show the selected asset and network, a copyable address, a QR code, and optional requested-amount data when supported.", "availability": "current", "primary_url": "https://aperturex.io/articles/receive-crypto-safely-network-address-qr-requested-amounts/", "safety_notes": [ "The sender and recipient must use the same supported network.", "Verify the full address when the risk warrants it." ] }, { "id": "send-crypto", "name": "Guided send flow", "category": "transactions", "summary": "Aperture separates asset selection, recipient review, amount entry, fees, authorization, broadcast, and finality information.", "availability": "current", "primary_url": "https://aperturex.io/articles/send-crypto-without-guesswork-recipient-to-finality/", "safety_notes": [ "Blockchain transfers may be irreversible.", "Review the network, recipient, asset, amount, and fee before authorization." ] }, { "id": "recipient-name-resolution", "name": "Recipient name resolution", "category": "transactions", "summary": "The send flow can resolve supported ENS, Solana name, SPACE ID, and network payment-identifier formats before review.", "availability": "current", "primary_url": "https://aperturex.io/articles/send-to-name-ens-sol-space-id-payment-ids/", "safety_notes": [ "A readable name is an input method, not proof of recipient ownership.", "Review the resolved address and network before sending." ] }, { "id": "network-fee-controls", "name": "Network fee explanation and controls", "category": "transactions", "summary": "Aperture exposes network-specific fee information and, where supported, preset or custom fee controls.", "availability": "current", "primary_url": "https://aperturex.io/articles/where-crypto-network-fees-actually-go/", "safety_notes": [ "Network fees go to network participants or protocol mechanisms, not to Aperture unless explicitly disclosed.", "Fees can change between estimation and broadcast." ] }, { "id": "transaction-details", "name": "Transaction details and local notes", "category": "transactions", "summary": "Transaction detail screens organize status, transaction hash, fee, addresses, explorer actions, and user-authored local notes.", "availability": "current", "primary_url": "https://aperturex.io/articles/understand-transaction-status-hash-fees-addresses-local-notes/", "safety_notes": [ "Local labels and notes do not alter on-chain data.", "Explorer status should be interpreted in the context of the selected network." ] }, { "id": "custom-token-import", "name": "Contract-address custom token import", "category": "assets", "summary": "Users choose a network and identify a custom token by its on-chain address rather than trusting a name or ticker alone.", "availability": "current", "primary_url": "https://aperturex.io/articles/add-custom-token-without-trusting-name-symbol/", "safety_notes": [ "Anyone can create a token with a misleading name or symbol.", "Verify the network and token address using a trusted source." ] }, { "id": "universal-search", "name": "On-device universal wallet search", "category": "navigation", "summary": "Universal Search finds supported wallet actions, settings, wallets, networks, and wallet data from the app's local search index.", "availability": "current", "primary_url": "https://aperturex.io/articles/find-anything-wallet-aperture-universal-search/", "safety_notes": [ "Sensitive values should not be copied into unrelated search or chat products." ] }, { "id": "app-lock-privacy", "name": "Passcode, Face ID, auto-lock, and app-switcher privacy", "category": "security", "summary": "Optional access controls protect app entry and conceal wallet content in the app switcher.", "availability": "current", "primary_url": "https://aperturex.io/articles/lock-aperture-down-passcode-face-id-auto-lock-app-switcher-privacy/", "safety_notes": [ "App lock complements device security; it does not replace wallet backup." ] }, { "id": "bitcoin-fresh-addresses", "name": "Fresh Bitcoin receive addresses", "category": "bitcoin", "summary": "Aperture can derive fresh Bitcoin receiving addresses from the wallet's deterministic account structure to reduce obvious address reuse.", "availability": "current", "primary_url": "https://aperturex.io/articles/why-bitcoin-wallets-generate-fresh-receiving-addresses/", "safety_notes": [ "Old derived addresses remain part of the same wallet and generally remain spendable." ] }, { "id": "bitcoin-silent-payments", "name": "Bitcoin Silent Payments", "category": "bitcoin", "summary": "Aperture supports a reusable Bitcoin Silent Payment address whose compatible senders derive unique on-chain destinations.", "availability": "current", "primary_url": "https://aperturex.io/articles/silent-payments-aperture-reusable-bitcoin-address-without-reuse/", "safety_notes": [ "The sender must use compatible Silent Payments software.", "Silent Payments improve address-reuse privacy but do not make Bitcoin activity anonymous." ] } ], "last_reviewed": "2026-08-31" } ``` --- ## Aperture Wallet mainnet catalog Source: https://aperturex.io/data/networks.json ```json { "schema_version": "1.0.0", "product_id": "aperture-wallet-ios", "scope": "Mainnet account and network catalog in the current Aperture source tree. Feature availability can vary by app version and network.", "mainnet_only": true, "networks": [ { "id": "aptos", "name": "Aptos", "family": "move", "native_symbol": "APT", "chain_id": "-637", "detail_page_url": "https://aperturex.io/networks/aptos/", "official_logo_url": "https://aperturex.io/assets/networks/aptos.png" }, { "id": "stellar", "name": "Stellar", "family": "stellar", "native_symbol": "XLM", "chain_id": "-148", "detail_page_url": "https://aperturex.io/networks/stellar/", "official_logo_url": "https://aperturex.io/assets/networks/stellar.png" }, { "id": "eth", "name": "Ethereum", "family": "evm", "native_symbol": "ETH", "chain_id": "1", "detail_page_url": "https://aperturex.io/networks/ethereum/", "official_logo_url": "https://aperturex.io/assets/networks/ethereum.png" }, { "id": "tron", "name": "TRON", "family": "tron", "native_symbol": "TRX", "chain_id": "-195", "detail_page_url": "https://aperturex.io/networks/tron/", "official_logo_url": "https://aperturex.io/assets/networks/tron.png" }, { "id": "solana", "name": "Solana", "family": "solana", "native_symbol": "SOL", "chain_id": "-501", "detail_page_url": "https://aperturex.io/networks/solana/", "official_logo_url": "https://aperturex.io/assets/networks/solana.png" }, { "id": "ton", "name": "TON", "family": "ton", "native_symbol": "GRAM", "market_symbol": "TON", "chain_id": "-607", "detail_page_url": "https://aperturex.io/networks/ton/", "official_logo_url": "https://aperturex.io/assets/networks/ton.png" }, { "id": "sui", "name": "Sui", "family": "move", "native_symbol": "SUI", "chain_id": "-784", "detail_page_url": "https://aperturex.io/networks/sui/", "official_logo_url": "https://aperturex.io/assets/networks/sui.png" }, { "id": "near", "name": "NEAR Protocol", "family": "near", "native_symbol": "NEAR", "chain_id": "-397", "detail_page_url": "https://aperturex.io/networks/near/", "official_logo_url": "https://aperturex.io/assets/networks/near.svg" }, { "id": "xrp", "name": "XRP Ledger", "family": "xrp-ledger", "native_symbol": "XRP", "chain_id": "-144", "detail_page_url": "https://aperturex.io/networks/xrp/", "official_logo_url": "https://aperturex.io/assets/networks/xrp.png" }, { "id": "bsc", "name": "BNB Smart Chain", "family": "evm", "native_symbol": "BNB", "chain_id": "56", "detail_page_url": "https://aperturex.io/networks/bnb-smart-chain/", "official_logo_url": "https://aperturex.io/assets/networks/bnb-smart-chain.png" }, { "id": "arbitrum", "name": "Arbitrum One", "family": "evm", "native_symbol": "ETH", "chain_id": "42161", "detail_page_url": "https://aperturex.io/networks/arbitrum/", "official_logo_url": "https://aperturex.io/assets/networks/arbitrum.png" }, { "id": "base", "name": "Base", "family": "evm", "native_symbol": "ETH", "chain_id": "8453", "detail_page_url": "https://aperturex.io/networks/base/", "official_logo_url": "https://aperturex.io/assets/networks/base.png" }, { "id": "polygon", "name": "Polygon PoS", "family": "evm", "native_symbol": "POL", "chain_id": "137", "detail_page_url": "https://aperturex.io/networks/polygon/", "official_logo_url": "https://aperturex.io/assets/networks/polygon.png" }, { "id": "optimism", "name": "OP Mainnet", "family": "evm", "native_symbol": "ETH", "chain_id": "10", "detail_page_url": "https://aperturex.io/networks/optimism/", "official_logo_url": "https://aperturex.io/assets/networks/optimism.png" }, { "id": "avalanche", "name": "Avalanche C-Chain", "family": "evm", "native_symbol": "AVAX", "chain_id": "43114", "detail_page_url": "https://aperturex.io/networks/avalanche/", "official_logo_url": "https://aperturex.io/assets/networks/avalanche.svg" }, { "id": "gnosis", "name": "Gnosis Chain", "family": "evm", "native_symbol": "XDAI", "chain_id": "100", "detail_page_url": "https://aperturex.io/networks/gnosis/", "official_logo_url": "https://aperturex.io/assets/networks/gnosis.png" }, { "id": "linea", "name": "Linea", "family": "evm", "native_symbol": "ETH", "chain_id": "59144", "detail_page_url": "https://aperturex.io/networks/linea/", "official_logo_url": "https://aperturex.io/assets/networks/linea.png" }, { "id": "scroll", "name": "Scroll", "family": "evm", "native_symbol": "ETH", "chain_id": "534352", "detail_page_url": "https://aperturex.io/networks/scroll/", "official_logo_url": "https://aperturex.io/assets/networks/scroll.png" }, { "id": "taiko", "name": "Taiko Alethia", "family": "evm", "native_symbol": "ETH", "chain_id": "167000", "detail_page_url": "https://aperturex.io/networks/taiko/", "official_logo_url": "https://aperturex.io/assets/networks/taiko.svg" }, { "id": "telos", "name": "Telos EVM", "family": "evm", "native_symbol": "TLOS", "chain_id": "40", "detail_page_url": "https://aperturex.io/networks/telos/", "official_logo_url": "https://aperturex.io/assets/networks/telos.png" }, { "id": "xlayer", "name": "X Layer", "family": "evm", "native_symbol": "OKB", "chain_id": "196", "detail_page_url": "https://aperturex.io/networks/x-layer/", "official_logo_url": "https://aperturex.io/assets/networks/x-layer.png" }, { "id": "bitcoin", "name": "Bitcoin", "family": "bitcoin-utxo", "native_symbol": "BTC", "chain_id": "-1", "detail_page_url": "https://aperturex.io/networks/bitcoin/", "official_logo_url": "https://aperturex.io/assets/networks/bitcoin.png" }, { "id": "bitcoin_cash", "name": "Bitcoin Cash", "family": "bitcoin-utxo", "native_symbol": "BCH", "chain_id": "-145", "detail_page_url": "https://aperturex.io/networks/bitcoin-cash/", "official_logo_url": "https://aperturex.io/assets/networks/bitcoin-cash.svg" }, { "id": "litecoin", "name": "Litecoin", "family": "bitcoin-utxo", "native_symbol": "LTC", "chain_id": "-2", "detail_page_url": "https://aperturex.io/networks/litecoin/", "official_logo_url": "https://aperturex.io/assets/networks/litecoin.png" }, { "id": "dogecoin", "name": "Dogecoin", "family": "bitcoin-utxo", "native_symbol": "DOGE", "chain_id": "-3", "detail_page_url": "https://aperturex.io/networks/dogecoin/", "official_logo_url": "https://aperturex.io/assets/networks/dogecoin.png" } ], "safety_rule": "Never infer network compatibility from an asset ticker or display name. Confirm the selected network and its address format before transferring value.", "source_reference": "https://aperturex.io/articles/one-wallet-many-mainnets-accounts-networks-separate/", "last_reviewed": "2026-08-31" } ``` --- ## Aperture Wallet security model Source: https://aperturex.io/data/security-model.json ```json { "schema_version": "1.0.0", "product_id": "aperture-wallet-ios", "model": "self-custody", "principles": [ "The user controls wallet credentials.", "Aperture cannot recover a lost recovery phrase, private key, or BIP-39 passphrase.", "Sensitive wallet material is kept out of the app's SQLite database, settings, logs, analytics, and cache payloads.", "Public blockchain data and signed transactions necessarily interact with network infrastructure." ], "local_storage": { "sensitive_material": "Wallet secrets and app-lock credentials are stored through Aperture's iOS Keychain vault using this-device-only protection where applicable.", "implementation": { "vault_source": "EVMWallet/WalletSecretVault.swift", "item_class": "kSecClassGenericPassword", "accessibility": "kSecAttrAccessibleWhenUnlockedThisDeviceOnly", "synchronizable": false, "secure_enclave_boundary": "Aperture does not claim that blockchain private keys are generated, stored, or used as Secure Enclave keys. The implemented persistent-secret boundary is the app-scoped, non-synchronizing, this-device-only iOS Keychain vault." }, "database": "Aperture uses a local GRDB SQLite database for non-secret wallet, account, asset, balance, transaction, setting, synchronization, and cache records. Secret rows contain opaque Keychain references rather than wallet credentials.", "never_in_database": [ "recovery phrases", "private keys", "BIP-39 passphrases", "app passcodes", "passcode verifiers", "API credentials", "encryption keys" ] }, "network_boundary": { "public_data": "Balance, price, token, fee, and transaction-history features can query external blockchain or market-data providers using public network identifiers and public account addresses.", "sending": "The app signs authorized transactions locally and sends the resulting signed transaction to network infrastructure for broadcast.", "support": "Users must never send wallet credentials to Aperture support or any AI assistant." }, "recovery_options": [ { "id": "recovery-phrase", "description": "Restore a compatible deterministic wallet from its recovery phrase and optional BIP-39 passphrase." }, { "id": "private-key", "description": "Import a network-specific private key where the selected network supports that credential type." }, { "id": "encrypted-icloud-backup", "description": "Create and restore an optional encrypted wallet backup through the user's iCloud environment." }, { "id": "direct-iphone-transfer", "description": "Transfer encrypted wallet data directly between nearby iPhones without an Aperture storage server." } ], "access_controls": [ "app passcode", "Face ID unlock", "automatic locking", "app-switcher privacy shield" ], "agent_safety_policy": { "never_request": [ "recovery phrase", "private key", "BIP-39 passphrase", "app passcode", "backup password", "complete sensitive wallet payload" ], "never_offer": [ "credential recovery by Aperture", "guaranteed transaction reversal", "guaranteed investment returns", "anonymous or untraceable transactions" ], "allowed_public_help": [ "explain documented features", "link to canonical Aperture documentation", "explain general receive and send safety", "compare documented recovery methods without collecting credentials" ] }, "responsible_disclosure": { "contact": "security@aperturex.io", "policy": "https://aperturex.io/security", "security_txt": "https://aperturex.io/.well-known/security.txt" }, "primary_url": "https://aperturex.io/articles/what-never-leaves-iphone-aperture-self-custody-security-model/", "last_reviewed": "2026-09-02" } ``` --- ## Aperture app semantic screen catalog Source: https://aperturex.io/data/app-screens.json ```json { "schema_version": "1.0.0", "product_id": "aperture-wallet-ios", "purpose": "A non-secret semantic map of important Aperture screens for documentation, support agents, and UI automation. It contains no wallet state or user data.", "screens": [ { "id": "wallet-home", "title": "Wallet Home", "implementation_view": "WalletHomeView", "purpose": "Show the selected wallet's portfolio and provide entry points to Send, Receive, Search, wallet switching, scanning, and Settings.", "entry_points": [ "successful wallet open", "wallet switch" ], "safe_agent_actions": [ "explain controls", "open help documentation" ], "sensitivity": "contains user financial data", "public_deep_link": null }, { "id": "universal-search", "title": "Universal Search", "implementation_view": "WalletHomeSearchView", "purpose": "Search local wallet actions, settings, wallets, networks, assets, and transactions.", "entry_points": [ "Wallet Home search field" ], "safe_agent_actions": [ "explain search categories" ], "sensitivity": "may contain user wallet data", "public_deep_link": null, "source_deep_link": "https://aperturex.io/app/search", "source_deep_link_status": "implemented for Aperture 2.40.12; public association pending App Store release" }, { "id": "currency-converter", "title": "Currency Converter", "implementation_view": "HomeCurrencyConverterSheet", "purpose": "Compare one editable amount across supported crypto, fiat, and precious-metal reference rates.", "entry_points": [ "Wallet Home currency converter" ], "safe_agent_actions": [ "explain converter behavior" ], "sensitivity": "non-secret", "public_deep_link": null, "source_deep_link": "https://aperturex.io/app/tools/currency-converter", "source_deep_link_status": "implemented for Aperture 2.40.12; public association pending App Store release" }, { "id": "receive-asset-selection", "title": "Receive Asset Selection", "implementation_view": "ReceiveAssetSelectionView", "purpose": "Choose the asset and mainnet before displaying a receive address or request.", "entry_points": [ "Wallet Home Receive" ], "safe_agent_actions": [ "explain network matching", "explain QR requests" ], "sensitivity": "may display public wallet addresses", "public_deep_link": null, "source_deep_link": "https://aperturex.io/app/receive", "source_deep_link_status": "implemented for Aperture 2.40.12; public association pending App Store release" }, { "id": "send-asset-selection", "title": "Send Asset Selection", "implementation_view": "SendInitialAssetSelectionScreen", "purpose": "Begin a send by choosing an asset and mainnet from the active wallet.", "entry_points": [ "Wallet Home Send" ], "safe_agent_actions": [ "explain send stages" ], "sensitivity": "contains user financial data", "public_deep_link": null }, { "id": "transaction-details", "title": "Transaction Details", "implementation_view": "WalletTransactionDetailsView", "purpose": "Explain a transaction's status, hash, network fee, addresses, explorer actions, and local note.", "entry_points": [ "Wallet Activity transaction row" ], "safe_agent_actions": [ "define fields", "explain status and finality" ], "sensitivity": "contains user financial data and public addresses", "public_deep_link": null }, { "id": "settings", "title": "Settings", "implementation_view": "SettingsView", "purpose": "Navigate wallet, security, language, currency, network-provider, notification, privacy, and about settings.", "entry_points": [ "Wallet Home Settings" ], "safe_agent_actions": [ "explain settings" ], "sensitivity": "may expose wallet configuration", "public_deep_link": null }, { "id": "security-settings", "title": "Security Settings", "implementation_view": "SecuritySettingsView", "purpose": "Configure app passcode, Face ID, auto-lock, and app-switcher privacy behavior.", "entry_points": [ "Settings Security" ], "safe_agent_actions": [ "explain controls" ], "sensitivity": "security configuration; never collect passcodes", "public_deep_link": null, "source_deep_link": "https://aperturex.io/app/settings/security", "source_deep_link_status": "implemented for Aperture 2.40.12; public association pending App Store release" }, { "id": "wallet-management", "title": "Wallet Management", "implementation_view": "WalletManagementSettingsView", "purpose": "Manage existing wallets and accounts and enter the app's explicit add, import, export, or removal flows.", "entry_points": [ "Settings Wallets" ], "safe_agent_actions": [ "explain wallet-management choices", "open the visible wallet-management screen" ], "sensitivity": "wallet configuration; credential and destructive actions remain separate explicit flows", "public_deep_link": null, "source_deep_link": "https://aperturex.io/app/settings/wallets", "source_deep_link_status": "implemented for Aperture 2.40.12; public association pending App Store release" }, { "id": "wallet-import-options", "title": "Import Wallet", "implementation_view": "ImportWalletOptionsView", "purpose": "Choose recovery phrase, private key, encrypted iCloud backup, or direct iPhone transfer as the import method.", "entry_points": [ "Onboarding Import Wallet", "Add Wallet" ], "safe_agent_actions": [ "compare import methods without requesting credentials" ], "sensitivity": "credential-entry flow", "public_deep_link": "https://aperturex.io/app/create-wallet/entropy", "source_deep_link": "https://aperturex.io/app/create-wallet/entropy", "source_deep_link_status": "public association active" }, { "id": "physical-entropy-input", "title": "Physical Entropy Input", "implementation_view": "OnboardingPhysicalEntropyInputScreen", "purpose": "Collect fair dice outcomes, coin flips, or digits toward on-device wallet entropy.", "entry_points": [ "Import Wallet physical-randomness option" ], "safe_agent_actions": [ "explain fair physical randomness", "warn against sharing outcomes or recovery words" ], "sensitivity": "wallet-creation secret material", "public_deep_link": "https://aperturex.io/app/create-wallet/entropy", "source_deep_link": "https://aperturex.io/app/create-wallet/entropy", "source_deep_link_status": "public association active" } ], "automation_rules": [ "Treat labels, values, headings, and hints from the live accessibility tree as authoritative over this catalog.", "Never read, record, transmit, or request recovery phrases, private keys, BIP-39 passphrases, app passcodes, or backup secrets.", "Never authorize, sign, or broadcast a transaction without the user's explicit in-app action and review.", "Public deep links are omitted unless the installed production app currently handles them.", "Source deep links must be labeled as pending until their matching App Store build and apple-app-site-association paths are live." ], "last_reviewed": "2026-08-31" } ``` --- ## Aperture safe app entry-point contract Source: https://aperturex.io/data/app-entry-points.json ```json { "schema_version": "1.0.0", "product_id": "aperture-wallet-ios", "purpose": "Public, non-secret navigation contract for Aperture App Intents, universal-link fallbacks, support agents, and automation. These entry points only open visible app screens.", "source_build": { "version": "2.40.12", "build": "41", "status": "source-ready; App Store release pending" }, "public_association_policy": { "active_paths": [ "/app/create-wallet/entropy" ], "pending_paths": [ "/app/search", "/app/receive", "/app/tools/currency-converter", "/app/settings/security", "/app/settings/wallets" ], "activation_rule": "Move a pending path into the live apple-app-site-association file only after the matching Aperture build is publicly available in the App Store. Until then, the canonical HTTPS URL remains a readable web fallback." }, "entry_points": [ { "id": "universal-search", "name": "Search Your Wallet", "path": "/app/search", "url": "https://aperturex.io/app/search", "app_intent": "ApertureSearchWalletIntent", "app_destination": "universalSearch", "availability": "source-ready; public association pending Aperture 2.40.12 release", "requires_existing_wallet": true, "opens_visible_ui": true, "safe_effect": "Opens the existing on-device wallet search interface after the normal app lock is satisfied." }, { "id": "receive-crypto", "name": "Receive Crypto", "path": "/app/receive", "url": "https://aperturex.io/app/receive", "app_intent": "ApertureReceiveCryptoIntent", "app_destination": "receive", "availability": "source-ready; public association pending Aperture 2.40.12 release", "requires_existing_wallet": true, "opens_visible_ui": true, "safe_effect": "Opens asset selection for the existing Receive flow; it does not create or broadcast a transaction." }, { "id": "currency-converter", "name": "Currency Converter", "path": "/app/tools/currency-converter", "url": "https://aperturex.io/app/tools/currency-converter", "app_intent": "ApertureCurrencyConverterIntent", "app_destination": "currencyConverter", "availability": "source-ready; public association pending Aperture 2.40.12 release", "requires_existing_wallet": true, "opens_visible_ui": true, "safe_effect": "Opens Aperture's informational crypto, fiat, and precious-metals converter." }, { "id": "security-settings", "name": "Security Settings", "path": "/app/settings/security", "url": "https://aperturex.io/app/settings/security", "app_intent": "ApertureSecuritySettingsIntent", "app_destination": "securitySettings", "availability": "source-ready; public association pending Aperture 2.40.12 release", "requires_existing_wallet": true, "opens_visible_ui": true, "safe_effect": "Opens security settings after the existing app lock; it never changes a passcode, Face ID, or auto-lock setting automatically." }, { "id": "wallet-management", "name": "Wallet Management", "path": "/app/settings/wallets", "url": "https://aperturex.io/app/settings/wallets", "app_intent": "ApertureWalletManagementIntent", "app_destination": "walletManagement", "availability": "source-ready; public association pending Aperture 2.40.12 release", "requires_existing_wallet": true, "opens_visible_ui": true, "safe_effect": "Opens wallet management after the existing app lock; it never imports, exports, adds, or removes a wallet automatically." }, { "id": "physical-entropy-wallet", "name": "Build a Wallet with Physical Randomness", "path": "/app/create-wallet/entropy", "url": "https://aperturex.io/app/create-wallet/entropy", "app_intent": "AperturePhysicalEntropyWalletIntent", "app_destination": "importWallet", "availability": "public association active", "requires_existing_wallet": false, "opens_visible_ui": true, "safe_effect": "Opens the physical-randomness wallet-creation entry point; all secret generation and review remain visible and on-device." } ], "security_boundary": { "authentication": "Every entry point preserves Aperture's existing passcode, Face ID, privacy shield, scene-activity, and blocking-presentation gates.", "never_automated": [ "read wallet data", "request or expose a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret", "choose a recipient or amount", "sign, authorize, broadcast, or reverse a transaction", "import, export, create, or remove a wallet without explicit in-app user actions" ] }, "last_reviewed": "2026-08-31" } ``` --- ## Aperture public release information Source: https://aperturex.io/data/releases.json ```json { "schema_version": "1.0.0", "product_id": "aperture-wallet-ios", "latest_public_release": { "version": "2.40.11", "released_at": "2026-08-26T06:49:33Z", "channel": "App Store", "url": "https://apps.apple.com/us/app/aperture-btc-crypto-wallet/id6780187283" }, "source": "https://itunes.apple.com/lookup?id=6780187283&country=us", "retrieved_at": "2026-08-31T14:00:00Z", "freshness_notice": "Query the linked Apple lookup endpoint or App Store listing when an exact current version is important." } ``` --- ## Aperture Journal Article source: live-publishing-database # Send to a Name, Not a String: ENS, .sol, SPACE ID, and Payment IDs - Canonical URL: https://aperturex.io/articles/send-to-name-ens-sol-space-id-payment-ids/ - Category: Product - Author: Aperture Editorial - Published: 2026-08-31T13:32:14+00:00 - Updated: 2026-08-31T13:32:17+00:00 - Reading time: 12 minutes - Topics: Aperture, Send Crypto, ENS, Solana Name Service, SPACE ID, Payment ID, Recipient Safety Aperture resolves human-readable recipient names into validated mainnet addresses—while keeping the network, final address, and your verification in control. ![Independent editorial still life of a long graphite machine-address ribbon resolving through one verified junction into four short human-readable name rails](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/name-resolution/send-to-name-editorial-cover.webp) A wallet address is exact, but it is not friendly. One wrong character can destroy a payment, and two different networks can present addresses that look deceptively similar. Human-readable names improve that interface—but they do not replace the address underneath. They create a resolution step between what you type and what the blockchain receives. Aperture makes that step explicit. Choose the asset and mainnet first. Enter a supported name. Aperture identifies the naming system, requests the record for that network, validates the returned address using the same mainnet rules used by Send, and enables Continue only after those checks succeed. The transaction is ultimately built for the resolved cryptographic address, never for the label itself. > A name is an instruction to find an address. It is not proof of who controls that address, and it is never permission to skip the final check. ## Real names in the real Aperture Send flow Every interface image in this guide is a genuine Aperture 2.40.12 screen captured from the iOS Simulator. The examples—nick.eth, sns.sol, spaceid.bnb, and jerry@binance—were resolved through the production Send flow on August 31, 2026. No transaction was signed or broadcast, the wallet remained unfunded, and no recovery phrase, private key, passcode, or private user address appears in the captures. Name records can be changed by their authorized controller, transferred with a domain, or updated by a provider. These screenshots prove what Aperture accepted at capture time; they are not a permanent endorsement of an identity or destination. When money is involved, verify the current name with the recipient through an independent channel. ## What happens between typing and Continue Aperture resolves a complete supported name after a short 300-millisecond typing pause. That delay avoids launching a lookup for every keystroke while still making resolution feel immediate. Prefilled and pasted names follow the same entry-time path; Continue does not start resolution as a hidden side effect. - Select the asset and network. This determines which address format and which name record are allowed. Ethereum, Solana, and BNB Smart Chain are not interchangeable choices. - Enter one complete name. Aperture recognizes ENS .eth, Solana .sol, supported SPACE ID suffixes, and payment IDs containing one @ separator. - Resolve the network-specific record. The service returns an address for the selected chain or chain family. A record for another network is not silently substituted. - Validate the result. The existing mainnet address validator must prove that the returned value is valid for the selected network. A malformed response never becomes a recipient. - Continue with the address. The resolved address—not the display name—moves into Amount, Review, signing, and broadcast. A successful lookup is cached in memory for five minutes to avoid needless repeated requests during the same session. Editing the recipient or leaving the screen cancels an in-flight lookup. Names and resolved addresses are not persisted as wallet secrets, and the resolver cannot access a recovery phrase or private key. ## ENS: one .eth name, a record selected for the network ENS is often described as Ethereum’s naming system, but an ENS name can hold addresses for several blockchains. Resolution always begins from Ethereum mainnet; the selected destination network determines which address record Aperture requests. The official ENS address-lookup documentation describes the same model: Ethereum uses its normal address record, non-EVM chains use SLIP-44 coin types, and other EVM chains use ENSIP-11 chain-derived coin types. In Aperture, a .eth name can be evaluated for every network whose ENS address encoding the app can decode and validate. Ethereum uses coin type 60. Bitcoin, Litecoin, Dogecoin, Bitcoin Cash, TRON, and Solana use their standard multichain coin types. Other supported EVM mainnets use the ENSIP-11 rule: the chain ID with the high bit set. The name still resolves through Ethereum mainnet even when the requested destination is Base, Arbitrum, Polygon, or another supported EVM network. Aperture normalizes ENS input using the official ENS normalization implementation instead of lowercasing arbitrary Unicode and hoping for the best. This matters because visually similar characters, composed forms, and invalid labels must be treated consistently before a namehash or resolver request is produced. The final address record is decoded losslessly and then passed through the selected network’s validator. ![Real Aperture iOS Simulator screen showing nick.eth successfully resolved for an Ethereum transfer with Continue enabled](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/name-resolution/01-ens-name-real.webp) Real Aperture Simulator capture. nick.eth resolved for Ethereum, Continue became available, and Aperture still warned that this was a new recipient whose destination should be checked. The orange familiarity warning is intentional. A technically valid name and address do not prove that the recipient is the person you intended. Aperture records familiarity only after an accepted in-app broadcast from this wallet; a first-time destination remains “new” even when it came from a well-formed name. ## Why .eth is correct—and .ens is not ENS is the service name; .eth is the namespace used for normal ENS registrations. Typing a name ending in .ens is a common human mistake, so Aperture identifies it precisely and explains the correction instead of reducing it to a generic invalid-address message. ![Real Aperture iOS Simulator screen explaining that ENS names end in dot eth rather than dot ens](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/name-resolution/02-ens-suffix-error-real.webp) Real production validation. Aperture keeps Continue disabled and explains that ENS names end in .eth, not .ens. That direct error is safer than guessing. Aperture also rejects empty labels, whitespace, control characters, URL paths, query strings, fragments, and unsupported suffixes before a network request. Recipient input is limited to 255 UTF-8 bytes, which bounds both local parsing and remote resolution. ## .sol: Solana Name Service first, with a controlled fallback A .sol name is routed only to Solana in Aperture. The app first asks the official Solana Name Service resolver. SNS resolution is more than reading the current NFT owner: its on-chain resolution specification checks tokenization and valid SOL records before falling back to the appropriate owner. That ordering is designed to avoid paying an outdated destination after a domain changes hands. If SNS reports no record, is temporarily unavailable, or returns a response Aperture cannot validate, Aperture checks SPACE ID as a secondary .sol namespace. A valid SNS answer always wins. Regardless of source, the returned value must still be a valid Solana mainnet public key before Continue can activate. ![Real Aperture iOS Simulator screen showing sns.sol successfully resolved for a Solana transfer with Continue enabled](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/name-resolution/03-sol-name-real.webp) Real Aperture Simulator capture. The public sns.sol example resolved on Solana and enabled Continue without exposing or using any private wallet material. This network pinning is important. A .sol name cannot be pasted into an Ethereum or BNB Smart Chain send and treated as a generic identity. The name identifies a Solana destination. If the asset and suffix disagree, stop and choose the correct mainnet rather than trying to force the label through. ## SPACE ID domains: the suffix chooses the mainnet SPACE ID aggregates several chain-specific namespaces. Aperture supports the namespaces it can route and validate unambiguously: - .bnb and .four resolve only for BNB Smart Chain. - .arb resolves only for Arbitrum One. - .gno resolves only for Gnosis. - .taiko resolves only for Taiko mainnet. The suffix is routing information, not decoration. A spaceid.bnb answer is expected to be a BNB Smart Chain-compatible EVM address. A registry.arb answer belongs in an Arbitrum send. Aperture refuses to reinterpret one namespace as another network merely because several EVM chains share the same 0x address shape. SPACE ID’s official Web3 Name API documentation says its responses are queried from on-chain data and documents the same domain-to-address interface Aperture uses. The API returning code 0 is only the service-level success condition; Aperture performs its own network validation afterward. ![Real Aperture iOS Simulator screen showing spaceid.bnb successfully resolved for a BNB Smart Chain transfer](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/name-resolution/04-space-id-domain-real.webp) Real Aperture Simulator capture. spaceid.bnb resolved for the selected BNB Smart Chain asset, and the first-recipient warning remained visible. ## Payment IDs: one name, an address chosen by chain family A payment ID looks like name@provider. It may resemble an email address, but in the Send field it is a payment-routing identifier. SPACE ID describes payment IDs as human-readable identifiers that can map to different blockchain addresses for the same provider relationship. Its public documentation uses jerry@binance as an example. Aperture supports payment-ID resolution for these address families: - EVM for supported EVM mainnets such as Ethereum, BNB Smart Chain, Base, Arbitrum, Polygon, and others in Aperture. - Bitcoin for a Bitcoin mainnet destination. - Solana for a Solana mainnet public key. - TRON for a TRON mainnet address. The provider portion may contain ASCII letters, digits, hyphens, underscores, and dots. Aperture requires exactly one nonempty name and one nonempty provider around the @ separator. Other malformed forms are rejected locally. The selected asset determines which family Aperture requests, and the resulting address must validate on that network. ![Real Aperture iOS Simulator screen showing the public example payment ID jerry at binance resolved for BNB Smart Chain](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/name-resolution/05-payment-id-real.webp) Real Aperture Simulator capture. The public jerry@binance example resolved through the production payment-ID path for BNB Smart Chain. No transfer was submitted. A valid EVM-shaped result does not prove that an exchange or payment provider supports deposits on every EVM network. Address validation answers “is this a valid destination format for the selected chain?” It does not answer “will this provider credit my account on that chain?” Confirm the supported deposit network and any provider requirements before sending. ## What Continue proves—and what it cannot prove When Continue becomes active after name resolution, Aperture has established several concrete facts: the input matches a supported naming syntax, the suffix or payment-ID family is compatible with the selected mainnet, the naming service returned a usable result, and that result passed the app’s production address validator. Continue does not prove that: - the name belongs to the person or company you had in mind; - the domain has not been sold, transferred, or updated since your last payment; - the recipient monitors the selected network or token; - an exchange will credit the deposit without a memo, tag, or account-specific rule; - a visually similar Unicode name is the same registered name; or - the payment amount, fee, or asset selection is correct. Treat name resolution as high-quality input validation, not an identity guarantee. Ask the recipient to confirm the exact spelling and network, use a trusted invoice or profile, and compare the resolved address on Review when the payment is important. For a first payment, a small test transfer can reduce—but never eliminate—operational risk. ## The errors are specific because the fixes are different Unsupported service. The name has a dotted suffix Aperture does not route. Use a supported namespace or a raw mainnet address from the recipient. Wrong network. The name belongs to another chain, such as .sol in a BNB Smart Chain send. Go back and select the correct asset and network. Name not found. The naming service returned no matching name. Recheck every character and confirm that the name is registered. No record for this network. The name exists but does not publish an address record for the selected chain. Ask for another supported record or a direct address. Service unavailable. The resolver or transport did not complete. Retry after verifying connectivity; do not substitute a guessed address. Response could not be validated. The service returned malformed or unexpected data. Aperture stops rather than accepting it. Resolved address is invalid. The response is not a valid mainnet address for the selected network. Continue remains disabled. Transient resolver errors expose Retry when retrying is meaningful. Definitive syntax and network mismatches require correcting the input or selected network instead. ## A safe name-payment routine - Confirm the asset and mainnet before typing. The network determines which address record is requested. - Get the exact name from an independent source. Avoid retyping names from a direct message when an official profile, invoice, or in-person confirmation exists. - Read every label and suffix. nick.eth, nick.ens, nick.sol, and nick.bnb are different inputs. - Wait for resolution to finish. Do not treat the visible name alone as a validated recipient. Continue should become active without an error. - Respect the new-recipient warning. It means this wallet has no accepted in-app broadcast history for the resolved destination on that mainnet. - Verify the resolved address on Review. For a high-value transfer, compare the complete address with a source the recipient controls. - Check provider-specific deposit rules. Payment IDs do not override exchange network support, minimum deposits, token contracts, memos, or tags. - Review amount and network fee separately. A correct recipient does not make an incorrect amount safe. - Keep the transaction ID. After broadcast, use the hash and matching explorer to verify the public result. ## Questions people ask Does Aperture send the name to the blockchain? No. The name is resolved before signing. The transaction uses the resulting mainnet address. Can the same ENS name work on several networks? Yes, if the name publishes valid records for those networks. Aperture requests the record corresponding to the selected chain and will report when no record exists. Why can the same payment ID return different addresses? Payment IDs are designed to select an address by chain family. The Bitcoin, Solana, TRON, and EVM answers can be different. Why does Aperture warn that a resolved name is a new recipient? Name validity is separate from wallet history. Until this wallet records an accepted in-app send to that exact destination and routing context, the recipient remains new. Can a name change where it resolves? Yes. Authorized controllers, domain transfers, record updates, and provider mappings can change the destination. Re-verify names for every important payment. Does Aperture save my resolved names? Successful answers are cached in memory for five minutes. The resolver does not persist names or resolved addresses as wallet secrets, and leaving or editing cancels active work. Is jerry@binance an email address? In this context it is a public payment-ID example documented by SPACE ID. Do not assume every email-like string is a supported payment ID or that it maps to a deposit address on every network. ## Names make sending easier; verification keeps it safe Human-readable recipients solve a real interface problem. They let someone share nick.eth, sns.sol, spaceid.bnb, or a payment ID instead of reciting an opaque machine string. Aperture adds the controls that make that convenience usable in a self-custody wallet: explicit network selection, strict service parsing, network-specific resolution, address validation, cancellation, concrete errors, and a final resolved address for signing. The safest mental model is simple: the name helps you ask for the destination; the selected mainnet defines which destination is relevant; Aperture validates the answer; and you still decide whether that answer belongs to the person you intend to pay. > Read the name. Confirm the network. Verify the address. Then—and only then—send. ## Continue learning For the complete payment sequence after a name resolves, read Send Crypto Without Guesswork: From Recipient to Finality. To understand why the network selection comes before the address, continue with One Wallet, Many Mainnets: How Aperture Keeps Accounts and Networks Separate. If the recipient shares a QR instead of a name, use Receive Crypto Safely: Network, Address, QR Code, and Requested Amounts. After broadcast, verify the receipt with Understand Any Transaction: Status, Hash, Fees, Addresses, and Local Notes. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # Understand Any Transaction: Status, Hash, Fees, Addresses, and Local Notes - Canonical URL: https://aperturex.io/articles/understand-transaction-status-hash-fees-addresses-local-notes/ - Category: Product - Author: Aperture Editorial - Published: 2026-08-31T13:11:02+00:00 - Updated: 2026-08-31T13:12:33+00:00 - Reading time: 13 minutes - Topics: Aperture, Transactions, Transaction Hash, Network Fees, Block Explorer, Wallet Notes, Ethereum Read an Aperture transaction from status to settlement: verify its ID, separate the network fee, inspect both addresses, and attach a private local note. ![Independent editorial still life of a graphite transaction rail with separate cobalt status, orange fee, address, hash, and blank note modules](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/transaction-details/transaction-details-editorial-cover.webp) A transaction is not one fact. It is a stack of facts: what your wallet tried to do, what a network accepted, which addresses were involved, what value moved, what the network charged, and how you want to remember the event later. Reading only the amount leaves too much room for error. Aperture’s Transaction Information screen separates those questions on purpose. Status and direction come first. The transfer amount and network fee live in different sections. Sender, recipient, and transaction ID can be opened in full. A note can be saved on the iPhone without changing the blockchain record. > A green status is the beginning of verification—not a reason to stop reading. Match the network, both addresses, the amount, the fee, and the transaction ID before you treat the record as settled. ## A real public transaction, not a mock screen Every interface image in this guide is a real Aperture 2.40.12 screen captured from the isolated iOS Simulator. To make the fields independently auditable without exposing a user’s wallet, the production detail view was loaded with a public Ethereum mainnet transfer and then the Simulator was restored. No funded Aperture account, recovery phrase, private key, passcode, or user address appears in the captures. The example transaction is 0xcb87a10a5e90a95b860ec6eb029956ff587c08db988f08f7c62a6f07ecf182b0 on Ethereum mainnet. A live mainnet RPC returned a successful receipt in block 25,875,394 with 21,000 gas used. The screenshot is a point-in-time record; the block naturally accumulated more confirmations after capture. ## Begin in Activity, then open the receipt Activity gives you the wallet-level summary: direction, asset, amount, relative time, and a status badge. In the example, Aperture shows a sent Ethereum transfer of 0.01184295 ETH. That row is useful for recognition, but it is intentionally not the complete proof. Open it before comparing details or answering a support question. ![Real Aperture Activity screen in the iOS Simulator showing a confirmed public Ethereum mainnet send](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/transaction-details/01-activity-real.webp) Real Aperture Activity screen. The amount is rounded for reading; the transaction detail and public receipt preserve the identity needed for verification. ## 1. Read the status—then separate confirmation from finality Aperture models four transaction states: - Pending. The transaction has been submitted or its outcome is not yet terminal. It may be waiting for block inclusion, provider reconciliation, or a network-specific status update. - Confirmed. Aperture has received a successful terminal result for the transaction. On Ethereum, that means the transaction was included and its receipt reported success. - Failed. Execution or submission reached a terminal failure. On fee-based networks, failure does not automatically mean that no network fee was consumed. - Canceled. The activity record was canceled in a supported flow. Treat it as a distinct terminal state and verify the transaction ID or explorer record whenever value movement is uncertain. “Confirmed” and “finalized” are related but not universal synonyms. Different blockchains use different consensus rules, confirmation counts, and finality models. Ethereum’s transaction lifecycle moves from a generated hash to the pending pool, block inclusion, justification, and finalization. Its proof-of-stake documentation describes finality as a checkpoint state backed by validator votes, not simply the first successful receipt. For everyday wallet reading, Aperture’s confirmed status answers “did this network report a successful transaction?” It does not promise that every supported network has reached the same depth or economic finality at the same moment. For a high-value payment, apply the recipient or service’s required confirmation policy and inspect the matching network explorer. ![Real Aperture Transaction Information screen showing confirmed status, timestamp, Ethereum network, recipient, sender, and transfer amount](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/transaction-details/02-transaction-overview-real.webp) Real Transaction Information screen. The green status, exact timestamp, Ethereum identity, recipient, and sender are visible before the fee or transaction ID. ## 2. Direction tells you whose perspective you are reading The same on-chain movement looks different depending on the selected wallet account. Aperture uses direction to make that perspective explicit: - Sent shows a negative asset amount because value left the selected account. For sent transfers, Aperture places the recipient before the sender so the destination is easy to check first. - Received shows a positive amount and places the sender before the recipient. The recipient still needs to confirm that the destination belongs to the intended account and network. - Self-transfer means the wallet recognized both sides as part of the same ownership context. A network fee may still apply even when the economic destination is yourself. - Swap represents an asset exchange. One transaction hash can contain several contract calls and token-transfer events, so the explorer may show more detail than one summary row. The plus or minus sign is a wallet perspective—not part of the raw blockchain amount. The chain records values and participants; Aperture derives whether the selected account received, sent, exchanged, or moved value to itself. ## 3. The transfer amount is not the total balance change Transfer Amount answers “how much of this asset was moved?” It does not necessarily answer “how much did my account lose in total?” A sender on a fee-paying network normally spends the transfer amount plus a separate fee paid in the network’s native asset. A recipient usually receives the transfer amount and does not pay the sender’s fee. In the public Ethereum example, the exact value field is 0.011842952936749721 ETH. Aperture presents -0.01184295 ETH for a readable sent summary. That rounding is presentation only; the transaction ID is the durable key for retrieving the exact public receipt. For token transfers, the asset being moved and the fee asset can differ. Sending an ERC-20 token, for example, moves the token while the Ethereum network fee is paid in ETH. Never subtract a token-denominated amount from a native-coin fee as if they were one unit. ## 4. Network fee is its own fact Aperture gives the network fee a separate section because it answers a different question: what did the network charge to process this operation? The fee is not an Aperture service charge and does not go to the recipient. Its mechanics depend on the selected mainnet. For this simple Ethereum transfer, the public receipt reports 21,000 gas used at an effective gas price of 1.091190433 gwei. Multiplying those values produces 0.000022914999093 ETH, which Aperture displays as 0.00002291 ETH. The official Ethereum gas documentation explains the same relationship: gas used multiplied by the cost per unit. Under EIP-1559, the effective cost includes the protocol base fee and a priority fee; the base fee is burned and the priority portion goes to the validator. Three fee rules prevent common misreads: - A fee is separate from the transfer amount. The recipient does not receive it. - A failed transaction may still cost a fee. Ethereum charges for computation already performed even when execution reverts or runs out of gas. - The displayed fee belongs to one network event. A bridge, swap, or multi-step workflow can create additional transactions with their own hashes and fees. ![Real Aperture transaction screen showing the transfer amount, separate Ethereum network fee, empty local-note field, and on-device note disclosure](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/transaction-details/03-fee-and-local-notes-real.webp) Real Aperture output. The transfer and fee are displayed in separate sections, followed by a note field whose footer states that notes stay on this iPhone and never enter the blockchain transaction. For a deeper breakdown of who receives, burns, or collects fees across network families, continue with Where Crypto Network Fees Actually Go. ## 5. Sender and recipient are identities, not labels The sender is the account that authorized the transaction. The recipient is the destination encoded by the transaction. On a simple native-coin transfer, that destination is usually another account. On a contract interaction, the recipient may be a smart contract while token-transfer logs describe the eventual asset recipients. Aperture abbreviates long identities in the overview so the screen remains readable. Tap a participant to open the complete address, then select the text when you need to compare or copy it. Do not verify only the first and last few characters: address-poisoning attacks are designed to make shortened strings look familiar. ![Real Aperture Recipient sheet showing the complete public Ethereum destination address](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/transaction-details/06-recipient-address-real.webp) Real Aperture Recipient sheet showing the full public Ethereum destination. The address is public chain data, not a recovery phrase or private key. Check addresses in this order: - Network first. An Ethereum address displayed on Base, Polygon, or another EVM network is a different chain context even when the hexadecimal string is identical. - Full destination second. Compare every character against the invoice, contact, or independently opened source. - Direction third. Make sure you are not reading your own sender address as the intended recipient. - Contract context last. For swaps and token transfers, use the network explorer to distinguish the called contract from transfer-event recipients. ## 6. The transaction ID is the receipt key A transaction ID—often called a transaction hash—is a public identifier derived from the signed transaction. It is not a password, private key, passcode, or recovery phrase. Sharing it reveals the public transaction and its addresses, amounts, timing, and contract activity, but it does not grant spending authority. Aperture presents the complete ID in a dedicated sheet and pairs it with copy, share, and chain-specific explorer actions. The explorer destination is selected from the transaction’s network, so an Ethereum hash opens on Ethereum’s explorer rather than on a different EVM chain. ![Real Aperture Transaction ID sheet showing the complete public hash with copy, share, and block-explorer actions](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/transaction-details/05-transaction-id-actions-real.webp) Real Aperture Transaction ID sheet. The full hash matches the independently verified public mainnet receipt used for this guide. Use the hash to answer questions the compact wallet view should not overload onto one screen: - Was the transaction found on the intended network? - Which block included it, and how old is that block now? - Did execution succeed or revert? - How much gas or network resource was actually consumed? - Were there token-transfer events, contract calls, memos, or destination tags? A block explorer is a read-only verification surface unless you deliberately connect a wallet or sign something. You do not need to enter a recovery phrase, private key, or passcode to inspect a transaction. If an explorer page or support message asks for one, leave immediately. ## 7. Local notes add context without rewriting history Blockchains preserve protocol facts, not your reason for sending. “Rent,” “invoice 1042,” “hardware-wallet consolidation,” or “support case opened” are personal context. Aperture lets you attach that context locally after the transaction exists. Transaction notes accept up to 1,000 UTF-8 bytes. Aperture trims surrounding whitespace, saves the normalized note in its local activity database, and exposes a delete action after saving. The note is not broadcast, cannot change the transaction, and is not visible to the recipient, validator, explorer, or anyone reading the chain. ![Real Aperture transaction screen showing a saved device-local mainnet verification note and its delete action](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/transaction-details/04-saved-local-note-real.webp) Real saved-note state. The neutral example records that the public receipt was checked; the footer makes the privacy boundary explicit. The temporary transaction and note were removed when the isolated Simulator was restored. Good notes explain intent without storing secrets. Useful examples include an invoice number, a contact name already safe to keep on the device, a tax lot label, a support ticket, or the reason an internal wallet was consolidated. Never place a recovery phrase, private key, passcode, API credential, full card number, or authentication code in a transaction note. Because the note stays on that iPhone and is not part of the blockchain record, do not treat it as an off-device backup or proof that a payment occurred. The transaction ID and network receipt prove the public event; the note is your private memory aid. ## A complete reading of the example transaction Here is how to read the public example from top to bottom without guessing: - Direction: Sent. The selected wallet perspective is outgoing, so Aperture prefixes the amount with a minus sign. - Status: Transaction Confirmed. The Ethereum receipt reported success; later blocks continued to build confirmation depth after capture. - Time: August 31, 2026 at 7:54:59 PM in the Simulator’s locale. The underlying block timestamp is public. - Network: Ethereum mainnet. This determines the explorer and the meaning of the 0x addresses. - Recipient: 0x42a8c9eade0235eff2b8b68f986d39ecea966180. Aperture shows a compact form in the overview and the complete value in the detail sheet. - Sender: 0x2394ac15081657c3289a3417adf734fad8172907. This public address authorized the transfer shown by the receipt. - Transfer amount: 0.011842952936749721 ETH exactly; 0.01184295 ETH in the readable Aperture presentation. - Network fee: 0.000022914999093 ETH exactly; 0.00002291 ETH in Aperture. It equals 21,000 gas multiplied by 1.091190433 gwei. - Transaction ID: 0xcb87a10a5e90a95b860ec6eb029956ff587c08db988f08f7c62a6f07ecf182b0. This is the public key to the matching Ethereum receipt. - Local note: “Verified on Ethereum mainnet - receipt checked.” This exists only in the isolated iPhone activity database and has no on-chain effect. ## When the details do not match your expectation Pending for longer than expected. Open the transaction ID on the correct network explorer. If no receipt exists yet, the transaction may still be queued, underpriced, replaced, or awaiting provider reconciliation. Do not send the same payment again merely because the first row is pending. Failed but a fee was charged. That can be normal on computation-based networks. The state change may revert while validators still process the attempted execution. Use the explorer receipt to inspect the failure and gas consumed. Amount looks right but the address does not. Stop and compare the complete destination. A correct amount cannot repair a wrong network or recipient, and irreversible blockchain transfers normally cannot be recalled by Aperture. Two rows look identical. Compare their complete transaction IDs. Retries, replacements, batched actions, token-transfer logs, and self-transfers can create similar-looking summaries with distinct hashes or event indexes. The explorer cannot find the hash. Confirm that you opened the explorer for the exact mainnet shown in Aperture. A hash searched on the wrong EVM chain may return nothing even though the transaction is valid elsewhere. The local note is missing on another device. That note was never on-chain. Use the original iPhone if the note is still needed, and keep durable records separately when accounting or compliance requires them. ## The 30-second verification checklist - Open the row. Do not verify from Activity alone. - Read status and timestamp. Decide whether you need more network-specific confirmation depth. - Confirm the mainnet. Every address and explorer result depends on it. - Check direction. Know whether the amount is leaving, arriving, swapping, or returning to your own wallet. - Compare the full recipient. Tap through; never rely only on the shortened characters. - Compare the sender when relevant. For received funds, make sure the expected account actually authorized the transfer. - Separate amount from fee. They answer different questions and may use different assets. - Open the transaction ID. Use the matching chain explorer for the public receipt and deeper execution data. - Add a safe local note. Record context, never secrets. ## Questions people ask Is a transaction hash safe to share? It does not grant spending authority, but it exposes the public transaction and can link addresses and activity. Share it only when that privacy tradeoff is acceptable. Never share a recovery phrase or private key. Does “confirmed” mean irreversible? It means Aperture received a successful terminal result. The depth and finality guarantees continue to depend on the network. High-value recipients may require additional confirmations or explicit finality. Why is the fee smaller or larger than I expected? Network demand, transaction complexity, gas or resource use, and the fee policy selected before sending all matter. Compare the final receipt with the pre-send estimate. Why does a token send charge ETH, SOL, TRX, or another native coin? The token is the transferred asset; the chain’s native asset generally pays for execution or network resources. Can I edit the blockchain transaction after adding a note? No. The note is separate local metadata. It cannot change the sender, recipient, amount, fee, hash, status, or block record. Can Aperture recover a transfer sent to the wrong address? Aperture cannot reverse a confirmed blockchain transfer. Contact the recipient or service if one can be identified, preserve the transaction ID, and ignore anyone who asks for your recovery phrase to “recover” it. ## One receipt, read without guesswork A trustworthy transaction screen should not compress everything into “success” and one number. Aperture keeps the public facts separate: status, time, network, direction, participants, transfer amount, fee, and transaction ID. It keeps your personal context separate too, in a note that never becomes part of the chain. That separation is the point. The blockchain receipt answers what happened publicly. The wallet view explains how that event affects the selected account. The local note records why it mattered to you. Read all three layers, and a transaction stops being a mysterious line item. It becomes an auditable record. > Status tells you the outcome Aperture received. The hash tells you which public event to verify. The note tells only you why it mattered. ## Continue learning Before creating the receipt, use Send Crypto Without Guesswork: From Recipient to Finality. To understand the charge shown in the fee section, read Where Crypto Network Fees Actually Go. To retrieve the same transaction later by asset, address, or hash, continue with Find Anything in Your Wallet: Aperture Universal Search. For the device boundary around keys and local wallet data, see What Never Leaves Your iPhone: Aperture’s Self-Custody Security Model. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # Add a Custom Token Without Trusting Its Name or Symbol - Canonical URL: https://aperturex.io/articles/add-custom-token-without-trusting-name-symbol/ - Category: Security - Author: Aperture Editorial - Published: 2026-08-31T12:46:45+00:00 - Updated: 2026-08-31T12:46:46+00:00 - Reading time: 12 minutes - Topics: Aperture, Custom Tokens, Token Contracts, EVM, Solana, TRON, Wallet Security Add a token by the identity that matters—mainnet plus contract or mint address—then understand what names, symbols, decimals, logos, and prices can and cannot prove. ![Independent editorial still life of a cobalt address rail passing through a graphite network gate beside three differently keyed blank token discs](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/custom-token-identity/custom-token-identity-editorial-cover.webp) A token can call itself anything. Its name can imitate a familiar project. Its ticker can reuse three or four trusted letters. Its logo can be copied pixel for pixel. None of those labels tells your wallet which on-chain asset you are looking at. The durable identity is the combination of network and token address: an EVM or TRON contract address on a specific mainnet, or a Solana mint address on Solana mainnet. Aperture makes you choose that network first, validates the complete address, and only then resolves the display metadata. The order is deliberate: identity before presentation. > Trust the mainnet-and-address pair. Treat the name, symbol, logo, decimals, and price as information to review—not proof of authenticity. ## Why a ticker is not an identity On ERC-20-style tokens, functions such as name, symbol, and decimals exist so interfaces can display a contract in human-friendly form. The Ethereum ERC-20 walkthrough describes them as user-interface helpers. A new contract can return the same name and symbol as an established token. The blockchain does not reserve a ticker globally. That creates four common traps: - Copied symbol. A malicious token can return “USDC,” “ENS,” or another familiar ticker without being the asset you intended. - Copied name and artwork. Polished metadata can make the wrong contract look convincing in a list. - Right address, wrong network. The same 0x string on Ethereum and Base refers to two separate chain contexts. A valid address shape does not select the chain for you. - Right contract, misleading search result. A sponsored result, direct message, or copied social post can replace one address with another while keeping every visible label familiar. For EVM assets, Aperture canonicalizes the identity as the selected network plus a lowercased 0x contract address. Solana mint addresses remain case-sensitive. TRON contract addresses use the mainnet Base58Check form. Those formats differ, but the rule does not: the address is meaningful only inside the network you selected. ## What “adding a token” actually does Adding a custom token tells Aperture to track an existing on-chain asset for the selected wallet account. It does not deploy a token, create a blockchain account, receive funds, import a private key, approve a spender, sign a message, or move value. A saved token with no balance simply appears with a zero balance. Aperture stores the asset under its network-and-address identity, enables it for the selected account, pins it for visibility, and schedules a balance refresh. If the same identity is added again, Aperture updates and re-enables the existing record instead of trusting a changed name or symbol as a second asset. ## Before you open Aperture: verify at the source Use a primary source controlled by the issuer or protocol. For this walkthrough, the public example is the ENS governance token on Ethereum mainnet. ENS states that token.ensdao.eth is its official governance token, and official ENS DAO material identifies the token contract as 0xC18360217D8F7Ab5E7c516566761Ea12Ce7F9D72. The contract address is public; it is not a wallet secret. Then cross-check the exact string in a reputable explorer for the same network. Confirm all 42 EVM characters, including the 0x prefix. Do not compare only the first and last four characters. Never take a contract address from a token sent unexpectedly to your wallet, a reply below a social post, a support direct message, or an advertisement. - Source one: the project or issuer’s official documentation. - Source two: a reputable block explorer opened independently for the chosen mainnet. - Final comparison: network name and every address character—not the token logo or ticker. ## 1. Open Manage Your Assets From Aperture’s wallet home, open the complete asset list, then use the settings control to reach Manage Your Assets. The add control in the upper-right starts the custom-token flow. ![Real Aperture Manage Your Assets screen in the iOS Simulator with the custom-token add control](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/custom-token-identity/01-manage-assets.webp) Real Aperture 2.40.12 output from the isolated iOS Simulator. The article wallet contained no funds, and no recovery phrase, private key, passcode, or funded address appears in any screenshot. ## 2. Choose the network before the token Aperture does not ask for a ticker and then guess a network. It asks for the chain first. In the production build used here, custom-token lookup is available on Ethereum, BNB Smart Chain, Arbitrum, Base, Polygon, Optimism, Avalanche, Gnosis, Linea, Scroll, Taiko, Telos, X Layer, Solana, and TRON—all mainnets. ![Real Aperture custom-token network picker showing supported mainnets in the iOS Simulator](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/custom-token-identity/02-choose-network.webp) Real production network picker. Ethereum is correct for the official ENS token used in this walkthrough. A similarly named token on another chain would be a different asset identity. This first choice prevents a dangerous shortcut: treating “0x…” as sufficient context. Multiple EVM networks share the same address format, but they do not share one asset registry. ## 3. Enter or scan the complete token address After choosing Ethereum, Aperture accepts a complete 0x-prefixed address. You can paste it, type it with the ASCII keyboard, or scan a QR code and review the recognized network and address before using it. Aperture filters the field to the expected address alphabet and length; an EVM address must contain 40 hexadecimal characters after 0x, and the zero address is rejected. ![Real Aperture Add a Custom Token screen for entering or scanning an Ethereum contract address](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/custom-token-identity/03-contract-entry.webp) Real empty contract-entry screen. Aperture begins the lookup only after the address is complete, so a partial string is not treated as a token identity. Solana follows its own rules: the mint must be a valid, case-sensitive Solana address. TRON requires a valid Base58Check contract address on TRON mainnet. Never “fix” capitalization on a Solana mint by hand, and never convert an address from one network’s format into another to make a form accept it. ## 4. Read the result in the right order When the address is complete, Aperture performs a chain-scoped lookup. The review card is designed to be read from strongest identity evidence to weakest presentation evidence: - Network. Is this the exact mainnet named by the issuer? - Contract or mint address. Does every character match the primary source? - Decimal places. Does the token’s unit precision match the expected on-chain definition? - Name and symbol. Do they look plausible only after the identity pair has matched? - Logo and market price. Are they helpful presentation data without being treated as authentication? ![Real Aperture token review showing the ENS name, symbol, Ethereum network, 18 decimal places, market price, and normalized contract address](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/custom-token-identity/04-token-identity-resolved.webp) Real live lookup of the official ENS token on Ethereum. Aperture normalized the stored identity to 0xc18360217d8f7ab5e7c516566761ea12ce7f9d72 and returned the ENS name, ENS symbol, 18 decimal places, and the market price available at capture time. Prices change; the contract identity does not. The warning under the card is the central rule of the flow: confirm the network and token address before saving, because anyone can create a token with a misleading name or symbol. ## What Aperture validates behind the review card Aperture applies network-specific checks rather than flattening every token into a ticker search: - EVM mainnets: the address is normalized, validated, rejected if it is the zero address, and looked up only inside the selected chain. The provider result must match both that chain and contract. Aperture requires a usable bounded name, symbol, and decimal value before it will offer the save action. - Solana mainnet: Aperture validates the mint account, compares the on-chain decimals with eligible metadata, and blocks results marked suspicious, denylisted, or hard-denied by the wallet safety policy. For an overview of mint identity and decimals, see Solana Token Basics. - TRON mainnet: Aperture validates the Base58Check contract address, reads the token name, symbol, and decimals through chain RPC calls, and applies the same hard-deny safety boundary. The metadata functions mirror the display-oriented fields described in the TRC-20 contract example. A malformed response does not become a generic “connection” story. Aperture distinguishes invalid addresses, missing token metadata, unsafe tokens, unsupported networks, provider errors, and unreadable responses so the result remains actionable. ## Decimals control display math—not legitimacy A token balance is stored on-chain as an integer. Decimals tell a wallet where to place the decimal point for human display. With 18 decimals, an atomic balance of 1,000,000,000,000,000,000 displays as one token. With 6 decimals, 1,000,000 displays as one token. Decimals do not prove value, backing, redeemability, ownership, or issuer identity. A fake token can choose the same decimals as a real one. Aperture requires a usable decimal value because incorrect precision would display the balance incorrectly—but the network-and-address pair still determines which asset it is. ## A logo is a convenience, never a credential Aperture resolves token artwork by blockchain plus normalized contract or mint address. Bundled catalog artwork is authoritative for known identities. For an EVM custom token absent from that catalog, a provider thumbnail may be used; Solana and TRON custom tokens without approved catalog artwork use a neutral fallback. Every logo is shown as a circular crop. That hierarchy avoids selecting artwork from a ticker or display name, but no artwork source changes the verification rule. A perfect logo beside the wrong contract is still the wrong token. A neutral fallback beside the right verified contract is still the right identity. ## The same address on another network is not the same lookup To make the network boundary visible, we entered the official ENS Ethereum contract while Base was selected. At capture time, Aperture did not quietly reuse the Ethereum metadata. The chain-scoped lookup returned “Token Could Not Be Found.” ![Real Aperture lookup result showing that the official ENS Ethereum contract address is not found when the Base network is selected](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/custom-token-identity/06-wrong-network-not-found.webp) Real production result, not a mock error. The address has a valid EVM shape, but Base is the wrong context for this official Ethereum token identity. A different contract could exist at the same 0x string on another EVM chain. If it did, it would still be that chain’s contract—not automatic proof that it represents the Ethereum asset. Always verify the network and address together. ## 5. Add the verified identity Only after the network and full address match should you tap Add This Token. Aperture saves the token under its canonical identity and enables it in Manage Your Assets. The ENS example appears with an Ethereum network badge and a zero balance in the empty article wallet. ![Real Aperture Manage Your Assets search result showing Ethereum Name Service enabled after the verified contract was added](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/custom-token-identity/05-token-added.webp) Real post-save state. The temporary ENS entry was hidden again after capture, and the Simulator was returned to the original wallet home screen. If a balance exists for the selected wallet account, the next synchronization can populate it. Adding the token does not make an unsupported balance appear, manufacture a price, or change anything on-chain. It changes what Aperture tracks and presents locally. ## When a price is missing “Currently Unavailable” means Aperture did not obtain a current market quote for that exact asset identity. It does not mean the token is worthless, and a displayed price does not mean the token is safe. Price coverage, liquidity, and authenticity are separate questions. Never substitute the price for the contract check. Scam tokens can advertise fabricated values, and illiquid markets can produce quotes that cannot be realized. Verify identity first; evaluate the asset and market separately. ## What to do with an unexpected token A token can be sent to a public address without your permission. Its presence is not a gift you must claim and not proof that the project is legitimate. Do not visit a URL embedded in its name, follow instructions in its symbol, connect to an unknown site, sign an approval, or send another asset to “unlock” it. If the asset is irrelevant or suspicious, leave it hidden. Adding or displaying a token is not required to preserve the blockchain balance: the chain already records it. The dangerous step is usually not seeing the token—it is interacting with an untrusted contract or website because the token told you to. ## A safe custom-token checklist - Name the mainnet first. Ethereum, Base, Solana, TRON, and every other supported network are separate identity scopes. - Get the address from a primary source. Use the issuer or protocol’s official documentation, not a search ad, direct message, or token list copied into a post. - Cross-check independently. Open a reputable explorer for that exact network and compare every address character. - Choose the network in Aperture. Do not let a shared 0x format tempt you into assuming the chain. - Enter or scan the complete address. Review the recognized value before the lookup. - Read the result in identity order. Network, address, decimals, then name, symbol, logo, and price. - Stop on any mismatch. Do not “try another network” until a familiar name appears. Return to the primary source instead. - Add only what you intend to track. Saving changes local tracking; it does not endorse the token or authorize a transaction. ## Questions people ask Can two tokens have the same symbol? Yes. Symbols are display metadata and are not globally unique. Two unrelated contracts can both return the same ticker, even on the same network. Can the same contract address appear on two EVM networks? Yes. EVM networks share an address format, but each network has its own state. The chain plus address is the identity; the address string alone is incomplete. Does capitalization matter? Aperture accepts EVM hexadecimal input and stores the normalized lowercase identity. Solana mint addresses are case-sensitive and must retain their exact capitalization. TRON uses its Base58Check mainnet address format. Does a correct name and logo mean the token is official? No. Both can be copied. Verify the exact network and contract or mint address against a primary source. Does adding a token give its contract permission to spend? No. Adding is local tracking. Spending permission requires a separate signed approval or transaction. Never sign one merely because the token now appears in the wallet. Why did Aperture reject a complete address? It may be malformed for that chain, the zero address, absent from the selected network’s fungible-token metadata, inconsistent with on-chain decimals, blocked by the safety policy, or unavailable because a provider returned a concrete error. Can I hide a token without losing it? Yes. Visibility is local presentation. Hiding an asset does not transfer, burn, or remove its on-chain balance. ## Identity first, metadata second Custom-token support is useful because blockchains are open: a wallet should not need a software update before it can recognize every legitimate asset. That openness is also why a familiar ticker can never be the trust anchor. Anyone can publish a label. Only the selected chain and exact contract or mint address identify the asset Aperture will track. Verify those two facts outside the wallet, reproduce them inside Aperture, and then use the fetched name, symbol, decimals, logo, and price as a review surface. The interface becomes clearer, the risk becomes explicit, and “Add a Custom Token” stops being a search box for names. It becomes what it should be: a precise request to follow one public on-chain identity. > A familiar symbol can be copied. A verified network-and-address pair is specific. ## Continue learning To understand how Aperture separates accounts by chain, read One Wallet, Many Mainnets: How Aperture Keeps Accounts and Networks Separate. For the device and key boundary behind every tracked asset, continue with What Never Leaves Your iPhone: Aperture’s Self-Custody Security Model. When you are ready to receive, use Receive Crypto Safely: Network, Address, QR Code, and Requested Amounts to keep the same network-first discipline all the way to the sender. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # Lock Aperture Down: Passcode, Face ID, Auto-Lock, and App Switcher Privacy - Canonical URL: https://aperturex.io/articles/lock-aperture-down-passcode-face-id-auto-lock-app-switcher-privacy/ - Category: Security - Author: Aperture Editorial - Published: 2026-08-31T12:27:08+00:00 - Updated: 2026-08-31T12:27:10+00:00 - Reading time: 10 minutes - Topics: Aperture, App Lock, Face ID, Auto-Lock, iPhone Security, Privacy Build a practical local access boundary with Aperture’s app passcode, Face ID shortcut, automatic locking, and balance-redacting app-switcher privacy. ![Independent editorial security sculpture with a six-dot graphite module, cobalt biometric contour, ivory timing gate, and graphite privacy shutter](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/app-lock-privacy/lock-aperture-down-editorial-cover.webp) A self-custody wallet can keep its keys on your iPhone and still reveal too much when the phone is already unlocked. A curious friend can open the app. A colleague can glance at the app switcher. A short trip away from your desk can become a long open session. The recovery phrase may remain perfectly local while the wallet interface is unnecessarily exposed. Aperture addresses that everyday risk with four separate controls: a six-digit app passcode, Face ID as an unlock shortcut, an automatic-lock timer, and a privacy mode for iOS app-switcher previews. They work together, but they do different jobs. Understanding the boundary of each one is the difference between a security setup and a collection of toggles. > Protecting the keys and protecting the visible wallet are related jobs—not the same job. ## The four layers at a glance ![Real Aperture Security settings in the iOS Simulator before App Lock and App Switcher Privacy are enabled](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/app-lock-privacy/01-security-controls-off.webp) Real Aperture 2.40.12 output from an empty article-only wallet in the iOS Simulator. No recovery phrase, private key, funded address, or passcode appears anywhere in this guide. - App Passcode: a local gate in front of the wallet interface and protected actions. It is separate from your iPhone passcode and separate from your recovery phrase. - Face ID: an iOS-evaluated convenience path for satisfying the App Lock gate without typing the Aperture passcode. - Automatic Lock: the rule that decides how soon Aperture asks for authentication after the app becomes inactive. - App Switcher Privacy: a presentation control that conceals balances and amounts while Aperture is shown in the iOS app switcher. App Lock is the foundation. Face ID and automatic locking stay unavailable until it is enabled. App Switcher Privacy is independent: you can use it even without App Lock because hiding a balance preview and blocking access are different decisions. ## Start with the threat you actually have These controls are built for local-access and shoulder-surfing risks: someone briefly holding an already-unlocked iPhone, an unattended device that has not locked yet, or a revealing app-switcher card. They are not a substitute for a strong iPhone passcode, current iOS, a verified wallet backup, or careful handling of the recovery phrase. For most people, a sensible target is simple: Aperture should close its local access window quickly, Face ID should make reopening painless, and the app switcher should not advertise the wallet balance. If your phone is routinely shared, used in public, or holds meaningful value, choose a shorter timing rule. ## 1. Create the Aperture app passcode Open Aperture, tap the settings control on the wallet home, choose Security, and turn on Require an App Passcode. Aperture asks for six digits and then asks you to enter the same six digits again. The confirmation step prevents a mistyped passcode from becoming the only value the app accepts. ![Real Aperture Create Passcode screen in the iOS Simulator before any digit is entered](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/app-lock-privacy/02-create-app-passcode.webp) Real setup screen captured before any digit was entered. The custom keypad and six empty indicators make the credential length explicit without displaying the eventual value. ![Real Aperture Confirm Passcode screen in the iOS Simulator before any confirmation digit is entered](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/app-lock-privacy/03-confirm-app-passcode.webp) Real confirmation screen, again captured with every indicator empty. The temporary Simulator-only credential was never shown, logged, or reused. ## What Aperture stores—and what it does not Aperture does not store the readable six-digit passcode. It generates a fresh 32-byte random salt and derives a 32-byte verifier with PBKDF2-HMAC-SHA256 using 210,000 iterations. Passcode comparisons use a constant-time byte comparison. The verifier is stored in Aperture’s app-scoped iOS Keychain vault as a non-synchronizing, this-device-only item available only while the device is unlocked. The wallet database keeps an opaque Keychain reference plus the failed-attempt count and any active lockout deadline. That separation means copying the ordinary database is not the same as obtaining the passcode verifier, and the verifier is not the wallet’s recovery phrase or private key. For the broader storage boundary, read What Never Leaves Your iPhone: Aperture’s Self-Custody Security Model. The distinction is important: App Lock protects access to Aperture on this device. It does not alter the blockchain keys, add words to the recovery phrase, or replace an optional BIP-39 passphrase. If you need the latter, see Add a BIP-39 Passphrase to an Aperture Wallet. ## Wrong guesses slow down instead of running forever The first four incorrect app-passcode attempts return an error. The fifth starts a five-second lockout. Continued failed attempts escalate through 30 seconds, 5 minutes, 30 minutes, 1 hour, and then a maximum 6-hour delay. A successful passcode entry resets the failed-attempt count and clears the lockout. This is defense in depth, not a reason to choose a predictable PIN. Avoid repeated digits, dates, phone fragments, and the same code you use elsewhere. More importantly, keep the iPhone itself protected: Aperture’s six-digit gate is one local layer inside Apple’s device security, not a replacement for it. ## 2. Add Face ID as the shortcut—not the foundation After App Lock is active, turn on Unlock with Face ID. Aperture does not silently accept the setting change. It first asks iOS to verify the currently enrolled face. Only a successful biometric result enables the preference. ![Real iOS Face ID verification over Aperture Security settings while biometric unlock is being enabled](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/app-lock-privacy/04-face-id-verification.webp) Real iOS Face ID verification over the production Aperture Security screen. The underlying screen remains visually protected while the system owns authentication. Aperture asks iOS to evaluate Face ID and receives an authentication result; it does not store a facial template in the wallet database. The app passcode remains the fallback credential. If Face ID is unavailable, interrupted, cancelled, or unsuccessful, Aperture routes back to passcode entry instead of treating biometric failure as proof of identity. ![Real Aperture Security settings with App Passcode, Face ID, immediate automatic locking, and App Switcher Privacy enabled](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/app-lock-privacy/05-security-controls-enabled.webp) Real Security settings with every article feature enabled for verification: App Passcode, Face ID, immediate automatic locking, and App Switcher Privacy. All four were returned to their original test-device state after capture. ## Face ID failure is a detour, not a dead end ![Real iOS Face ID not recognized prompt displayed over Aperture during wallet unlock](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/app-lock-privacy/08-face-id-fallback.webp) Real iOS Simulator biometric failure. No artificial error card or mock interface was used. If the face is not recognized, iOS can try again or cancel. Cancelling the biometric prompt reveals Aperture’s own passcode screen. The Face ID control on the keypad also lets you retry biometrics later when the setting and device availability permit it. ![Real Aperture Unlock Your Wallet passcode screen after Face ID fallback](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/app-lock-privacy/09-app-passcode-unlock.webp) Real automatic-lock result: Aperture reopened to its six-digit passcode gate. The indicators were empty and the temporary test passcode was never visible. ## 3. Choose how quickly Aperture closes the access window Automatic Lock starts from a plain question: after Aperture becomes inactive, how long should the existing authenticated session remain usable? The available choices are: ![Real Aperture Automatic Lock Delay screen listing immediate, timed, and never-lock choices](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/app-lock-privacy/06-auto-lock-choices.webp) - Immediately After Leaving. Aperture requests the wallet lock as soon as the app becomes inactive. This is the strongest choice for shared devices, public environments, or users who prefer an explicit unlock every time. - After 30 Seconds or After 1 Minute. Short grace periods make quick app switches convenient while keeping the unattended window small. One minute is the production default shown before App Lock is configured. - After 5 Minutes or After 15 Minutes. Longer sessions reduce repeated prompts but leave a larger opportunity if the unlocked phone changes hands. - Never Lock Automatically. Background inactivity does not trigger the timer. App Lock still exists and can apply on a protected launch or protected action; this choice only removes inactivity-based locking. For timed choices, Aperture records when it entered the background and compares the elapsed time when it becomes active again. With the immediate choice, the lock request happens on the inactive/background transition itself. If App Lock is turned off, Face ID and automatic locking are disabled with it. ## 4. Conceal the app-switcher preview Turn on App Switcher Privacy to reduce casual balance exposure whenever Aperture is inactive. The wallet card remains recognizable, but total balance, token balances, and fiat amounts are replaced with neutral placeholders. Asset names and the overall interface structure remain visible, so this is selective redaction rather than a fake blank screen. ![Real iOS app switcher showing Aperture wallet balances and asset amounts replaced by neutral placeholders](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/app-lock-privacy/07-app-switcher-privacy.webp) Real iOS app-switcher capture from the empty article wallet. No blur was added to the screenshot; the gray amount placeholders are Aperture’s production privacy behavior. This control does not lock the app, hide public blockchain data from a network provider, prevent a screenshot you deliberately take while Aperture is active, or retract information copied to the clipboard. It solves one specific presentation problem well: the app switcher no longer becomes a passive balance display. ## How the layers behave together - You leave Aperture. App Switcher Privacy redacts amounts as the app becomes inactive. It does not wait for the auto-lock timer. - The selected delay expires. Aperture marks the wallet as requiring authentication. With “Immediately,” that happens as soon as you leave. - You return. If Face ID is enabled and available, iOS receives the first authentication request while Aperture keeps protected content covered. - Face ID succeeds. The wallet opens without typing the app passcode. - Face ID cannot complete. Aperture falls back to the six-digit app passcode and preserves the lock. - You turn App Lock off later. Aperture also disables Face ID and inactivity-based automatic locking. App Switcher Privacy remains its own setting. ## Three practical configurations - Balanced daily use: App Passcode on, Face ID on, After 30 Seconds or After 1 Minute, App Switcher Privacy on. This is the best starting point for most personal phones. - Maximum local privacy: App Passcode on, Face ID on, Immediately After Leaving, App Switcher Privacy on. Every departure closes the wallet access window while Face ID keeps return friction low. - Biometric-minimal: App Passcode on, Face ID off, a short automatic-lock delay, App Switcher Privacy on. Choose this when you prefer deliberate passcode entry and accept the extra taps. “Never Lock Automatically” is appropriate only when you understand the tradeoff and the iPhone has a tightly controlled use pattern. Convenience is real, but so is the length of the authenticated session. ## What these controls cannot protect A strong local setup still has boundaries. App Lock, Face ID, automatic locking, and app-switcher redaction cannot: - recover a lost recovery phrase, private key, or required BIP-39 passphrase; - reverse a transaction already accepted by a blockchain; - hide public addresses and transaction history from the chain or every network provider; - protect a recovery phrase after you photograph it, paste it into a website, send it in a message, or reveal it to another person; - make a jailbroken or fully compromised operating system trustworthy; or - replace a verified backup plan for the day the iPhone is lost or destroyed. For recovery planning, continue with Lose Your Phone, Not Your Wallet: Backup and Restore in Aperture. Access control keeps today’s phone private; backup and restore determine whether tomorrow’s phone can recover the wallet. ## A two-minute setup checklist - Verify recovery first. Know where the recovery phrase and any required passphrase are stored before changing access settings. - Open Settings → Security. Enable Require an App Passcode and confirm a unique six-digit value. - Enable Face ID if desired. Complete the live iOS verification; do not assume the toggle alone is enough. - Choose the shortest workable delay. Start with Immediately, 30 Seconds, or 1 Minute and lengthen it only if the repeated prompts genuinely interfere with use. - Enable App Switcher Privacy. Open the iOS app switcher once and verify that balances are replaced by placeholders. - Test both unlock paths. Leave Aperture until it locks, return with Face ID, then cancel a biometric attempt once to confirm the app-passcode fallback. ## Questions people ask Is the Aperture app passcode my recovery phrase? No. It is a six-digit local access credential. The recovery phrase or private key controls the wallet itself. Changing the app passcode does not change wallet recovery information. Is the Aperture passcode the same as my iPhone passcode? No. They are separate credentials enforced by different layers. Use a strong iPhone passcode and do not deliberately reuse it as the Aperture passcode. Does Face ID replace the app passcode? No. Face ID is an optional unlock path layered on App Lock. The app passcode remains the fallback when biometrics are unavailable or unsuccessful. Does Aperture store my face? Aperture asks iOS to perform biometric authentication and stores only the preference to allow that path. The wallet database does not contain a facial template. Will App Switcher Privacy hide everything? No. It conceals balances and amount fields while leaving enough of the card to recognize Aperture. It is visual redaction, not an app lock and not blockchain anonymity. What happens if I disable App Lock? Face ID unlock and automatic locking are disabled with it. App Switcher Privacy remains separately configurable. ## The best lock is the one you will keep enabled Security controls fail when they are misunderstood, overestimated, or switched off after a frustrating day. Aperture’s model keeps the pieces explicit: the app passcode is the gate, Face ID is the fast path, automatic locking limits session lifetime, and App Switcher Privacy reduces visual leakage. Turn on the full stack, choose a delay that matches your real environment, and test the fallback before you need it. Your recovery phrase protects ownership. These controls protect the moments in between—when the wallet is on your phone, the phone is nearby, and privacy depends on what happens after you look away. > Keys secure the wallet. Good local controls secure the moments around it. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # What Never Leaves Your iPhone: Aperture’s Self-Custody Security Model - Canonical URL: https://aperturex.io/articles/what-never-leaves-iphone-aperture-self-custody-security-model/ - Category: Security - Author: Aperture Editorial - Published: 2026-08-31T12:01:39+00:00 - Updated: 2026-08-31T12:01:41+00:00 - Reading time: 12 minutes - Topics: Aperture, Self-Custody, iPhone Security, Keychain, Privacy, Wallet Security See exactly where Aperture keeps spending authority, what public wallet data reaches network providers, and how optional encrypted backup and direct transfer change the boundary. ![Independent editorial cutaway of a graphite device chassis with a sealed cobalt local vault, separate public-data rail, and orange verification tab](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/self-custody-security-model/what-never-leaves-iphone-cover.webp) “What never leaves your iPhone?” sounds like a yes-or-no question. For a wallet, it is more useful to ask it in layers. A recovery phrase is not the same kind of data as a public address. A signed transaction is not the same thing as a private key. An optional encrypted backup is not the same thing as an automatic secret upload. Aperture’s self-custody model draws the line around spending authority: the recovery phrase, private key, BIP-39 passphrase material, and credentials that protect access to the app. In normal use, Aperture keeps that authority on the iPhone. Public blockchain data still has to cross a network so the wallet can show balances, find activity, estimate fees, and broadcast a transaction you have signed. > Self-custody is not “nothing leaves the phone.” It is “nothing required to authorize spending leaves your control.” ## The boundary in one screen The wallet home is a view over two very different systems. The accounts, balances, prices, and activity are public or derived data that Aperture can refresh from mainnet providers. The keys that can move those assets are private material held locally. The interface puts both together without making them the same thing. ![Real Aperture wallet home in the iOS Simulator showing an empty Main Wallet and local asset overview](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/self-custody-security-model/01-local-wallet-home.webp) Real Aperture 2.40.12 Simulator output. This article-only wallet is empty. No recovery phrase, private key, passcode, signing material, or funded address appears anywhere in this guide. ## Three classes of wallet data A precise security model starts by classifying the data instead of treating the entire app as one sealed box. - Spending authority. Recovery phrases, imported private keys, passphrase-bearing wallet material, and derived signing keys can authorize transactions. Aperture stores persistent wallet secrets in the iOS Keychain and loads them only for a local operation that needs them. - Local working data. Wallet names, enabled networks, public account addresses, cached balances, activity records, contacts, preferences, and backup status live in Aperture’s local wallet database. The database stores opaque Keychain references—not plaintext recovery phrases or private keys. - Public network data. Addresses, token contracts, transaction hashes, block data, prices, fee estimates, and signed transaction bytes are not wallet secrets. Aperture sends the minimum request needed to blockchain, indexer, price, and broadcast providers for the feature you use. This separation matters after a database copy, diagnostic export, or ordinary network observation. A public address can reveal on-chain history, but it cannot create a signature. A Keychain reference can point Aperture to a secret on the same device, but it is not the secret itself. ## The secret vault is Keychain—not the wallet database For self-custody wallets, Aperture writes recovery phrases and private keys to a stable, app-scoped iOS Keychain service. The items are marked non-synchronizing and use the device-only “accessible when unlocked” protection class. In practical terms, these entries are available to Aperture after the iPhone is unlocked, do not join ordinary Keychain synchronization, and are not designed to migrate to another device through a device backup. Aperture verifies each Keychain write by reading it back before treating persistence as successful. The wallet database keeps the opaque reference plus public account records. If a wallet is removed, Aperture uses a cleanup journal and verifies the corresponding secret item is gone rather than assuming a delete call succeeded. There is an important wording distinction: Aperture does not claim that every wallet secret is a Secure Enclave private key. The implementation boundary is the app’s device-only iOS Keychain namespace. That is the concrete promise the code can verify. ![Real Aperture Settings screen in the iOS Simulator with Wallets Management and Security destinations](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/self-custody-security-model/02-settings-security-entry.webp) Real Settings screen. Wallet storage, app-access controls, and backup choices have separate destinations because they protect different boundaries. ## App Lock protects access; it does not replace the wallet key ![Real Aperture Security settings in the iOS Simulator with App Lock, biometrics, automatic locking, privacy, and secure transfer controls](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/self-custody-security-model/03-security-controls.webp) Real Security settings from the empty article-only wallet. App Lock and biometrics were intentionally left unconfigured; the screen documents the available layers without changing the wallet. Aperture’s App Lock is a local gate in front of the wallet interface and sensitive actions. A six-digit app passcode is never stored as readable text. Aperture derives a verifier with PBKDF2-HMAC-SHA256, 210,000 iterations, and a fresh 32-byte random salt, then keeps that verifier in the same device-only Keychain vault. The database stores only its reference and lockout state. Face ID can be enabled after App Lock and is evaluated by iOS. Automatic Lock controls how soon Aperture requires authentication after becoming inactive. These features reduce casual or opportunistic access if someone has an unlocked iPhone; they do not change the recovery phrase or the blockchain keys derived from it. ![Real Aperture App Lock setup screen in the iOS Simulator before any passcode digit is entered](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/self-custody-security-model/08-create-app-passcode.webp) Real App Lock setup before any digit was entered. The screen was cancelled after capture, so the article Simulator retained its original configuration. ## Privacy around the wallet matters too Security is not only key storage. A wallet preview can expose balances to someone looking over your shoulder or glancing at the iOS app switcher. Aperture’s App Switcher Privacy setting replaces the balance and amount fields in the background preview with neutral placeholders while leaving the app’s structure recognizable. ![Real iOS Simulator app switcher showing Aperture balances replaced by neutral privacy placeholders](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/self-custody-security-model/09-app-switcher-privacy.webp) Real iOS Simulator app-switcher capture. The preference was enabled only for this verification, then returned to its original off state. No blur was added to the screenshot. This is a visual privacy control, not cryptographic protection. It does not hide public addresses from a blockchain provider, encrypt screenshots you deliberately take, or stop another app from reading information you explicitly copy to the clipboard. ## What does leave the iPhone during normal use Aperture is a networked wallet. It cannot discover mainnet state without asking a node, indexer, or API about public accounts. Depending on the chain and feature, a request may include a public wallet address, script hash, transaction hash, token contract, chain identifier, requested page, or signed transaction payload. Price requests may include asset identifiers and quote currency. - Balance and activity queries. A public address or derived public query key is sent to a provider so Aperture can find balances, transfers, and confirmation state. A provider can ordinarily observe the request’s IP address, timing, and queried identifiers. - Fee and simulation requests. The draft’s public transaction fields may be sent to a network provider to estimate gas, fees, or execution. The private signing key is not part of that request. - Broadcast. After local review and authorization, Aperture signs on the device and sends the resulting signed transaction bytes to the selected mainnet provider. A signed transaction is meant to become public; the private key used to create its signature is not included. - Token and price metadata. Asset identifiers and market-data requests can leave the device so the interface can label assets and calculate fiat values. That means self-custody should never be confused with network anonymity. Public-chain providers and the chain itself can learn things from addresses and transaction patterns. If address privacy is the goal, use chain-specific techniques such as fresh Bitcoin receive addresses or Silent Payments; start with Why Bitcoin Wallets Generate Fresh Receiving Addresses and Silent Payments in Aperture. ## Optional iCloud backup changes the location—not the custody iCloud Backup is off until you turn it on for a wallet. When enabled, Aperture creates a unique Apple passkey for that wallet, obtains passkey-derived wrapping material through Apple’s authorization flow, generates a separate 256-bit backup data key, and encrypts the wallet payload locally with authenticated AES-GCM encryption. The data key is itself wrapped; Aperture does not put an unwrapped wallet secret into iCloud Drive. The encrypted “.aperturewallet” document in iCloud Drive contains ciphertext plus the metadata required to list, bind, and validate the backup—for example the backup wallet name, identifier, format version, timestamps, passkey credential identifier and salt, wrapped data key, integrity digest, and whether the wallet reports passphrase protection. The recovery phrase or private key is inside the encrypted payload, not in that readable metadata. Aperture writes the encrypted document, reads it back, decrypts it locally, and compares the restored payload before marking the backup verified. An explicit restore reauthorizes the Apple passkey, unwraps the data key, authenticates the ciphertext, and decrypts on the destination device. aperturex.io verifies only the app’s passkey association; it does not receive the wallet backup. ![Real Aperture wallet backup options explaining that every wallet has its own Apple passkey and backup encryption happens locally](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/self-custody-security-model/06-local-encryption-icloud-choice.webp) Real wallet-backup screen. The switch remained off; no iCloud backup was created for this article. The tradeoff is deliberate: encrypted recovery availability moves from one device to your Apple Account’s iCloud Drive and synced passkey ecosystem. If you prefer a fully offline backup, use the manual recovery material instead. For the full restore model and failure cases, read Lose Your Phone, Not Your Wallet: Backup and Restore in Aperture. ## Direct iPhone transfer is a private bridge Moving to a new iPhone is another explicit exception to “local to this device.” It is not an upload. Aperture creates a short-lived invitation containing a random session identifier, an ephemeral public key, and an expiry. The receiving iPhone scans that QR code and the two devices find each other through Apple’s nearby-device transport. Under the hood, the phones perform ephemeral P-256 key agreement, derive a 32-byte session key with HKDF-SHA256, authenticate the join request, and require encrypted Multipeer Connectivity. Aperture additionally seals the manifest, secret bundle, and completion messages with authenticated ChaChaPoly encryption bound to the session. The source sends a temporary database snapshot through the encrypted peer session, the destination verifies and imports it, and temporary transfer material is cleaned up. ![Real Aperture Security screen explaining direct encrypted iPhone transfer without an Aperture server upload](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/self-custody-security-model/07-encrypted-direct-transfer-note.webp) Real Security screen. No transfer session was started and no QR invitation was generated for this article. The old iPhone keeps its wallet after a successful transfer; migration is not remote deletion. Verify the destination before retiring the source device. See Move Everything to a New iPhone—Directly, Encrypted, and Serverless for the complete two-device flow. ## The deliberate exits: reveal, export, back up, transfer A secure wallet must let its owner recover and move. That means there are intentional paths where protected material can leave persistent Keychain storage: viewing a recovery phrase, exporting private keys, creating an encrypted backup, and sending an encrypted device-migration package. These are not hidden background behaviors; they are separate user actions. ![Real Aperture wallet settings showing deliberate recovery-phrase review, private-key export, and optional iCloud Backup controls](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/self-custody-security-model/05-wallet-backup-boundary.webp) Real wallet controls. The recovery phrase and private-key destinations were not opened, and no secret was displayed or exported. Once you reveal a phrase or private key, the environment matters. A camera, screen recording, compromised keyboard, untrusted clipboard manager, phishing site, or person nearby can defeat the app’s local storage protections. Aperture can require current app authentication before a sensitive export when App Lock is enabled; it cannot make a disclosed secret undisclosed again. ## Aperture’s security model, layer by layer - Ownership layer. Your recovery phrase or private key controls the wallet. Aperture does not hold a recovery copy that customer support can return to you. - Storage layer. Persistent wallet secrets and passcode verifiers live in app-scoped, non-synchronizing, device-only Keychain items; the database keeps references and public state. - Access layer. App Lock, optional biometrics, automatic locking, and short-lived authorization grants guard the interface and sensitive actions. - Presentation layer. Balance hiding and App Switcher Privacy reduce visual disclosure around the phone. - Signing layer. Aperture builds and signs transactions locally, then sends only the signed result for broadcast. - Recovery layer. Manual recovery material stays under your physical control; optional iCloud backup is encrypted locally and requires its Apple passkey. - Migration layer. A one-time nearby transfer uses ephemeral key agreement and authenticated encryption without an Aperture transfer server. - Verification layer. Writes, backup reads, secret deletion, transfer receipts, and imported account identities are verified before Aperture declares success. ## What the model does not promise Good security documentation should say where the boundary ends. Aperture cannot: - recover a lost recovery phrase, private key, required BIP-39 passphrase, or unavailable encrypted backup for you; - reverse a valid transaction after it is accepted by a decentralized network; - hide public addresses and transaction history from the blockchain or every network provider; - protect a secret after you type it into a website, send it in a message, photograph it, or give it to another person; - guarantee safety on a fully compromised or jailbroken operating system; or - turn a weak device passcode, unattended unlocked phone, or unverified backup into a strong recovery plan. Open source helps make these boundaries inspectable, not magical. You can review the project’s security approach and code links on the Aperture Open Source page. ## A five-minute security setup - Protect the iPhone first. Use a strong device passcode, keep iOS current, and do not jailbreak the device that holds your wallet. - Enable Aperture App Lock. Choose a six-digit app passcode that is not a reused PIN, then enable Face ID if it fits your threat model. - Choose an automatic-lock delay. Shorter is safer on a frequently shared or high-risk device; balance that against your daily use. - Turn on App Switcher Privacy. It reduces accidental balance disclosure when switching apps. - Verify one recovery route. Confirm the manual phrase and required passphrase privately, or create and verify the optional encrypted iCloud backup. Do not assume “backup enabled” means “restore tested.” - Practice the boundary. Never enter a recovery phrase or private key into a link, support chat, form, airdrop page, or “wallet verification” prompt. Aperture support does not need it. ## Questions worth asking Does Aperture upload my recovery phrase during normal sync? No. Normal balance, activity, fee, and price refreshes use public identifiers. Persistent recovery material remains in the device-only Keychain unless you deliberately reveal, export, back up, or transfer it. Can a blockchain provider see my wallet address? Yes. An address-based wallet must query public mainnet state somewhere. Providers can observe the identifiers and network metadata involved in those requests. That is a privacy consideration, not custody of the key. Is the local wallet database secret? It contains sensitive personal context—addresses, balances, activity, contacts, and settings—but it does not hold plaintext recovery phrases or private keys. Protect the device and app even though spending authority is separated into Keychain. Does Face ID encrypt the recovery phrase? No. Face ID is an access-control option for unlocking Aperture. Keychain protection and wallet cryptography are separate layers. What exactly is stored in iCloud? An authenticated encrypted wallet payload plus the metadata needed to identify, validate, and restore that backup. The Apple passkey is required to recover the wrapping material, and decryption happens locally. Does direct iPhone transfer touch Aperture servers? No. The transfer uses a temporary QR invitation and an encrypted nearby-device session. The two iPhones exchange the package directly. Can Aperture recover my wallet if every copy is gone? No. That is the defining consequence of self-custody. Keep at least one verified recovery path outside the single iPhone you could lose. ## The honest version of “never leaves” The recovery phrase, private key, and app-access verifier are local by default because they can authorize or expose control. Public addresses, mainnet requests, signed transactions, and market data cross the network because a useful wallet must read and write public systems. Optional iCloud backup sends only a locally encrypted document to iCloud Drive. Direct transfer sends an encrypted package to the other iPhone, not to Aperture. That boundary is more valuable than a slogan because you can act on it. Keep the device secure. Turn on the access and privacy controls you need. Verify a recovery method. Treat every reveal and export as a real exit. Then use the public network with a clear understanding of what it sees—and what it never receives. > Your public wallet can travel across the network. Your authority to spend should remain yours. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # Receive Crypto Safely: Network, Address, QR Code, and Requested Amounts - Canonical URL: https://aperturex.io/articles/receive-crypto-safely-network-address-qr-requested-amounts/ - Category: Security - Author: Aperture Editorial - Published: 2026-08-31T11:37:15+00:00 - Updated: 2026-08-31T11:37:17+00:00 - Reading time: 13 minutes - Topics: Aperture, Receiving Crypto, Network Safety, QR Codes, Payment Requests, Self-Custody Choose the exact asset and mainnet, verify the public destination, understand what the QR carries, and treat every requested amount as a request—not an authorization. ![Independent editorial sculpture with an ivory asset token, cobalt network gate, graphite address rail, and separate amount dial](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/receive-crypto-safely/receive-crypto-safely-cover.webp) Receiving crypto can look like the easy half of self-custody. Open a QR code, send it to someone, and wait. But the blockchain does not understand the human story around a payment. It does not know which token name you meant, which network the sender selected, whether a pasted address was altered, or whether “100” meant 100 units of the asset or 100 units of local currency. It only executes the exact transaction it receives. A safe receive request therefore has four independent facts: the asset, the network, the destination, and the amount. Aperture makes the first three visible together. The fourth remains something the sender must review and authorize. This guide explains each boundary using the production Receive flow—not a mockup—and shows what the QR code carries beneath the squares. > Choose the asset. Name the mainnet. Verify the address. Treat the amount as a request. ![Real Aperture Receive asset picker in the iOS Simulator with network filters, asset balances, and search](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/receive-crypto-safely/01-receive-asset-selection.webp) Fresh capture from Aperture 2.40.12 in the iOS Simulator. The article-only wallet is empty and every visible address is public test content for documentation—not a destination for deposits. Every app image below is a real Simulator capture; no funded wallet, recovery phrase, private key, signing, or broadcast was used. ## Receiving is a four-field agreement Before money moves, the receiver and sender should be able to say the same four things out loud: - Asset identity. ETH is not an ERC-20 token. USDC is not every token that happens to display “USDC.” A token’s network and contract or mint identity matter. - Blockchain network. Bitcoin, Linea, Ethereum, Base, Solana, and TRON are different ledgers. A familiar symbol does not make their deposit routes interchangeable. - Destination address. The complete public address—or the exact QR payload—must belong to the intended Aperture wallet on that network. - Requested amount. The amount is an instruction for the sender to review, not permission for a wallet to move funds automatically. Network fees are separate. If any one of these facts is missing, stop before the sender confirms. A QR code reduces typing, but it does not replace judgment. A matching address does not repair a wrong network. A correct network does not turn a look-alike token into the intended asset. ## Start with the asset—and keep the network visible Tap Receive from Wallet Home. Aperture opens a native, searchable asset list with a network selector above it. You can narrow the catalog to a mainnet first or search by asset name or symbol. Rows preserve the asset’s identity and, when relevant, its network context instead of asking you to choose from a ticker-only list. ![Real Aperture Receive search results in the iOS Simulator for USDC](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/receive-crypto-safely/02-search-usdc.webp) Real Simulator result for “USDC.” Search is useful, but a symbol is only the beginning of the identity check; the destination screen supplies the decisive mainnet label. The safest order is simple: decide what asset should arrive, decide which mainnet the sender can use, then open that exact receive destination. If a centralized exchange calls the network by a shortened or branded name, match the underlying chain—not the cheapest fee and not the logo color. When the withdrawal screen and Aperture do not name the same mainnet, do not continue until the difference is resolved. This is the same separation Aperture uses throughout the wallet. Read One Wallet, Many Mainnets: How Aperture Keeps Accounts and Networks Separate for the account model behind the labels. ## The network badge is a safety boundary, not decoration The receive card puts the network above the QR code and repeats it in the warning below the actions. In the real USDC example, Aperture says “On Linea Network” and then states that only USDC on Linea should be sent to the address. That repeated context is intentional: the symbol, network, QR, address, and warning can be reviewed in one screen. ![Real Aperture USDC receive card in the iOS Simulator labeled for Linea with QR code, public address, and network warning](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/receive-crypto-safely/03-usdc-linea-receive-card.webp) Real Aperture 2.40.12 output. The public address belongs to an empty article-only wallet. Do not send assets to addresses shown in documentation screenshots. Ethereum-compatible networks often derive the same hexadecimal account address from the same wallet key. That visual similarity is useful for account continuity, but it can be misleading during a transfer. A Linea transfer and an Ethereum transfer are recorded on different chains. The same-looking recipient does not make the asset available on both, and a token contract valid on one chain does not automatically identify the corresponding token on another. For an EVM native coin, Aperture’s QR payload includes the destination and the selected chain ID. For a catalog token, it includes the token contract, chain ID, and recipient in the standard transfer form. The on-screen address stays human-readable while the QR can carry the richer network-qualified instruction. ## A receiving address is public—but precision still matters The address on Receive is designed to be shared. It is not a recovery phrase, private key, passcode, or signing credential. Sharing a public receive address lets someone construct a transaction to the wallet; it does not let them spend from it. Public does not mean approximate. Cryptocurrency addresses are exact identifiers. One changed character can point somewhere else or fail validation. Aperture renders the complete address under the QR, allows it to wrap without inserting visual hyphens, and keeps the text selectable. Copy writes the address itself to the clipboard; the button changes to a clear confirmation so you know the action completed. ![Real Aperture USDC receive card in the iOS Simulator confirming the address was copied to the clipboard](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/receive-crypto-safely/04-copy-address-confirmation.webp) Real copy confirmation in the Simulator. For a high-value transfer, compare the beginning and end of the pasted address again on the sender’s review screen; clipboard replacement malware exists outside the wallet’s control. When possible, verify the destination through a second trusted channel: compare a few characters during a call, use a previously verified contact, or scan the QR directly from the receiver’s device. Never “fix” an address by hand. If the sender reports an invalid format, return to Aperture and reopen the correct asset and network rather than editing the string. ## What Aperture actually places in the QR code A QR code is a transport for text. Aperture generates the bitmap locally from a network-aware payload, while keeping the exact destination printed beneath it. The payload differs because blockchains use different payment-request conventions: - EVM native coins. The payload uses an Ethereum payment URI containing the account address and the selected chain ID. No amount is appended by the current Receive screen. - EVM tokens. The payload identifies the token contract and chain ID, invokes the standard transfer form, and supplies the receiving address. No token amount is appended by the current Receive screen. - Conventional Bitcoin. The payload is a BIP21-style bitcoin URI containing the fresh receive address. Silent Payments use a Bitcoin URI with the reusable Silent Payment address in its dedicated parameter. - Solana in the current Receive flow. The QR contains the selected Solana account address. The visible network label and asset selection remain essential context. - Other independent account families. Aperture derives and validates the account for that blockchain, then uses the chain’s supported explicit scheme or direct address representation. Token identity is added where the supported request format permits it. These details explain why the human-readable screen still matters. A camera can decode a syntactically valid request that belongs to the wrong person or wrong network. Before the sender continues, their wallet should show the same recipient, mainnet, asset, and any requested amount in its own review interface. ## Share the address—or share a branded QR card Aperture keeps two sharing modes separate. Share Address hands the native share sheet the plain public address. Share QR Code first renders a shareable Aperture card containing the QR, asset, network, tagline, and readable destination, then passes that image to the native share sheet. If QR rendering fails, the action safely falls back to sharing the address instead of inventing a broken image. ![Real Aperture receive sharing menu in the iOS Simulator offering Share Address and Share QR Code](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/receive-crypto-safely/05-share-address-or-qr.webp) Real in-app sharing choice. The system share sheet was not captured so no contacts or personal suggestions appear in this article. Use the plain address when the sender will paste it into a wallet and compare it. Use the QR card when the sender can scan from another device or when the visible network context should travel with the image. In either case, use a communication channel you already trust. A screenshot forwarded by an unknown account is not authenticated simply because it looks polished. ## Requested amounts are requests—not authorizations Aperture 2.40.12 does not add an amount to the QR generated by Receive. The current card describes the destination—plus richer asset and chain context where the URI standard supports it—but leaves the amount blank. The sender chooses the amount in Send and reviews it before authorization. That is an important distinction. A payment request can prefill a number; it cannot sign a transaction, pay a fee, or spend from the sender’s wallet. Aperture’s Send parser understands amount-bearing forms from supported request standards, including Bitcoin’s decimal amount, Solana Pay’s user-unit amount, and the atomic-unit value fields used by EVM native and token requests. It validates formats, precision, duplicate parameters, supported networks, and token identity before presenting a request. But the sender still owns the final decision. - Communicate the unit. Say “0.01 ETH,” not just “0.01,” and avoid mixing an asset amount with a local-currency quote. - Keep fees separate. A request for 0.01 ETH does not mean the sender’s total cost is exactly 0.01 ETH; the sending network may require a separate fee. - Do not hand-edit payment URIs casually. Different networks express amounts in user units or atomic units. A misplaced scale can change the number by many orders of magnitude. - Review after scanning. The sender should compare the wallet’s decoded asset, network, recipient, and amount before continuing. Scanning is input, not consent. For the sender-side path from recipient entry through review and confirmation, read Send Crypto Without Guesswork: From Recipient to Finality. For the difference between the transfer amount and network cost, read Where Crypto Network Fees Actually Go. ## Bitcoin receive addresses are intentionally fresh Bitcoin does not use the single static-account model common to EVM networks. For an HD wallet, Aperture prepares a fresh unused Bitcoin receiving address for the selected standard and displays it in a Bitcoin payment URI. The menu supports BIP86 Taproot, BIP84 Native SegWit, BIP49 Nested SegWit, BIP44 Legacy, and Silent Payments where the wallet supports them. ![Real Aperture Bitcoin receive card in the iOS Simulator with a fresh Native SegWit address and Bitcoin QR code](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/receive-crypto-safely/06-bitcoin-fresh-receive-card.webp) Real Aperture 2.40.12 Simulator capture using BIP84 Native SegWit. The address is public and belongs to the empty article-only wallet; it is not a deposit destination. A fresh address improves on-chain privacy because unrelated incoming payments are less easily clustered through one reused destination. Aperture monitors the wallet’s derived address range so funds sent to the displayed address still belong to the same wallet. Read Why Bitcoin Wallets Generate Fresh Receiving Addresses for the HD discovery model, or Silent Payments in Aperture: A Reusable Bitcoin Address Without Address Reuse for the privacy-preserving reusable alternative. ## Solana has its own account identity Aperture does not recycle a generic EVM address for Solana. It derives and validates Solana account identities through the chain’s canonical address rules. Because Solana wallets in the ecosystem commonly use more than one derivation convention, Aperture can expose the compatible Phantom and Trust Wallet paths when both accounts are available. Choose the path that matches the wallet identity the sender expects. ![Real Aperture Solana receive card in the iOS Simulator with the independent Solana address, QR code, and network warning](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/receive-crypto-safely/07-solana-receive-card.webp) Real Solana receive screen from the same empty Simulator wallet. The QR and visible address represent the selected Solana account; neither exposes the private key. The same principle extends to other non-EVM chains: the wallet must derive a real account for that blockchain, validate its address format, and show the correct network context. A hexadecimal EVM address is never a universal fallback for an unrelated chain. ## Never infer an asset from the address alone An address answers “where.” It may not fully answer “what.” One EVM account can receive a native coin and many token contracts on the same chain. The same symbol can also appear on multiple chains, and malicious or unrelated tokens can copy a familiar name. Aperture’s catalog resolves token identity through blockchain plus normalized contract or mint address rather than ticker text alone. That is why the safe instruction is not “send USDC to this 0x address.” It is “send the catalog USDC asset on Linea to the address shown on the Linea receive card.” The extra words close the ambiguity that a bare address leaves open. ## A safe first-transfer rehearsal - Open Receive from the intended wallet. If you manage several wallets, confirm the selected wallet name first. - Choose the exact asset and mainnet. Use search and the network selector; do not choose by symbol alone. - Read the network badge and warning. Make the sender’s withdrawal network match the full chain identity. - Copy or scan the destination. Avoid manual transcription and never edit the address to make another app accept it. - Compare the decoded request. On the sending device, recheck asset, network, recipient, and any requested amount. - Send a small test when the route is new. Wait until Aperture shows the incoming transfer with the expected network and asset before moving the remainder. - Record the final transaction hash. The hash is the durable reference for checking mainnet status; a screenshot of a “sent” message is not finality. - Reopen Receive for a later payment. This is especially important for Bitcoin, where a fresh address may now be displayed. A test transfer is not magic—it still needs the same four checks—but it limits the consequence of a misunderstood network, token identity, or exchange label. It is often the cheapest useful insurance for a new route. ## After the sender broadcasts Sharing a receive card does not create a pending transaction on-chain. Activity begins only after the sender’s wallet signs and broadcasts a valid transaction. Aperture then discovers it through the selected wallet’s mainnet synchronization and follows the network-specific confirmation lifecycle. Do not treat a chat receipt, exchange email, or copied hash as proof of spendable funds. Match the transaction hash, destination, network, asset, amount, and status in a trusted wallet or explorer view. Confirmation times vary with the chain and current conditions. If a sender paid too little in network fees, the transaction may remain pending; if they selected another chain, waiting longer will not move it to the intended ledger. ## Mistakes a self-custody wallet cannot reverse - Wrong recipient. A confirmed blockchain transfer generally cannot be recalled by Aperture. The wallet does not control the destination key. - Wrong network. The transfer exists on the network the sender used. It does not automatically migrate to the network the receiver intended. - Wrong token contract or mint. A familiar name is not proof of the intended asset. Recovery depends on what was actually transferred and whether the destination account can control it. - Missing exchange memo or tag. When sending to a custodial deposit address, follow that provider’s exact memo or destination-tag instructions. Aperture’s own self-custody receive address should be used exactly as its screen presents it. - Amount misunderstanding. The chain records the amount expressed in the signed transaction, not the amount discussed in a message. ## Questions before you receive Is it safe to share my Aperture receive address? Yes. The receive address is public and cannot authorize spending. Never share a recovery phrase, private key, passcode, or backup secret as part of a receiving request. Does scanning the QR automatically send money? No. A compatible sender wallet decodes the request and should present a review flow. Signing and broadcast require the sender’s explicit authorization. Why can the same 0x address appear on several EVM networks? Supported EVM chains can share one derived account identity, but their ledgers and token contracts remain separate. Always match the chain ID and asset identity. Does the current Receive QR include an amount? No. Aperture 2.40.12 generates amount-free receive requests. Communicate the amount and unit separately, then have the sender enter and review it. Can I reuse the Bitcoin address in the screenshot? Do not send to documentation addresses. In your own wallet, reopen Receive and use the fresh address Aperture currently displays. Why has the payment not appeared yet? Confirm that the sender actually broadcast it, verify the hash and destination, check the exact mainnet, and wait for that network’s confirmation process. A transfer on another chain will not arrive by waiting. ## Make the request unambiguous before the chain makes it final Safe receiving is not about memorizing address formats. It is about keeping context attached to the destination. Aperture starts with a real asset and mainnet selection, presents the network beside the QR, keeps the exact public address visible, validates chain-specific account identities, and lets you share either the address or a branded QR card. The final responsibility remains human and shared: the receiver must request the correct route, and the sender must review what their wallet decoded before signing. When asset, network, destination, and amount all agree, the QR code becomes what it should be—a convenient carrier of precise instructions, not a substitute for them. > Share the context. Verify the destination. Let the sender authorize the amount. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # Find Anything in Your Wallet: Aperture Universal Search - Canonical URL: https://aperturex.io/articles/find-anything-wallet-aperture-universal-search/ - Category: Product - Author: Aperture Editorial - Published: 2026-08-31T00:08:06+00:00 - Updated: 2026-08-31T00:08:08+00:00 - Reading time: 13 minutes - Topics: Aperture, Universal Search, Wallet UX, Privacy, GRDB, Self-Custody Search wallet actions, settings, managed wallets, mainnets, assets, prices, and selected-wallet activity from one local field—then jump directly to the result. ![Independent editorial sculpture of one blue query rail selecting six ranked wallet records from a precise graphite local index](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/universal-search/aperture-universal-search-cover.webp) A wallet starts small: one balance, a few assets, two obvious buttons. Then it grows. More networks arrive. Token names repeat across chains. Transaction history becomes a stream of hashes, counterparties, methods, notes, and statuses. Settings collect in their own hierarchy. A second wallet appears. The thing you remember is no longer where an item lives—it is what the item is called. Aperture Universal Search turns that memory into navigation. One native search field on Wallet Home looks across actions, settings, managed wallets, supported mainnets, assets, available prices, and the selected wallet’s transaction history. Results are grouped by meaning, ranked locally, and wired to the real destination. Search for a task and perform it. Search for an asset and open it. Search for a network and see its assets. Search for a transaction clue and inspect the matching activity. > You remember the intent. Aperture finds the route. ![Real Aperture Universal Search start screen in the iOS Simulator showing Send, Receive, Scan QR, and Assets suggestions](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/universal-search/aperture-universal-search-suggestions.webp) Fresh capture from Aperture 2.40.12 in the iOS Simulator. The empty article-only wallet shows real start suggestions—Send, Receive, Scan QR, and Assets. Every app image in this article is a real Simulator capture containing public data only; no secret, funded wallet, fabricated transaction, signing, or broadcast was used. ## “Universal” means one query, several kinds of answer Most wallet search boxes answer one narrow question: which token matches this text? Aperture treats search as a cross-product command surface. The same query can produce several independently labeled sections: - Wallet actions and settings. Send, Receive, Scan QR, Assets, Manage Assets, Activity, Wallets, Security, Appearance, Language, Currency, Notifications, About, Privacy, Terms, Reset, and related settings entries. - Wallet management. Every active managed wallet can be found by name, public wallet address, or wallet type, with the current wallet identified separately from a wallet you can switch to. - Blockchain networks. All supported mainnets are indexed by display name, internal identity, blockchain family, and useful network aliases. - Assets and market prices. Native coins and tokens can match by name, symbol, qualified network identity, contract address, and available numeric balance, fiat-value, or unit-price data. - Complete transaction history. Eligible activity in the selected wallet can match hashes, addresses, direction, status, methods, display details, asset identity, network identity, time text, and your local transaction note. The sections matter. A query like “security” can legitimately describe a Settings destination and an asset name. Aperture does not flatten them into an ambiguous list; it labels their domains so you can choose with context. ## Open search and the useful defaults are already there On iPhone, the native search control lives in the bottom toolbar. On iPad, the same search affordance moves to the top trailing toolbar position. Before you type, Aperture presents four high-frequency routes in a native list: Send, Receive, Scan QR, and Assets. If the portfolio contains funded assets, up to four of those assets can appear as suggestions too. This blank-query state is intentional. Search is still useful when the exact wording has not arrived yet. It gives the thumb a short path to the next action without adding a second custom dashboard or a parallel navigation system. ![Real Aperture Universal Search results in the iOS Simulator for Receive, including the Receive action and related settings](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/universal-search/aperture-universal-search-receive-results.webp) Real Simulator output for “Receive.” The exact Receive action ranks first. Related settings whose explanatory text contains the same intent follow in the same clearly labeled section. ## The search request stays on the device Universal Search does not send the typed query to an Aperture search server. When the field opens, the app builds an in-memory index from the wallet content already available to the Home presentation: actions, localized settings copy, managed wallet metadata, supported network metadata, and the wallet’s searchable asset catalog. Transaction matching runs against the centralized on-device GRDB WalletDatabase. That distinction is precise: prices, balances, assets, and blockchain history may have been synchronized from their normal providers before you search, but the act of typing and matching the query is local. There is no remote “universal search” endpoint receiving each character. Closing search clears the query from the Home view. The search index is also demand-driven. Aperture does not keep rebuilding it while the search interface is closed. Presenting search activates observation of the current asset IDs, managed wallets, and reusable USD prices; changes to wallet content, wallet metadata, prices, the selected wallet, or the app language produce a new revision. Dismissing search stops that work. ## Fast local matches and deep history run together Each non-empty query launches two bounded jobs in parallel: - The in-memory index ranks actions, settings, wallets, networks, and assets. This keeps the interface responsive and avoids touching the transaction database for everything. - The transaction index uses SQLite FTS5 inside WalletDatabase to retrieve matching activity from enabled accounts belonging to the selected wallet. The UI waits for a coherent result set, then presents the categories together. If transaction-history lookup fails, Aperture keeps the other local results and shows a specific history-unavailable message instead of replacing the whole search with a generic connectivity error. If the index is still being prepared, the screen uses a localized static state rather than a spinner or fabricated placeholder rows. ## Ranking favors what you probably meant Search text is trimmed, case-folded, and normalized. Exact titles rank first. A title beginning with the query ranks next, then a complete title word, followed by matches across the item’s broader searchable copy. In a multi-term query, every term must be represented by a whole word, a word prefix, or contained text. Ties fall back to title order for deterministic results. This is deliberate lexical search, not a cloud language model guessing intent. Prefixes work well—“Bitco” can match Bitcoin—and accents are folded for transaction search, but an unrelated typo is not promised to be corrected. The result is predictable: the same local data and query produce the same ordering. Result sets are bounded too: up to 20 actions, 20 wallets, every supported network match, 60 asset matches, and 100 display-eligible transactions. Transaction candidate retrieval is capped before the app applies its normal visibility policy. Large catalogs remain searchable without turning one query into an unbounded scan. ## A network name can reveal both the chain and its assets Search for Bitcoin and Aperture does not pretend every matching object is the same Bitcoin. In the real app, the query returns Bitcoin and Bitcoin Cash as blockchain networks, the native BTC asset on Bitcoin, and assets named Bitcoin on other chains. Each asset row carries its symbol and network; each logo is resolved from the official network artwork or identity-qualified asset catalog. ![Real Aperture Universal Search results in the iOS Simulator for Bitcoin across blockchain networks, assets, and market prices](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/universal-search/aperture-universal-search-bitcoin-results.webp) Fresh Aperture 2.40.12 Simulator capture. The article-only wallet returns two mainnet records plus identity-qualified Bitcoin assets. The visible JOD value is a real available market-price presentation at capture time, not an invented balance. This identity model prevents a dangerous shortcut: a ticker or display name alone is not enough to choose a token. Aperture’s asset search is backed by blockchain plus normalized contract identity where a contract exists. A query can therefore include a symbol and network—such as “USDT Ethereum”—or an exact contract address to narrow the result. A hidden Home asset is still discoverable in search. Finding or opening it does not silently change its visibility preference. Search answers “does this wallet know this asset?” while the Home setting independently answers “should this asset appear in the primary portfolio list?” ## Network results are navigation, not decoration Every supported network is indexed with its localized name, stable network ID, blockchain family, and aliases. Selecting a network result closes search and opens the complete asset list already filtered to that mainnet. There is no testnet switch hiding behind the result: Aperture’s supported wallet surface is mainnet-only. That direct route is useful when one symbol spans many chains. Search can first identify the network, then place you in a list where every remaining asset shares that network context. Read One Wallet, Many Mainnets: How Aperture Keeps Accounts and Networks Separate for the account and address boundaries behind those labels. ## Wallet names, public addresses, and mainnet aliases share one field Managed wallets are indexed by name, public address, and wallet kind: created, recovery-phrase import, private-key import, watch-only, or hardware-backed where supported. The result row distinguishes the active wallet from one that can be made active, and selecting another wallet closes search before Aperture updates the selected wallet and reloads its presentation. ![Real Aperture Universal Search results in the iOS Simulator for Main, showing the active wallet, mainnet networks, and assets](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/universal-search/aperture-universal-search-wallet-results.webp) Real Simulator output for “Main.” It finds the active Main Wallet and networks whose aliases identify them as mainnets, then shows matching assets below. The wallet is empty and the displayed JOD 0.00 is real. Wallet-address matching is useful when the recognizable part of a wallet is its public identity rather than its nickname. It does not expose recovery phrases or private keys because those secrets are not members of the search documents or the WalletDatabase. ## Settings become destinations you can name Deep settings are often remembered semantically: “Face ID,” “auto lock,” “language,” “notifications,” or “privacy screen.” Universal Search indexes both the localized setting title and its explanatory subtitle. Searching the thing you want can therefore find the screen even when the navigation hierarchy is not in memory. ![Real Aperture Universal Search results in the iOS Simulator for Security across settings and an identity-qualified asset](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/universal-search/aperture-universal-search-security-results.webp) Real Simulator output for “Security.” The Security destination and Settings route are grouped above a Base asset whose real name also matches. The categories make the difference explicit. Selecting a settings result dismisses search and presents the existing Settings flow at the dedicated route. Search does not reproduce the setting inline, bypass its normal screen, or add a new authentication gate. The destination keeps its own lifecycle, controls, platform protections, and navigation behavior. ![Real Aperture Security settings destination opened from Universal Search in the iOS Simulator](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/universal-search/aperture-universal-search-security-destination.webp) Real Aperture 2.40.12 Simulator capture after selecting Security from the search results. No setting was changed for this article. ## Transaction search is broad—but deliberately not raw Aperture maintains a dedicated FTS5 table for transaction discovery. Database triggers insert, update, or remove its search document when a transaction changes. Asset-identity, network-identity, and local-note updates refresh the affected records so search does not rely on a stale exported cache. The searchable transaction document can include: - transaction hash, scoped to enabled accounts in the selected wallet; - from, to, and counterparty addresses; - asset name, symbol, contract address, and network identity; - incoming or outgoing direction, transaction kind, and current status; - decoded method name, user-facing detail, display time, and your local transaction note. Raw calldata is intentionally not indexed. A test in Aperture’s production suite seeds a marker inside transaction calldata and verifies that Universal Search cannot retrieve it, while the transaction hash, counterparty, local note, and “Polygon POL” identity remain searchable. This keeps search focused on useful user-facing fields instead of turning opaque payload bytes into an accidental discovery surface. History results are also scoped and filtered. Only enabled accounts belonging to the currently selected, non-archived wallet enter the query. Retrieved records must still pass Aperture’s transaction display-eligibility and visibility policies before they become rows. Search cannot resurrect activity the wallet intentionally excludes from every other screen. Selecting a transaction opens the standard transaction-details screen. For the lifecycle behind those statuses, see Send Crypto Without Guesswork: From Recipient to Finality; for the cost fields you may encounter, see Where Crypto Network Fees Actually Go. ## Search understands qualified assets and numeric clues Asset lookup reuses Aperture’s discovery index instead of inventing a second ticker-only catalog. It can match names, symbols, network-qualified phrases, normalized contract addresses, and the network metadata already used throughout Send, Receive, and asset management. It also merges matches against available balance, fiat-value, and unit-price decimal text. Numeric matching is a convenience, not an accounting query language. A displayed value may be converted into the user’s selected currency while underlying reusable price data is maintained in USD and stored losslessly as decimal text. Search is best used with a name, symbol, network, or contract when certainty matters. Aperture’s Currency Converter remains the purpose-built tool for comparing amounts across units. ## Localization changes the index, not just the labels Actions and settings are indexed from the current localized title and subtitle. The app language identifier is part of the index preparation request, so changing language causes the search documents to rebuild rather than leaving English-only keywords behind a translated interface. Network rows use localized display names, while symbols, contracts, public addresses, and useful technical aliases remain available as identity terms. The interface uses native SwiftUI List and Section behavior, including Dynamic Type, platform row selection, VoiceOver grouping, and locale-driven layout direction. On iPad the toolbar placement adapts; on iPhone it remains thumb-reachable. If Reduce Motion is enabled, Aperture removes the smooth in-place presentation transition rather than forcing movement. ## No match is a complete answer too When no domain matches every query term and activity search completed successfully, Aperture presents a clear native empty state. It does not fill the screen with approximate tokens, web results, sponsored results, testnets, or an AI guess. ![Real Aperture Universal Search no-results state in the iOS Simulator for an unmatched two-term query](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/universal-search/aperture-universal-search-no-results.webp) Real Simulator output for the unmatched query “tangerine orbit.” Aperture returns “No Matching Results” because neither term belongs to the local wallet index. Try a shorter prefix, remove an over-specific term, qualify an asset with its network, or paste the exact public address, contract, or transaction hash. If the item is blockchain activity, confirm that it belongs to the currently selected wallet and has already been synchronized into its eligible history. ## What Universal Search does not do - It is not a blockchain explorer. It searches locally known wallet content, not every transaction, address, or token on the internet. - It is not fuzzy semantic AI. Exact, prefix, normalized-term, alias, identity, and numeric matching are predictable; arbitrary misspellings are not promised. - It does not cross selected-wallet activity boundaries. Wallet management can find another wallet, but transaction history remains scoped to the wallet currently active when the query runs. - It does not expose secrets. Recovery phrases and private keys never enter the search documents or WalletDatabase. - It does not mutate a result merely by finding it. A hidden asset stays hidden, a setting stays unchanged, and a different wallet stays inactive until you select the corresponding row. ## Queries worth remembering - An action: Send, Receive, Scan QR, Assets, Manage Assets, or Transaction History. - A setting: Face ID, Auto Lock, Privacy, Language, Currency, Notifications, Terms, or Reset. - An asset identity: Bitcoin, USDT Ethereum, a token contract address, or a native symbol plus its network. - A network: Bitcoin Cash, Base, Polygon, Solana, or another supported mainnet alias. - A wallet: Its nickname, public address, or wallet kind. - An activity clue: A transaction hash, counterparty address, asset, decoded method, status, direction, or memorable local note. ## Questions before you rely on Search Does Aperture upload my query? No Universal Search request is sent to a remote search endpoint. Matching runs against the in-memory index and the on-device WalletDatabase. Normal wallet synchronization is separate. Why did an asset appear even though it is hidden on Home? Search and Home visibility answer different questions. Finding the asset does not change its visibility preference. Why does one word appear in several sections? The same term can name a setting, network, wallet, or asset. Grouped domains preserve context instead of arbitrarily discarding valid matches. Can I search another wallet’s transactions? Make that wallet active first. Managed-wallet results span available wallets, while activity lookup is intentionally scoped to enabled accounts in the selected wallet. Can I find a transaction by my note? Yes. Local transaction notes update the FTS search document. Raw calldata remains excluded. Why is a newly seen transaction missing? Universal Search can only retrieve eligible activity already synchronized into WalletDatabase. Let wallet synchronization complete, verify the active wallet and network, then search again. ## The shortest path starts with the word you already know Universal Search makes a large self-custody wallet feel smaller without hiding its structure. Networks remain networks. Assets remain identity-qualified assets. Wallets remain separate ownership scopes. Transactions remain selected-wallet records. Settings keep their own screens. Search simply builds one local, ranked map across them. That map is fast because it is bounded, private because the query stays local, useful because results are real destinations, and honest because an unmatched query stays unmatched. When the wallet grows beyond what you can keep in your head, the path forward is still one field away. > Search by intent. Confirm the category. Open the real destination. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # Silent Payments in Aperture: A Reusable Bitcoin Address Without Address Reuse - Canonical URL: https://aperturex.io/articles/silent-payments-aperture-reusable-bitcoin-address-without-reuse/ - Category: Security - Author: Aperture Editorial - Published: 2026-08-30T23:55:17+00:00 - Updated: 2026-08-30T23:57:45+00:00 - Reading time: 14 minutes - Topics: Bitcoin, Silent Payments, BIP352, Privacy, Taproot, Self-Custody Publish one reusable Bitcoin payment instruction while compatible senders create a different Taproot output every time. See how Aperture derives, scans, verifies, recovers, and spends Silent Payments—and where the privacy tradeoffs remain. ![Independent editorial sculpture of one reusable two-part receiver gateway transforming three separate sender inputs into three unique Bitcoin output tiles](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/silent-payments/silent-payments-reusable-address-cover.webp) A normal Bitcoin address can be copied forever, but reusing it creates a permanent public join: every direct payment to that script is trivially grouped. Generating a fresh address for every payer avoids the join, yet it is awkward for a profile, donation page, printed card, or contact who may pay you later. Silent Payments solve that tension with a surprising distinction: reuse the payment instruction, never the on-chain destination. Aperture lets an eligible recovery-phrase wallet publish one reusable mainnet instruction beginning with sp1. A compatible sender combines that instruction with the final transaction inputs to create a new Taproot output that has never appeared before. The next compatible payment creates another output. The reusable string stays the same; the output script does not. > One public instruction. A different Taproot output for every payment. No repeated receive address on-chain. ![Real Aperture Bitcoin address type menu in the iOS Simulator with Silent Payments selected above BIP86, BIP84, BIP49, and BIP44](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/silent-payments/aperture-silent-payments-types-selected.webp) Fresh capture from Aperture 2.40.12 in the iOS Simulator. Silent Payments is selected in an empty article-only wallet; the other receive formats remain available. Every app image in this article is a real Simulator capture containing public data only—no secrets, funds, signing, or transaction broadcast. ## The address you share is not the output the blockchain sees The phrase “reusable address” can sound like conventional address reuse, so precision matters. A version-zero Silent Payment address is a Bech32m-encoded payment instruction. On Bitcoin mainnet its human-readable prefix is sp, and its payload contains two compressed public keys: a scan public key and a spend public key. It is not a P2PKH, P2WPKH, or P2TR output script waiting to be copied into every transaction. Instead, a supporting sender uses those public keys and information from its own final inputs to derive a unique x-only public key. The transaction pays a standard Taproot P2TR output built from that unique key. An observer sees an ordinary-looking Taproot output, not the published sp1 instruction and not a reusable script. This is the central privacy win: two people can pay the same published instruction without creating two outputs to the same address. Their outputs are different, and the blockchain contains no direct reference to the reusable instruction that connects them. ![Real Aperture Receive BTC screen in the iOS Simulator showing a reusable mainnet Silent Payment address beginning with sp1](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/silent-payments/aperture-silent-payment-receive.webp) Real Aperture 2.40.12 Simulator output. The QR and sp1 string are the reusable BIP352 payment instruction for this empty article-only wallet. The instruction is public; the scan and spend private keys are not shown. ## What happens when a compatible sender pays Silent Payments are interactive cryptography without an interactive conversation. The receiver publishes the instruction once. The sender can then construct a payment asynchronously, but it must do so only after its final transaction inputs are known. In simplified form: - Decode and validate the instruction. The sender reads the version-zero scan and spend public keys from the mainnet sp1 address. Aperture rejects unsupported testnet encodings and malformed payloads. - Finish coin selection. Eligible Bitcoin inputs are selected first. Their public keys and the lexicographically smallest input outpoint become part of the derivation context. - Create a shared secret. The sender combines its input-key material with the receiver’s scan public key. Elliptic-curve Diffie–Hellman lets the receiver reproduce the same secret with the scan private key, without anyone revealing a private key. - Derive a payment-specific tweak. BIP352 tagged hashes bind the shared secret to the transaction and output position. The tweak is added to the receiver’s spend public key. - Create the unique output. The tweaked x-only key becomes a Taproot output script. This script is the actual destination recorded in the transaction. If coin selection changes, the sender must derive the Silent Payment outputs again. Adding or removing an input changes the shared input context and therefore changes the destination key. Aperture’s sender path performs Silent Payment derivation after final input selection and includes the exact 34-byte Taproot output in fee estimation and signing review. That final-input rule is why an app cannot safely precompute a Silent Payment output too early, then casually add another UTXO without recalculating. The recipient instruction stays valid; the transaction-specific output must match the transaction actually signed. ## Two receiver keys separate finding money from spending it Aperture derives the BIP352 account at account index zero for recovery-phrase Bitcoin wallets. The two private branches have different jobs: - Scan key — m/352'/0'/0'/1'/0. This viewing key helps recognize candidate outputs and reconstruct the same payment tweak the sender created. It cannot authorize spending by itself. - Spend key — m/352'/0'/0'/0'/0. This key combines with each verified tweak to produce the one-time private output key that can spend the matching Taproot output. The reusable address publishes only the two public keys. Aperture keeps both private keys in its this-device-only Keychain vault. The wallet database stores public account material, the reusable address, scan heights, discovered output metadata, and opaque Keychain references—not the recovery phrase, the base private keys, or a one-time output private key. ![Real Aperture Bitcoin Settings screen in the iOS Simulator showing conventional address accounts and a selected Silent Payments account in one wallet](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/silent-payments/aperture-silent-payments-bitcoin-settings.webp) Real Simulator capture from Bitcoin Settings. The same wallet contains its conventional BIP44, BIP49, BIP84, and BIP86 accounts plus Silent Payments. Values shown are zero; the selected receive mode is Silent Payments. ## The QR follows BIP321, not a private Aperture format When Silent Payments is selected, Aperture saves that receive preference and displays the locally prepared instruction immediately. Its QR payload uses the Bitcoin payment URI form bitcoin:?sp=
, as defined by BIP321. That lets a supporting wallet recognize the sp parameter as a Silent Payment destination. A BIP321 request can also carry an ordinary Bitcoin address as a fallback. When a sender understands Silent Payments, it can prefer the sp instruction; an older sender can use the conventional fallback if one was provided. A bare sp1 string still requires explicit BIP352 support. Switching back to BIP86, BIP84, BIP49, or BIP44 clears the Silent Payments receive preference and publishes that account’s current fresh conventional child instead. It does not delete the Silent Payment account or make previously received outputs disappear. ## Finding an output requires scanning, not address lookup A conventional wallet can ask an indexer for activity on known scripts. A Silent Payment receiver does not know the final output scripts until it combines transaction input data with its scan key. The cost of eliminating the public notification is therefore scanning work. Aperture’s current mainnet discovery path uses a TLS-protected BIP352 scan service. Before sending a request, the app verifies that the service reports the Bitcoin genesis hash and Silent Payments version zero. It provides the scan private key, spend public key, and a bounded starting height so the service can filter candidate transactions. This is an important privacy tradeoff: the scan service gains viewing capability for Silent Payment activity, but it does not receive the spend private key and cannot spend the funds. Aperture does not accept a server candidate as money on trust. For each candidate it: - downloads the raw mainnet transaction through the same verified session; - parses the transaction locally and recomputes its transaction ID; - recomputes the BIP352 input hash, shared secret, tagged tweak, and expected Taproot script; - accepts only an exact script match at the reported output index; and - stores the exact decimal-text value, script, block metadata, and an opaque Keychain reference to the one-time output key. This division is deliberate. The service can help narrow the search, but it cannot invent a spendable balance by returning a false candidate: local cryptographic verification must reproduce the output. It also cannot sign because it lacks the spend key. Nevertheless, anyone choosing Silent Payments should understand that the current discovery service can observe the activity it scans. ![Real Aperture Silent Payments account screen in the iOS Simulator showing its reusable payment instruction and beginning statistics](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/silent-payments/aperture-silent-payments-account.webp) Real Aperture 2.40.12 Simulator capture. The dedicated account view exposes the reusable public instruction and wallet-owned scan status without revealing either private branch. ## Incremental discovery, live updates, and reorg safety The first recovery scan begins from a safe historical floor rather than Bitcoin block zero. Aperture currently uses block 709,632—the Taproot activation height—as the mainnet starting point for this account, unless a configured birth height narrows the range. Subsequent scans resume near the last verified height while overlapping the prior 100 blocks so a short reorganization can be reconciled. A live scan subscription can trigger discovery again when a relevant mempool or block candidate appears. Once outputs are known, Aperture monitors their script hashes through its Bitcoin synchronization path, reconciles confirmations, detects spends, and removes orphaned state after a reorg. An unconfirmed verified Silent Payment can enter the spendable UTXO set; confirmation count still affects its status and ordering. ![Real Aperture Silent Payments statistics in the iOS Simulator showing discovered outputs and the mainnet scan-height range for an empty wallet](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/silent-payments/aperture-silent-payments-scan-statistics.webp) Fresh Simulator capture from the empty article-only wallet. It has zero discovered, unspent, and spent outputs. The visible scan range begins at block 709,632 and reached block 964,805 when captured; these are real runtime values, not a mockup. ## Received outputs join the same Bitcoin balance A Silent Payment does not create a separate kind of bitcoin. After an output is discovered and verified, Aperture represents it as a normal mainnet Taproot UTXO inside the same Bitcoin balance alongside outputs received through BIP44, BIP49, BIP84, and BIP86. Bitcoin Settings can show separate account details, but portfolio ownership remains unified. For spending, Aperture retrieves the one-time output key through its opaque Keychain reference and proves that the key’s x-only public key matches the Taproot output script before signing. That output can then participate in ordinary coin selection. The sender does not need the original reusable instruction again, and the user does not have to “convert” the received funds. Silent Payments do not remove miner fees. The outgoing transaction still occupies block space, and its fee is still the chosen satoshi-per-vbyte rate multiplied by actual virtual size. Receiving to a Silent Payment produces a 34-byte Taproot output script; spending it uses the Taproot key-path shape. Read Where Crypto Network Fees Actually Go for fee mechanics and Send Crypto Without Guesswork: From Recipient to Finality for Aperture’s transaction review path. ## Silent Payments and fresh BIP84 addresses solve different moments A fresh conventional address is still the simplest receive method when you can generate a new request for each payment and the sender may not support BIP352. Aperture defaults conventional receiving to BIP84 Native SegWit, whose addresses begin with bc1q. The wallet advances through its external address chain as use is discovered. ![Real Aperture Receive BTC screen in the iOS Simulator showing a conventional fresh BIP84 address for comparison with Silent Payments](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/silent-payments/aperture-bip84-fresh-address-comparison.webp) Real Aperture 2.40.12 Simulator capture from the same empty article-only wallet after returning to BIP84. The bc1q address is one conventional child destination; a later payment can use another child. - Use a fresh conventional address for an invoice, exchange withdrawal, or sender that does not explicitly support Silent Payments. - Use a Silent Payment instruction where one stable public contact point is valuable and the sender supports BIP352. - Do not confuse Silent Payments with reusing a bc1 address. Repeated conventional-address payments repeat a visible output script; compatible Silent Payments derive a different script each time. For a deeper look at conventional HD receive and change chains, read Why Bitcoin Wallets Generate Fresh Receiving Addresses. ## Compatibility: who can receive and who can send Silent Payments require wallet support on the sending side. A legacy wallet, exchange withdrawal form, or payment processor that validates only conventional addresses may reject an sp1 string or fail to construct the required output. Aperture keeps all conventional formats available for exactly this reason. - Receiving in Aperture. The reusable BIP352 account is derived for Bitcoin wallets created from, or restored by, a recovery phrase. That full deterministic scope is necessary to reconstruct the scan and spend branches. - Sending from an Aperture recovery-phrase wallet. Aperture can build a version-zero mainnet Silent Payment output after final Bitcoin coin selection. - Sending from a supported imported single-key wallet. An eligible WIF wallet can pay an sp1 recipient because sender derivation can use the selected input key. The WIF import does not gain its own reusable receiver account. - Version handling. Aperture constructs version-zero payments. It can read forward-compatible versions 1 through 30 when the first 66 payload bytes provide the expected public keys, while version 31, malformed payloads, and testnet human-readable prefixes are rejected. Before sending, confirm that both the source wallet and recipient instruction are on Bitcoin mainnet. If support is uncertain, ask the recipient for a conventional BIP84 or another mutually supported address and start with a small test payment. ## Recovery reconstructs keys, then rediscovers outputs Aperture can regenerate the same BIP352 scan and spend account from the same recovery phrase at account zero. Recovery is not an instant database snapshot: after deriving the keys, the wallet must scan from its historical floor or configured birth height, verify matching transactions, rebuild one-time output keys, and reconcile whether each output is unspent or spent. That scan can take longer than restoring a short list of ordinary addresses because Silent Payment ownership must be derived from transaction data. Keep the app connected long enough for discovery to reach the current chain tip before concluding that funds are missing. Aperture’s encrypted direct-device migration does not simply copy Silent Payment output rows as trusted state. The destination prepares the deterministic account and rediscovers outputs. The recovery phrase therefore remains the durable root of ownership; the local scan database is reconstructible index data. See Lose Your Phone, Not Your Wallet: Backup and Restore in Aperture and Recovery Phrase, Private Key, iCloud, or iPhone Transfer? Choose the Right Import before choosing a recovery route. ## What Silent Payments protect—and what they cannot Silent Payments remove one especially obvious relationship: repeated payments to the same published destination script. They also avoid an on-chain notification transaction and let the receiver publish a stable instruction without negotiating a new address. Those are meaningful improvements, not an anonymity guarantee. - The transaction graph remains public. Inputs, outputs, amounts, timing, fee rate, and later spends can still support analysis. - Input clustering can reveal sender relationships. Combining inputs can link coins even when the payment output itself is unique. - Later receiver spending can create clues. Consolidating multiple received outputs may reveal common control. - Off-chain records still matter. An exchange, merchant, contact, IP observer, or device telemetry source may know who initiated a payment. - The current scan service has viewing capability. It receives the scan private key and spend public key for filtering. It cannot spend, and Aperture verifies candidates locally, but this remains a disclosure to understand. - A published sp1 instruction is still public. Anyone who sees it can pay it and associate that instruction with the identity or page where it was published, even though they cannot search the chain for a repeated destination. Good privacy comes from layers: avoid conventional address reuse, understand coin selection, avoid unnecessary UTXO consolidation, keep account descriptors private, limit off-chain identity leakage, and verify the software and services you choose. Silent Payments improve the receive layer; they do not erase every other layer. ## A practical Silent Payments checklist - Open Bitcoin Receive, choose Types, then select Silent Payments. - Share the complete sp1 instruction or its QR; never share the recovery phrase, scan private key, spend private key, or extended private key. - Confirm the sender explicitly supports BIP352 Silent Payments on Bitcoin mainnet. If it does not, switch to a fresh conventional address. - For meaningful value, verify the instruction through a second channel and begin with a small supported test payment. - Allow discovery to reach the current block height after receiving or restoring. An empty result before the scan reaches tip is not final. - Keep the recovery phrase backup accurate and offline. The reusable instruction alone cannot restore or spend the wallet. - Remember that unique outputs improve linkability at receipt; later transaction behavior can still reconnect them. ## Questions people ask before publishing an sp1 instruction Can I keep using the same Silent Payment instruction? Yes. Its purpose is repeated publication and payment. With the same recovery phrase and account scope, Aperture reconstructs the same version-zero scan and spend public keys. Each compatible payment still derives a unique Taproot output. Can any exchange send to it? Only if its withdrawal system supports BIP352. If the form rejects sp1 or does not explicitly document Silent Payments, use a conventional Aperture receive address instead. Does the reusable instruction reveal my balance? It does not provide a simple address lookup that lists all received outputs. However, Silent Payments are not anonymous, and Aperture’s current scan-service model grants that service viewing capability as described above. Can the scan key spend my bitcoin? No. Recognizing an output uses scan-key capability; spending requires the separate spend key and the verified per-output tweak. Protect the scan key anyway because it can reveal activity. Are Silent Payments free? No. There is no special on-chain notification transaction, but the actual Bitcoin payment still pays an ordinary miner fee. Do my old bc1 addresses stop working? No. Switching receive types changes what Aperture publishes now. Previously generated conventional addresses remain valid and monitored. Why can restoration take time? The recovery phrase recreates the account keys, but ownership of one-time outputs must be rediscovered by scanning and locally verifying mainnet transactions. ## Reusable should describe the instruction—not the output Silent Payments change what a static Bitcoin contact point can mean. The reusable object is a pair of public keys encoded as an sp1 instruction. The blockchain output is a fresh Taproot key derived for one transaction. Aperture keeps those roles separate: public instruction for contact, scan key for discovery, spend key for ownership, local verification for trust, and the recovery phrase for reconstruction. That separation is why the headline is not a contradiction. You can publish one stable way to be paid without asking compatible senders to reuse the same on-chain address. The instruction remains recognizable to people; the outputs remain distinct to the blockchain. > Publish once. Derive per payment. Verify locally. Recover from the phrase. Technical standard: BIP352 Silent Payments. Payment URI interoperability: BIP321. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # Why Bitcoin Wallets Generate Fresh Receiving Addresses - Canonical URL: https://aperturex.io/articles/why-bitcoin-wallets-generate-fresh-receiving-addresses/ - Category: Security - Author: Aperture Editorial - Published: 2026-08-30T23:43:31+00:00 - Updated: 2026-08-30T23:43:33+00:00 - Reading time: 12 minutes - Topics: Bitcoin, HD Wallets, Receiving Addresses, Privacy, UTXOs, Silent Payments, Self-Custody A Bitcoin wallet is not one address. See how Aperture derives fresh receiving and change destinations from one recovery credential while keeping every satoshi in one spendable wallet. ![Independent editorial sculpture of one deterministic Bitcoin key feeding unique receiving tiles along a blue external rail and a separate orange change rail](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/bitcoin-fresh-addresses/why-bitcoin-wallets-generate-fresh-addresses-cover.webp) 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. ![Real Aperture Bitcoin Receive screen in the iOS Simulator showing a fresh BIP84 Native SegWit address from an empty article-only wallet](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/bitcoin-fresh-addresses/aperture-bitcoin-fresh-bip84-receive.webp) 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 Aperture BIP84 account details in the iOS Simulator showing its account path, public descriptor, and separate receive and change chains](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/bitcoin-fresh-addresses/aperture-bitcoin-bip84-account.webp) 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 Aperture Bitcoin Settings screen in the iOS Simulator showing 160 generated addresses across BIP44, BIP49, BIP84, and BIP86](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/bitcoin-fresh-addresses/aperture-bitcoin-settings-overview.webp) 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 Aperture Receive Addresses screen in the iOS Simulator showing the current BIP84 address and an ordered pool of unused public addresses](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/bitcoin-fresh-addresses/aperture-bitcoin-receive-address-chain.webp) 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 Aperture Bitcoin address type menu in the iOS Simulator showing Silent Payments, BIP86 Taproot, BIP84 Native SegWit, BIP49 Nested SegWit, and BIP44 Legacy](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/bitcoin-fresh-addresses/aperture-bitcoin-address-types.webp) 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 Aperture Change Addresses screen in the iOS Simulator showing a separate pool of internal BIP84 change addresses](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/bitcoin-fresh-addresses/aperture-bitcoin-change-address-chain.webp) 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 Aperture Bitcoin Receive screen in the iOS Simulator showing the reusable Silent Payment address option for an empty article-only wallet](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/bitcoin-fresh-addresses/aperture-bitcoin-silent-payment.webp) 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. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # One Wallet, Many Mainnets: How Aperture Keeps Accounts and Networks Separate - Canonical URL: https://aperturex.io/articles/one-wallet-many-mainnets-accounts-networks-separate/ - Category: Product - Author: Aperture Editorial - Published: 2026-08-30T23:27:05+00:00 - Updated: 2026-08-30T23:27:07+00:00 - Reading time: 10 minutes - Topics: Wallet Architecture, Mainnets, Accounts, EVM, Network Safety, Self-Custody One Aperture wallet can manage many mainnet identities, but every address, asset, balance, fee, nonce, and transaction remains attached to its exact network. ![Independent editorial sculpture of one secure vault connected to physically separated mainnet ledger islands with distinct account keys](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/mainnet-separation/one-wallet-many-mainnets-cover.webp) A multi-chain wallet can create a dangerous illusion: everything appears in one app, so everything must belong to one account. It does not. Aperture gives you one coherent wallet experience while keeping the cryptographic identities, assets, balances, fees, nonces, and transaction histories of each mainnet in their proper lanes. That separation is not visual housekeeping. It is part of the wallet’s safety model. A network name changes which ledger you are reading, which account identity is valid, which token contract defines an asset, which native coin pays the fee, and where a signed transaction can become final. > One interface can hold many mainnets. It must never pretend those mainnets are one ledger. ![Real Aperture home screen in the iOS Simulator showing Ethereum, Bitcoin, Solana, BNB Smart Chain, and TRON assets in one wallet](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/mainnet-separation/aperture-home-multi-mainnet.webp) A fresh capture from Aperture 2.40.12 in the iOS Simulator. One test wallet presents Ethereum, Bitcoin, Solana, BNB Smart Chain, and TRON together without collapsing their network identities. ## The mental model: wallet, account, asset Three words are often used as if they mean the same thing. In Aperture they describe three different layers: - Wallet. The user-owned container and recovery scope. A recovery-phrase wallet can deterministically derive the supported mainnet accounts that belong to it. Aperture stores the secret material in its protected Keychain vault, not in the portfolio database. - Network account. A public identity for one exact mainnet: network ID, validated address, public key, derivation path, and account index. One wallet owns many of these records. - Asset. A native coin or token on one network. A token is identified by its network plus its canonical contract, mint, type, or issued-asset identity—not by a ticker or display name. A holding then joins one network account to one asset. A transaction joins the same account and network to a transaction hash. This is why the app can sum values into one portfolio while still knowing exactly which ledger owns every row. ## Aperture derives real accounts for every supported mainnet When a full recovery-phrase wallet is created or imported, Aperture derives and validates its supported account-zero identities through canonical Wallet Core coin APIs and chain-specific address rules. The result is not one generic address copied everywhere. It is a complete set of public account records produced from one deterministic recovery credential. Bitcoin-family accounts use their own derivation and address formats. Aptos, Stellar, TRON, Solana, TON, Sui, Near, and XRP each use the key and address rules appropriate to that chain. Aperture verifies the derived address before it becomes a persisted account. A newly supported non-EVM network cannot silently inherit the Ethereum address because EVM compatibility is a positive allowlist, not a guess. ![Real Aperture Receive selector in the iOS Simulator showing separate Sui, Near, XRP, Ethereum, BNB Smart Chain, Arbitrum, Base, and Polygon mainnets](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/mainnet-separation/aperture-network-list-mixed.webp) Real Simulator output. Sui, Near, XRP, Ethereum, BNB Smart Chain, Arbitrum, Base, and Polygon are separate destinations even when several of them use EVM technology. ## The EVM exception: one address, separate chain state Supported EVM-compatible mainnets can reuse the same proven secp256k1 public-key identity. That means the same hexadecimal address can appear on Ethereum, BNB Smart Chain, Arbitrum, Base, Polygon, Optimism, and other supported EVM networks. Aperture persists one validated account record per network, and those EVM records must agree on the same normalized address and public key. The shared address is a cryptographic convenience. It does not merge the chains. Each mainnet still has its own: - Balance and token holdings. ETH on Ethereum and ETH on Arbitrum are independent ledger entries. A token contract on one chain is not the same asset as a look-alike contract on another. - Nonce and transaction history. Sending on Ethereum advances Ethereum state, not BNB Smart Chain state. Explorers and receipts are network-specific. - Native fee asset. The network decides which native coin pays validators or sequencers. Having value at the same address on another chain cannot pay this chain’s fee. - Chain identity and finality. A transaction is encoded, signed, submitted, and confirmed under the selected network’s rules. The address alone does not choose the destination ledger. ![Real Aperture Ethereum receive screen in the iOS Simulator with an explicit Ethereum Network label and public article-only test address](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/mainnet-separation/aperture-receive-ethereum-address.webp) Real Aperture output. The destination is explicitly labeled Ethereum Network. The public address belongs to an empty article-only Simulator wallet; no recovery phrase or private key is present in the image. ![Real Aperture BNB receive screen in the iOS Simulator with an explicit BNB Smart Chain Network label and the same validated EVM test address](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/mainnet-separation/aperture-receive-bnb-address.webp) The hexadecimal address matches the Ethereum screen, but the selected ledger, native asset, network label, safety instruction, and receive request are BNB Smart Chain-specific. Same address does not mean same balance or same network. ## Non-EVM accounts do not borrow the Ethereum identity On a non-EVM chain, the account is derived with that chain’s supported key type, path, public-key encoding, checksum, and address format. A Stellar address beginning with G, a Solana base58 address, an XRP classic address, and a Bitcoin address are not alternate spellings of the EVM address. They are different public identities governed by different protocols. ![Real Aperture Stellar receive screen in the iOS Simulator with a Stellar-specific public address and network safety instruction](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/mainnet-separation/aperture-receive-stellar-address.webp) Real Aperture output from the same empty test wallet. Stellar has its own public account address and an explicit instruction to send only XLM on the Stellar network. This separation matters during both recovery and signing. A full wallet can derive all of its supported chain accounts from the same recovery credential, but it still signs each chain with the correct account material. A private-key import is narrower: an EVM key may cover supported EVM mainnets that reuse the proven address, while a non-EVM private key remains restricted to the network for which Aperture validated it. ## A ticker is not an asset identity Symbols are labels for people, not globally unique identifiers. ETH can be the native fee asset on several EVM networks. USDC exists through different contracts or issued-asset models on different chains. Unrelated tokens can even reuse a familiar symbol. Aperture therefore resolves an asset by network plus its canonical on-chain identity. Native assets use the network plus a native marker; tokens use the network plus their exact contract, mint, Move type, account, or issued-asset identity. ![Real Aperture Receive screen filtered to Stellar, showing Stellar XLM and Stellar USD Coin only](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/mainnet-separation/aperture-receive-stellar-filter.webp) Real Simulator output filtered to Stellar. The visible XLM and USD Coin rows are Stellar variants, not generic symbols detached from a network. - Logos do not prove identity. Aperture uses official bundled network art and contract-aware token artwork, but the network and canonical on-chain identifier remain authoritative. - Names do not prove identity. Searching for “USD Coin” is discovery; selecting the exact network variant is the security decision. - Bridges do not happen automatically. Receiving or sending on one network does not teleport the asset to another. A bridge is a separate protocol action with separate risks. ## The network filter is a safety control Aperture’s Receive and Send discovery screens keep network selection visible because the same wallet can legitimately contain many destinations. “All” is useful for discovery. A specific mainnet filter narrows the list to assets whose identity belongs to that network. ![Real Aperture Receive screen in the iOS Simulator with an All network filter and mainnet-specific asset rows](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/mainnet-separation/aperture-receive-network-selector.webp) Real Simulator output. Every row is backed by an exact asset variant, and the horizontal mainnet selector can reduce the catalog before an address is shown. The ordering is contextual without changing identity. Networks with current local-currency value or activity may be easier to reach, but ranking never rewrites the network ID, address, or asset contract. A refreshed balance can move a row; it cannot turn an Ethereum asset into a BNB Smart Chain asset. ## Receiving: verify the ledger before the address Aperture resolves the receive address from the selected wallet’s persisted account for the chosen blockchain. Independent-address chains must pass their chain-specific validator. EVM chains use the validated shared EVM identity only when the selected network is positively known to be EVM. - Choose the asset and exact mainnet in Aperture. Do not start with an address copied from an old message. - Read the network label above the QR code and the safety instruction below the address. - Make the sender or exchange use that same network. A matching EVM address is not enough. - For meaningful value, send a small supported test amount first and wait for it to appear on the intended network. - Keep the native fee asset for future movement. Receiving a token does not automatically provide gas. When an exchange shows several withdrawal networks for the same symbol, compare the full network name on both sides. Fees and speed are secondary; compatibility is the first requirement. ## Sending: the selected asset carries its network with it Aperture’s global Send action begins with network-aware asset selection. Sending from an asset detail screen already owns one exact asset and network variant, so it goes directly to the recipient step without asking you to choose again. The selected variant carries its network ID, source account, native-or-token identity, exact balance, decimals, and contract or mint into review and signing. The network also determines address validation, amount encoding, fee estimation, signing logic, provider, explorer, and broadcast method. Review is therefore about more than the recipient and amount. It is the final chance to verify the complete tuple: asset, network, recipient, amount, and network fee. Read Send Crypto Without Guesswork for the full flow and Where Crypto Network Fees Actually Go for the fee model. ## What stays separate behind the interface Aperture’s portfolio database keeps the boundaries explicit rather than inferring them from display strings: - Wallet record. Name, wallet kind, selection state, backup state, appearance, and an opaque reference to protected secret material. - Network account record. Wallet ID plus network ID, public address, normalized address, public key, derivation path, and account index. - Asset record. Network ID plus native/token type and the exact canonical contract or equivalent on-chain identity. - Holding record. One account joined to one asset with lossless text balances and visibility state. - Transaction record. Account ID and network ID beside the transaction hash, asset, amount, fee, nonce where applicable, and status. This model prevents a convenient label from becoming a source of truth. It also lets Aperture total a portfolio without sacrificing the boundaries needed for Send, Receive, synchronization, fee calculation, and transaction details. ## Recovery phrase wallets and private-key wallets are intentionally different A recovery phrase is a deterministic root. Aperture can derive the complete supported full-wallet account set, validate it, and persist the public identities atomically. A private key proves a much smaller scope. Aperture does not pretend one child key can reconstruct the original seed or unrelated chain accounts. - Full recovery-phrase wallet. Network selector and asset management are available across the supported mainnet set. Each chain still receives its correct account identity. - EVM private-key wallet. The proven EVM address may be used across supported EVM-compatible mainnets, with independent chain state on each one. - Non-EVM private-key wallet. The wallet remains scoped to the single validated network. It cannot acquire an Ethereum identity merely because another chain is visible elsewhere in the app. For a precise comparison of recovery scope, read Recovery Phrase, Private Key, iCloud, or iPhone Transfer?. ## Mainnet only means fewer ambiguous destinations Aperture supports production mainnets only. It does not mix testnet balances, faucets, test tokens, or test transaction histories into the portfolio. That removes one entire class of network confusion, but it does not remove the need to distinguish one mainnet from another. Ethereum mainnet and BNB Smart Chain mainnet are both real ledgers with real value—and they are still separate. ## Seven mistakes the architecture is designed to expose - “The address matches, so the network must match.” Several EVM mainnets can share the address. Read the network label. - “The ticker matches, so the token must match.” The network and exact contract or issued-asset identity decide what the token is. - “I have ETH somewhere, so I can pay this fee.” The fee asset must exist on the network where the transaction will be submitted. - “One private key restores my whole wallet.” It restores only the account scope the key can prove. - “A wallet app balance is one universal balance.” The total is an aggregation of network-scoped holdings, not an on-chain account. - “Sending to the same EVM address moves value between chains.” A transfer stays on its selected chain. Cross-chain movement requires a separate bridge or exchange workflow. - “The explorer says nothing happened.” You may be looking at the right address on the wrong network explorer. ## A practical preflight for every transfer - Which exact mainnet will record this transaction? - Is the selected asset the native coin or the exact token contract/mint on that mainnet? - Does the recipient support that same network and address format? - Which native asset will pay the fee, and is enough of it available on this network? - Am I reading the correct network explorer and expected finality model? - If the value matters, have I tested the route with a small amount first? ## One wallet should reduce work, not erase boundaries Aperture’s job is to make many networks understandable without making them look interchangeable. The wallet switcher gives you one place to manage the self-custody identity. The portfolio gives you one total. Search and selectors give you one way to find assets. Underneath, every account, asset, holding, transaction, fee, and receive address retains its exact mainnet context. That is the balance a serious multi-chain wallet must keep: one coherent experience for the person, many uncompromised ledgers for the cryptography. > One wallet. Many validated accounts. Every asset and transaction stays on the network that actually owns it. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # Recovery Phrase, Private Key, iCloud, or iPhone Transfer? Choose the Right Import - Canonical URL: https://aperturex.io/articles/recovery-phrase-private-key-icloud-iphone-transfer-import/ - Category: Security - Author: Aperture Editorial - Published: 2026-08-30T23:17:38+00:00 - Updated: 2026-08-30T23:17:40+00:00 - Reading time: 11 minutes - Topics: Wallet Import, Recovery Phrase, Private Key, iCloud, iPhone Transfer, Self-Custody Four ways in—but four very different results. Choose the credential that matches what you still have, whether you need one account, one wallet, a deterministic multi-network wallet, or your complete Aperture setup. ![Editorial decision board presenting recovery tiles, a cryptographic key, an encrypted cloud capsule, and two directly connected phones around one secure vault](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/import-methods/choose-import-method-cover.webp) Every Aperture import option can end with a usable wallet, but they do not restore the same thing. A recovery phrase can recreate a deterministic wallet across supported networks. A private key represents a much narrower account scope. An encrypted iCloud backup restores one protected wallet. A direct iPhone transfer moves the portable Aperture experience—including all eligible wallets and local app state—from one working device to another. The right choice is not the option that sounds most secure or most convenient in the abstract. It is the option whose credential you actually have and whose recovery scope matches what you are trying to bring back. > Choose by evidence: what credential is in your hands, whether the old iPhone still works, and whether you need one account, one wallet, or the complete app. ![Real Aperture clean-device import screen showing Recovery Phrase, Private Key, iCloud Backup, and Transfer from Another iPhone](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/import-methods/04-clean-device-import-methods.webp) A real Aperture 2.40.12 capture from a clean iPhone Simulator. No recovery phrase, passphrase, private key, wallet address, backup, or transfer payload appears in this image. ## The thirty-second decision - Your old iPhone still works and you want everything. Use Transfer from Another iPhone. It is the only route designed to restore the complete portable app state, and the destination must be clean. - The old iPhone is unavailable, but you have an Aperture iCloud backup and its Apple passkey. Use Restore an iCloud Backup. It restores that selected wallet from its encrypted backup document. - You have the wallet’s recovery words. Use Recovery Phrase. Add the exact BIP-39 passphrase if the wallet was created with one. - You have one chain-specific private key or supported extended key. Use Private Key and choose the blockchain first. Expect the account scope represented by that key—not a full seed wallet. If none of those statements is true, do not experiment with similar-looking credentials. Aperture cannot derive a missing recovery phrase from one child private key, manufacture a forgotten BIP-39 passphrase, decrypt an iCloud backup without its matching passkey, or transfer data from an old iPhone that can no longer authorize and open the app. ## First principle: importing access is not moving crypto Your crypto assets remain recorded by their blockchains. Importing gives a new Aperture installation the cryptographic authority and account identity needed to find and use those assets. The network does not receive a “move wallet” transaction, and nothing is sent simply because the wallet becomes visible on another device. What changes between methods is how much identity and local context can be reconstructed. A deterministic seed can derive many chain accounts. One private key proves one account scope. An iCloud backup carries one wallet credential and limited identity metadata. A direct device transfer carries the portable database as well as the wallet secrets needed to make that database usable. ## Recovery Phrase: rebuild the deterministic wallet A BIP-39 recovery phrase is a human-readable encoding used to produce a deterministic seed. The BIP-39 specification defines the mnemonic-to-seed process and an optional passphrase. Aperture accepts valid 12-, 15-, 18-, 21-, or 24-word phrases from its supported BIP-39 language lists, validates the checksum, and uses its canonical mainnet derivations to reconstruct the full-wallet account scope. ![Real Aperture Recovery Phrase import screen in the iOS Simulator with empty secure entry, Scan QR, Paste, and BIP-39 tools](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/import-methods/02-recovery-phrase-import.webp) Real Simulator output with the secret field intentionally empty. Recovery material was never typed, pasted, scanned, logged, or included in the article assets. - What you need. Every word in the correct order, from the correct BIP-39 language list. If the original wallet used a passphrase, you need that exact passphrase as well. - What it restores. The deterministic wallet identity and Aperture’s supported mainnet accounts derived from that seed and passphrase combination. - What it does not restore. Local contacts, tags, notes, wallet ordering, cached balances, app preferences, or a standalone account that was imported from an unrelated private key. Networks can resynchronize public activity, but private local organization is not encoded in the phrase. - Best use. Independent recovery when the original device, app installation, and cloud services are unavailable. - Portability. This is the most portable option when another wallet implements the same standard, word list, passphrase behavior, and derivation paths. Address verification is still essential. The ellipsis on the recovery screen opens BIP-39 tools, including the optional recovery passphrase and official word lists. If the wallet used a passphrase, the words alone are not enough. The same words with a different passphrase derive a different, valid wallet; there is no universal “wrong passphrase” signal. Read the complete Aperture passphrase guide before restoring a passphrase-protected wallet. ## Private Key: restore the represented account scope A private key is the signing authority for a specific cryptographic account. It is not a synonym for a recovery phrase, and a single child key cannot be reversed into the deterministic seed or every sibling account that seed could derive. Aperture therefore asks for the blockchain before it asks for the key. ![Real Aperture private-key network selector showing Aptos, Stellar, EVM networks, Bitcoin, Litecoin, Dogecoin, Bitcoin Cash, TRON, and Solana](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/import-methods/03-private-key-network.webp) Real Simulator output. The network must be selected before key entry because valid formats, address derivation, and account capabilities differ by chain. Aperture supports the formats appropriate to each listed network—for example, raw hexadecimal secp256k1 keys for EVM and TRON accounts, Bitcoin-family WIF or supported extended private keys, Solana seed or keypair encodings, and validated Ed25519 material for applicable networks. The importer decodes the selected format, derives the canonical public address, and rejects a key that is not valid for the chosen route. - What you need. The exact private or extended key and the blockchain it belongs to. Guessing from the number of characters is unsafe. - What it restores. The chain/account scope represented by that key. An EVM import can use the same proven address across supported EVM-compatible mainnets; a non-EVM key remains scoped to its validated network. - What it does not restore. The original mnemonic, unrelated chains, sibling accounts, a BIP-39 passphrase, or the previous app’s contacts, notes, and settings. - Best use. Bringing one standalone account into Aperture when its recovery phrase is unavailable or was never part of that account’s export format. - Important limitation. Treat it as an account import, not as a complete backup of a multi-network wallet. ## iCloud Backup: restore one protected Aperture wallet An Aperture iCloud backup is an app-specific encrypted recovery package. When backup is enabled for a wallet, Aperture encrypts its recovery credential or imported private-key material locally, stores the encrypted document in the app’s private iCloud Drive container, and verifies that remote copy. Restoration requires the Apple passkey created for that wallet. Apple documents that passkeys are public-private key credentials stored through Passwords & Keychain and available across eligible Apple devices through iCloud Keychain. See Apple’s passkey documentation for the platform model. Aperture uses the wallet-specific passkey to obtain the cryptographic material required to unwrap and authenticate the encrypted backup; the wallet payload is decrypted locally. - What you need. The Apple Account containing the encrypted Aperture backup, iCloud Drive access, Passwords & Keychain, and the matching wallet passkey. - What it restores. One selected wallet credential plus the wallet name, kind, expected address, passphrase status, and private-key network/format metadata needed to validate that wallet. - What it does not restore. The complete multi-wallet database, contacts, tags, notes, cached portfolio state, or every application preference. Each eligible wallet has its own backup status and must be considered separately. - Best use. A direct recovery on a trusted replacement Apple device when the old iPhone is gone but the verified backup and passkey remain available. - Portability. This is an Aperture-and-Apple recovery route, not a plain recovery phrase that can be typed into any compatible wallet. Keep an independent manual backup. For the full encryption and restore sequence, read Lose Your Phone, Not Your Wallet. ## iPhone Transfer: move the complete portable Aperture state Direct iPhone transfer is different from credential import. It is designed for a planned move while the old iPhone still works. The old device authorizes an export, displays a short-lived invitation, and establishes an encrypted nearby connection with a clean Aperture installation on the new iPhone. Aperture does not create a server-side transfer archive. - What you need. Both iPhones nearby, unlocked, current enough to use a compatible transfer protocol, and open in Aperture. The old phone must authorize the export; the new phone must start with no wallet records. - What it restores. Eligible wallets and accounts, recovery and private-key material under fresh Keychain references, assets, balances, prices, transaction history, contacts, tags, wallet ordering, selected-wallet state, and portable application preferences. - What it deliberately recreates. Installation-bound security references, biometric authorization, temporary key caches, and push bindings are not cloned as if the new hardware were the old hardware. - Best use. A planned move to a new iPhone when you want the closest result to continuing the same Aperture setup. - Not a backup. If the old device is lost or broken before the session begins, direct transfer cannot help. Maintain a recovery phrase or verified encrypted backup independently. The new iPhone validates the transferred database, migration compatibility, file digest, wallet coverage, and every secret-bearing account before it restores the package. The old iPhone keeps its data after success so you can verify the new installation before deciding whether to erase anything. Read the complete encrypted iPhone transfer guide for the full protocol. ## Why iPhone Transfer disappears after setup A full device migration is not a merge. Importing a second portable database into an installation that already contains wallets could create ambiguous ownership, duplicate records, conflicting settings, or misleading local history. Aperture therefore exposes Transfer from Another iPhone only when the destination is eligible for a complete clean restore. ![Real Aperture import screen on an existing wallet installation showing Recovery Phrase, Private Key, Build Your Entropy, and Restore an iCloud Backup](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/import-methods/01-import-methods.webp) Real Simulator output from an existing Aperture installation. Recovery Phrase, Private Key, physical entropy, and iCloud restore can add or recover individual wallet state. Full iPhone transfer is intentionally absent because this destination is no longer empty. If you already created or imported a wallet on the new phone but intended to perform a complete device migration, stop before adding more state. Decide whether that new wallet needs an independent backup, then return to a genuinely clean Aperture destination through the appropriate supported reset or installation path. Do not delete a credential you have not backed up merely to make the transfer option appear. ## What returns: an exact comparison - Recovery Phrase — deterministic identity. Rebuilds the full-wallet derivation scope from standardized words plus the exact optional passphrase. Public network history can be rediscovered; private local organization cannot. - Private Key — one signing scope. Restores the account or chain family represented by that key. It does not recreate the seed or unrelated accounts. - iCloud Backup — one Aperture wallet. Restores one encrypted wallet credential and the metadata needed to identify and validate it. It depends on the wallet’s Apple passkey and iCloud backup. - iPhone Transfer — the portable app. Moves all eligible wallets plus the portable database and preferences, while rebuilding security items that must belong to the new installation. ## Common wrong turns - Entering recovery words in the private-key field. They are different credential formats. Choose Recovery Phrase and preserve word order. - Forgetting the BIP-39 passphrase. The words can validate perfectly and still derive the wrong wallet when the passphrase is missing or mistyped. - Choosing the wrong chain for a private key. Address rules and accepted encodings differ. Use the network the key was created for, not the network where you hope funds exist. - Expecting one EVM key to restore Bitcoin or Solana. EVM-compatible mainnets can share the proven EVM address; unrelated cryptographic chains do not. - Treating iCloud as a universal seed export. It is an encrypted Aperture backup that requires its Apple passkey. Maintain a manual recovery credential too. - Trying to merge with iPhone transfer. The destination must be clean. Add individual wallets through Recovery Phrase, Private Key, or iCloud when you need to preserve an existing installation. - Erasing the old phone immediately. After direct transfer, first compare wallet count, known public addresses, balances after refresh, contacts, settings, and backup status. ## Import safely - Use a trusted, updated device in a private environment. - Never enter a recovery phrase, passphrase, or private key into a website, support chat, email, or message. Aperture support cannot need it. - Do not create screenshots of secret fields. The screenshots in this article are real but intentionally contain no credential material. - After import, compare at least one complete known public receive address before sending or receiving meaningful value. - Keep the original backup until the restored wallet has been independently verified. - If you used a private key, document its network scope so it is never mistaken for a complete multi-network backup. ## One final decision tree - Do both iPhones work, and do you want every eligible wallet plus local app state? Choose Transfer from Another iPhone on a clean destination. - If not, do you have a verified Aperture iCloud backup and its matching Apple passkey? Choose Restore an iCloud Backup. - If not, do you have the recovery words and the exact optional BIP-39 passphrase? Choose Recovery Phrase. - If not, do you have a supported private or extended key and know its blockchain? Choose Private Key. - If none applies, pause. Creating a new wallet does not recover an old one, and Build Your Entropy creates a new 24-word wallet rather than importing missing credentials. Read Make Randomness Physical only when your intention is to create a new wallet. ## The method should match the recovery you mean The four choices form a ladder of scope. A private key is narrowest. A recovery phrase expands to a deterministic wallet. An iCloud backup restores one Aperture-protected wallet with a smoother Apple-device recovery path. A direct iPhone transfer is widest because it moves the portable app state as well as its eligible wallet credentials. Wider is not always better. When the source phone is gone, direct transfer is unavailable. When only one standalone account should be imported, a private key is more honest than pretending it is a seed. When long-term portability matters, the recovery phrase and exact passphrase remain the independent foundation. > Import the credential you truly have. Expect only the scope it can prove. Verify the public result before trusting the recovery. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # Where Crypto Network Fees Actually Go - Canonical URL: https://aperturex.io/articles/where-crypto-network-fees-actually-go/ - Category: Product - Author: Aperture Editorial - Published: 2026-08-30T23:07:57+00:00 - Updated: 2026-08-30T23:07:58+00:00 - Reading time: 12 minutes - Topics: Network Fees, Gas, Miners, Validators, Fee Burning, Self-Custody A network fee is not one universal charge. Follow it through miner rewards, validator tips, burns, L1 settlement, storage funds, and protocol pools—and see exactly what Aperture does with none of it. ![Editorial still life of a physical routing machine dividing one blue value token among a validator tower, burn aperture, storage vault, and settlement rail](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/network-fees/where-network-fees-go-cover.webp) You press Send. Your wallet shows a network fee. A little later, the recipient receives the transfer—and some extra amount has left your balance. The natural question is simple: who got it? There is no single answer. On one chain, the fee becomes miner revenue. On another, one part rewards a validator while another part is permanently destroyed. A rollup can divide the cost between executing your transaction and publishing data to a different chain. Some protocols route fees into storage funds or locked pools. Others let a contract or application sponsor part of the resources. The label “network fee” hides all of that machinery. This guide opens the machine. > Aperture does not receive any part of the network fee and adds no transfer surcharge. The destination and accounting are determined by the blockchain protocol. ## First: a fee is a price for scarce network work A blockchain does not merely move a number from one screen to another. Independent computers must validate the transaction, order it, execute any program logic, store or commit the result, distribute it across the network, and eventually make it final. Those operations consume scarce block space, computation, bandwidth, storage, or settlement capacity. The fee is the protocol’s method for pricing that scarcity and discouraging unlimited spam. But protocols disagree about what should happen to the value after it is collected. That design choice affects validator incentives, token supply, storage economics, and even how an app should explain the estimate. ## What Aperture estimates—and what the chain charges A wallet can estimate the cost before signing, but it cannot rewrite the protocol. Aperture first obtains rate information without sending a recipient, transfer amount, balance, or wallet identity to the fee quote provider. Once the destination and amount exist, the estimate becomes transaction-shaped: it reflects the actual network, asset, recipient, amount, and chain-specific work that the unsigned transfer is expected to require. ![Real Aperture Transfer Amount screen in the iOS Simulator with the Network Fee menu available from the toolbar](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/network-fees/01-amount-network-fee-entry.webp) Real Aperture 2.40.12 output captured in the iOS Simulator. The wallet is intentionally empty, Review is disabled, and no transaction was signed or broadcast. The ellipsis opens Network Fee. The important distinction is this: a rate is not always the complete fee. Bitcoin needs a transaction size and UTXO plan. Ethereum needs a gas limit plus fee-per-gas rules. Solana combines a base fee with any prioritization fee. TRON may consume staked Bandwidth and Energy before burning TRX. A rollup may add an L1 data or security component to its own execution charge. Aperture prepares the total using the builder for the selected mainnet instead of multiplying every chain by one generic formula. ## Speed choices are protocol-aware Fastest, Standard, and Economy are understandable intentions—not promises that every blockchain has the same auction. Aperture exposes multiple tiers where rates can meaningfully influence inclusion. Where a protocol has no user-defined urgency market, the app does not invent one. Custom values are kept separately by network so a preference on one chain cannot silently become a dangerous value on another. ![Real Aperture Network Fee screen in the iOS Simulator showing Fastest, Standard, Economy, and Custom choices for Ethereum](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/network-fees/02-ethereum-network-fee-presets.webp) A real Simulator capture before a funded amount existed. The dashes are deliberate: Aperture has no complete transaction to price, so it does not display a fictional fee. On the final Review screen, Aperture shows the prepared native fee and its local-currency value when pricing is available. That reviewed fee policy becomes part of the exact draft authorized for signing. If the draft changes, the earlier authorization no longer matches. ## The five places a network fee can go - Block producers. Miners or validators receive some or all of the fee as compensation for ordering, executing, and securing transactions. - The burn. Some protocols destroy a portion—or all—of the charged asset, permanently removing it from circulating supply. - Another settlement layer. Rollups can pay a base layer for data availability or security in addition to charging for local execution. - A protocol fund or pool. Storage funds, locked fee pools, and resource accounts can keep value inside the protocol for a defined long-term purpose. - Contracts or resource sponsors. Some networks share execution economics with contracts, or allow developers to stake resources so users pay less directly. Many networks use more than one destination at once. Follow the examples below and the same word—fee—will describe very different routes. ## Bitcoin: the miner receives the difference A Bitcoin transaction spends existing outputs and creates new outputs. Its fee is not a separate field paid to a fee address. It is the difference between the total input value and the total output value. When a miner includes the transaction, that unassigned value becomes available through the block’s coinbase transaction. The Bitcoin developer guide describes this accounting directly. This is why transaction size matters more than the number of bitcoin being sent. A small-value transfer that must combine many UTXOs can consume more virtual bytes than a large-value transfer using one clean input. The miner is being paid for block space, not a percentage of your payment. ## Ethereum: base fee burned, priority fee rewarded An Ethereum fee is gas used multiplied by the effective price per unit of gas. Under Ethereum’s current fee market, the mandatory base fee is burned. The optional priority fee—the tip used to make inclusion more attractive—goes to the validator. The network’s official gas documentation also explains why an executed transaction can consume gas even if the call ultimately fails: validators still performed the computation. The sender can cap the maximum fee per gas, but the chain charges only the effective amount permitted by the base fee, tip, gas limit, and actual gas consumed. Unused gas is not a bonus handed to the validator. A wallet therefore needs both a realistic gas limit and current pricing; one without the other is not a complete estimate. ## Base and other rollups: execution plus settlement A rollup transaction can have two economic layers. On Base, the total includes an L2 execution fee and an L1 security fee related to publishing transaction data for Ethereum settlement. Base’s network-fee documentation explains both components. The destination is also different from Ethereum mainnet. In the OP Stack design used by Base, priority fees, L2 base fees, and L1-cost fees are accounted through separate protocol fee vaults rather than treating the L2 base fee as Ethereum’s mainnet burn. This is the clearest reason not to say “every EVM fee is gas burned.” The transaction format may feel familiar while the fee route is not. ## Solana: base fee split, priority fee to the validator Solana combines a base transaction fee with an optional prioritization fee based on the requested compute-unit limit and compute-unit price. According to Solana’s official fee documentation, half of the base fee is burned and half goes to the validator; the prioritization fee goes to the validator. The compute-unit limit matters. Setting it far above the transaction’s needs can overpay because the priority calculation uses the requested limit, not merely the units ultimately consumed. The base signature fee is still charged when a transaction is processed and fails, because the network verified and scheduled real work. ## XRP Ledger: the transaction cost is destroyed On the XRP Ledger, the transaction cost is not paid to a validator or company. It is irrevocably destroyed. The XRPL transaction-cost guide describes the cost as an anti-spam mechanism and explains that open-ledger demand can increase the amount required for a transaction to be considered. That means “who receives the fee?” has a surprisingly literal answer here: nobody. It leaves the sender’s balance and ceases to exist. ## TRON: resources first, TRX burn when resources run short TRON measures ordinary transaction bytes with Bandwidth and smart-contract execution with Energy. Accounts can obtain those resources through staking or delegation. If the available allowance is insufficient, the protocol deducts and burns TRX for the missing resources. The charging order is documented in TRON’s Bandwidth and Energy guide. A contract deployer can also stake and share Energy for calls to that contract. Two users performing similar actions may therefore pay different direct amounts depending on account resources and the contract’s sponsorship settings. A fee estimator has to inspect the resource model, not assume a simple auction price. ## Sui: computation rewards and a storage fund Sui separates computation and storage economics. Computation gas supports validator rewards. Storage fees flow into the storage fund, whose design compensates future validators for the long-term cost of maintaining on-chain data. When data is deleted, the protocol can return a storage rebate, less the non-refundable portion defined by the protocol. See Sui’s tokenomics paper for the full model. This is a different mental model from paying once for a line in a block. Part of the charge is about who bears the storage obligation later. ## NEAR: burn plus a contract reward NEAR prices execution through deterministic gas rules rather than a priority-fee bidding market. Its official gas documentation explains that a portion of gas burned during contract execution is credited to the contract account, while the remainder is burned. The documented contract reward is 30 percent of the gas burned during execution. For users, that means a contract call and a simple transfer do not share exactly the same destination story. It also means paying more cannot buy a faster priority lane in the same way it can on a congestion-priced auction. ## Stellar: fees enter a locked protocol pool Stellar’s classic transactions pay an inclusion fee, while Soroban smart-contract transactions also account for resource fees. The network’s fees and resource metering guide states that collected network fees go into a locked account and are not paid out or otherwise used. Stellar tracks this as a protocol fee pool outside circulating supply. So Stellar’s route is neither an immediate validator reward nor exactly the same burn mechanism used elsewhere. The value becomes inaccessible under the protocol’s accounting. ## TON: storage, gas, routing, and message forwarding TON’s fee is a bundle of work performed across transaction phases. It can include storage fees, computation gas, action fees, and forwarding fees for outbound messages. The TON transaction-phase documentation shows the order in which those components are calculated and deducted. A TON transfer is message-driven, so forwarding the message tree can matter as much as executing the first account. The protocol can also reach a partial execution state in which earlier phases consumed resources before a later action failed. ## Why a failed transaction can still cost money “Failed” can describe different moments. A transaction rejected locally before signing costs nothing on-chain. A node that refuses an invalid payload before accepting it may also leave the balance untouched. But once a valid transaction is included or executed, the network may have verified signatures, consumed a nonce or sequence, run program instructions, read and written state, or forwarded messages—even if the requested outcome did not complete. Protocols charge for that work because otherwise anyone could force validators to execute unlimited failing programs for free. Ethereum and Solana explicitly charge processed failures; other networks apply their own phase and resource rules. The safe interpretation is not “failure always costs” or “failure never costs.” It is: check whether the chain accepted and executed the exact transaction. ## Why the number changes between two sends - Demand for block space. Congestion raises auction-based rates and can change which urgency tier is likely to be included. - Transaction size. More Bitcoin inputs, longer scripts, additional signatures, or larger L2 data payloads increase the bytes that must be committed. - Computation. A token transfer or contract interaction usually executes more logic than a native transfer. - State and storage. Creating an account, token account, trust line, storage record, or long-lived object can add reserves, rent, or storage costs. - Settlement-layer conditions. A rollup’s L1 data component can move even if local L2 execution demand is unchanged. - Account resources. TRON Bandwidth and Energy, Sui storage rebates, and protocol-specific balances can change the net amount paid directly. - Fee policy. Fastest, Standard, Economy, or a custom limit can change the ceiling or priority component where the network supports it. ## Honest estimation includes honest failure states A fee number should come with evidence. If current price data is unavailable, a local-currency conversion is not trustworthy. If the balance cannot be verified, the app cannot honestly promise that a custom fee is spendable. Aperture preserves the concrete reason and blocks Apply instead of replacing it with a generic connection message or a made-up value. ![Real Aperture Custom Network Fee screen explicitly reporting unavailable live price and balance verification instead of inventing a quote](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/network-fees/03-custom-network-fee.webp) Real Simulator output from the intentionally empty article wallet. Current local pricing and fee-balance verification were unavailable, so Aperture exposed both conditions and kept Apply disabled. This is a production failure state, not a mockup. Automatic fee requests are bounded, and a provider error stays distinguishable from a successful live quote. Where Aperture has a built-in protocol fallback, it is labeled as such rather than presented as a fresh network observation. ## How to read Aperture’s fee screen - Confirm the network. The fee model belongs to the selected mainnet. A similarly named token on another chain is a different transaction. - Treat the preset as an intention. Fastest asks for stronger inclusion economics where supported; Economy accepts a slower target. Neither can guarantee a block time. - Read the complete amount. Aperture presents an estimated total transaction fee in the selected local currency and preserves the exact native fee for Review. - Look for additional chain costs. Account activation, rent, storage, associated token accounts, reserves, or L1 data can be required even when they are not a validator tip. - Stop on unresolved data. A dash or concrete validation message means the evidence is incomplete. It is not a zero-fee promise. - Verify again on Review. The prepared fee is tied to the actual recipient, amount, and transaction draft immediately before authorization. ## Pay less without creating a riskier send - If the transfer is not urgent, wait for lower congestion or select a slower preset where the network supports meaningful fee tiers. - Keep enough of the network’s native asset for fees. A token balance cannot usually pay the underlying gas unless the protocol and transaction explicitly support sponsorship. - On Bitcoin, understand that many small UTXOs create a larger transaction. Consolidation can reduce a future transaction’s size, but doing it now is itself an on-chain transaction and should be considered only when current fees and privacy tradeoffs make sense. - Avoid repeatedly submitting a contract call that already failed. Read the exact execution reason and transaction hash before rebuilding it. - Do not confuse a normal transfer fee with a bridge, swap, withdrawal, or application charge. Those workflows can include separate protocol or service economics beyond sending one asset on one network. - Never lower a custom ceiling blindly. An underpriced transaction may remain pending, and replacement rules differ by chain. ## The fee is not a mystery charge The cleanest way to understand a network fee is to ask three separate questions: what work is being priced, how is the amount calculated, and where does the collected value go? Bitcoin, Ethereum, Solana, Base, XRP Ledger, TRON, Sui, NEAR, Stellar, and TON answer those questions differently because they are different economic systems—not skins over one universal payment rail. Aperture’s role is narrower and more useful: build the exact mainnet transaction, obtain and validate the relevant rates and resources, show the prepared cost before authorization, sign locally, and report the chain’s result. The protocol receives, routes, burns, or locks the fee. Aperture receives none of it. > The fee is the network’s price for doing the exact work you asked it to do. The wallet’s job is to make that price—and its uncertainty—visible before you sign. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # Send Crypto Without Guesswork: From Recipient to Finality - Canonical URL: https://aperturex.io/articles/send-crypto-without-guesswork-recipient-to-finality/ - Category: Product - Author: Aperture Editorial - Published: 2026-08-30T22:56:16+00:00 - Updated: 2026-08-30T22:56:18+00:00 - Reading time: 12 minutes - Topics: Send, Transactions, Network Fees, Finality, Recipient Safety, Self-Custody Aperture turns a transfer into a chain of explicit checks: exact asset, validated destination, lossless amount, visible network fee, locally bound authorization, one-shot broadcast, and exact-hash finality. ![Editorial still life of a blue transfer token moving from an address slab through a signing gate toward three finality blocks](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/send-crypto-finality/send-crypto-finality-cover.webp) A crypto transfer can look deceptively simple: choose an asset, paste an address, enter an amount, and tap send. Underneath that short sequence are several different questions. Is this the right asset on the right mainnet? Is the destination valid for that chain? Can the account receive it? Is the quantity exact? What will the network charge? Did a node accept the signed transaction—or did the connection disappear at the worst possible moment? Aperture treats those as separate proofs. Each screen owns one decision, and the app repeats the critical network and account checks immediately before signing. The goal is not to make a blockchain transfer feel casual. It is to make every consequential detail visible before your private key authorizes it. > A good Send flow does not promise certainty where a blockchain cannot. It removes preventable ambiguity, then labels the remaining network state honestly. ## A send is a chain of explicit decisions The production route is intentionally linear: choose the exact network asset, validate the recipient, enter an exact amount, review the transfer and fee, authorize the reviewed draft, sign locally, submit once, and monitor the resulting transaction identity. Recipient and Amount are independent screens, and Review remains the last human checkpoint before authorization. - Identity proof. Aperture resolves one canonical network-plus-asset variant and one validated mainnet destination. - Value proof. The amount, balance, fee, reserve, and precision rules are evaluated with lossless base-10 or integer arithmetic. - Intent proof. A short-lived authorization is bound to the exact wallet, account, network, recipient, amount, fee policy, and transaction options shown on Review. - Network proof. The locally derived transaction identity is compared with the provider response and then monitored by exact hash until the chain reports a terminal result. ## Start with an exact asset—not a ticker The main-wallet Send action begins with a network-aware selector. Every row is one exact asset on one mainnet. A search for a token can include its name, symbol, contract or mint, network name, or mainnet alias; a qualified result selects that exact variant without a second guessing step. A token is never resolved from a ticker or display name alone. ![Aperture Send screen showing the real network-aware asset selector in the iOS Simulator](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/send-crypto-finality/01-send-asset-selection.webp) Real Aperture 2.40.12 output captured in the iOS Simulator. The screenshot is unmocked and shows the empty test wallet used for this article. The selector covers Aperture’s supported mainnets, from EVM networks and the Bitcoin family to Solana, TRON, TON, Sui, XRP Ledger, NEAR, Aptos, and Stellar. Official native artwork and exact chain-aware token identities stay attached to the transfer all the way through signing. ## A recipient is more than a plausible-looking string Recipient Information accepts a mainnet address, a supported recipient name, a scanned QR code, or a compatible payment request. Aperture applies the selected network’s complete validator; it does not approve a destination because its prefix merely looks familiar. Supported names begin cancelable resolution after a short typing debounce, and Continue remains unavailable until the current name resolves to an address that is valid for this exact network. ![Aperture Recipient Information screen validating a public EIP-55 example address and warning that it is a new recipient](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/send-crypto-finality/02-recipient-verified.webp) This is a real Simulator capture using a published EIP-55 checksum example address. It is shown only to demonstrate validation; it is not a transfer recommendation or a recipient supplied by a user. No transaction was signed or broadcast. A pasted payment request is also checked against the selected asset. A request that names another network, native coin, token contract, or mint stays on the form with a concrete mismatch instead of silently retaining an older recipient. QR scanning changes only the recipient on this screen; hidden amount, memo, token, or fee metadata cannot leak from an earlier scan into a manual transfer. ## “New recipient” is a warning, not a reputation score After validation, Aperture compares the full destination with its own accepted-send registry for this wallet and mainnet. If there is no matching app-recorded broadcast, it says that the recipient is new and asks you to check the address. If there are prior accepted sends, it can show the exact count. That familiarity signal is deliberately narrow. It does not claim the address is trustworthy, does not inspect someone else’s history, and does not turn imported provider activity into an endorsement. On memo-capable networks, the routing detail is part of the identity: one XRP Destination Tag is not treated as familiarity with every customer behind the same exchange address. ## Some destinations need live account-state checks Syntactic validity is not always enough. When the selected network has recipient-account rules, Aperture starts a cancelable mainnet lookup on Amount and blocks Review until the live requirement is satisfied. - Stellar and XRP Ledger. A missing native account must receive the current live reserve; issued assets require the destination account and matching trust line. - Solana. A new native account needs the current rent-exempt minimum, while a token transfer may require the sender to fund creation of the recipient’s associated token account. - NEAR. Named native recipients must exist, and NEP-141 recipients need a base account before token storage can be prepared. - TRON. An inactive native destination produces an activation advisory; account creation and bandwidth remain sender-side network costs. The same state is loaded again during final transaction preparation. Early checking improves feedback, but it never weakens the last pre-signing race check. ## Enter the amount without floating-point guesswork The Amount screen uses Aperture’s own ASCII keypad. Input accepts only digits 0–9 and one period, and the selected asset’s authoritative decimals cap the precision. Parsing, comparison, conversion to atomic units, and balance checks use exact text and integer operations—not binary floating point. ![Aperture Transfer Amount screen with exact amount controls, Max, asset unit, Review Transfer, and the ASCII keypad](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/send-crypto-finality/03-amount-and-fee-controls.webp) Real Simulator output from the same empty wallet. Review is correctly disabled because no positive funded amount can be prepared. The ellipsis opens the network-fee controls. You can enter in asset units or, when a current price is available, in the selected local currency. A local-currency entry is rounded down to the asset’s supported precision and converted into one canonical asset quantity before Review. The signer never receives a fiat amount. Max is also explicit state, not a visual shortcut. For a native coin, Aperture calculates what can leave after the required network fee and any live chain reserve. For a token, Max spends the token balance while independently requiring enough native coin for gas, rent, bandwidth, storage, or another protocol cost. A scanned fixed amount that happens to equal the balance is never silently converted into Max or reduced to make room for fees. ## The fee is presented as a transaction cost Aperture begins an automatic network-fee session as soon as an asset is selected. That early quote contains network rates only; it does not send your recipient, amount, balance, or wallet identity to a fee provider. When the destination and amount exist, the estimate becomes transaction-shaped: EVM uses buffered gas estimation, Bitcoin-family networks use the current UTXO plan, Solana combines base and priority fees, TRON prepares bandwidth and energy, and every other network applies its validated protocol fee or reserve model. ![Aperture Network Fee screen showing Fastest, Standard, Economy, and Custom fee choices for Ethereum](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/send-crypto-finality/04-network-fee-presets.webp) Real Simulator output opened before an amount was entered. The rows are intentionally unresolved in this capture because no complete transaction could be estimated from the empty test wallet. Aperture does not invent a successful live quote. - Fastest first. Fastest is the initial recommendation. Standard and Economy expose lower rates only where the protocol supplies meaningful tiers. - One understandable total. The interface shows the estimated complete fee in the selected local currency, while keeping the exact native fee available on Review. It does not ask users to mentally multiply gas units, satoshis per virtual byte, or protocol-specific rates. - Custom where it is meaningful. Supported networks can store exact custom base-unit values per network. Networks without a user-defined urgency market do not pretend that a custom priority price exists. - No Aperture transfer fee. The network fee is paid under the blockchain’s rules to its miners or validators. Aperture charges no additional transfer fee. ## Review is the last human checkpoint Final Review keeps the blockchain payment data read-only. Before authorizing, verify every line as if it were a paper instruction you were about to sign. - Asset and network. Confirm the official asset and network artwork, the network name, and—on tokens—the full selectable contract or mint. - Recipient. Read the full selectable destination. Do not rely on the first and last characters alone. - Routing data. Verify any XRP Destination Tag, Stellar memo, payment-request label, message, or reference that will accompany the transfer. - Transfer value. Confirm the exact asset quantity and its local-currency projection when pricing is available. - Network fee. Confirm both the native fee quantity and its local value. Automatic fees must still be fresh before authorization. - Bitcoin controls. When relevant, confirm automatic versus manual coin selection and the independent Replace-by-Fee setting. ## Authorization is bound to exactly what you reviewed Confirm and Transfer does not hand the signer an open-ended permission. Aperture issues a short-lived, single-use capability with a random nonce. It is bound to the wallet ID, exact signing account, mainnet network, and a SHA-256 digest of the reviewed draft—including recipient, amount, fee policy, prepared fee, request intent, Max state, and applicable Bitcoin controls. Change the draft and that authorization no longer matches. If App Lock is enabled, Review requests Face ID or Touch ID when available and falls back to the normal wallet passcode route when necessary. If App Lock is disabled, Aperture still creates a fresh wallet-scoped capability; it simply does not add an authentication screen the user did not configure. Capabilities stay in memory, expire, and are never stored in the transaction database. ## Signing stays local—and proves the account again At signing time, Aperture reloads the selected wallet secret from the protected Keychain vault. A recovery-phrase wallet re-derives the requested account, including its exact BIP-39 passphrase when one exists; an imported private-key wallet reloads its scoped key. The derived public address must match the persisted source account before the key can sign. The private key never travels to the RPC provider. Aperture constructs and signs the chain-native transaction locally, then derives the canonical transaction identity from those exact signed bytes before submission. That local hash or signature becomes evidence the app can compare with the network response. ## Broadcast once; classify the outcome honestly Read-only preparation can use bounded provider failover. Signed submission is different. Aperture chooses one route and does not replay the payload through another provider after an ambiguous timeout, transport failure, cancellation, malformed response, or hash mismatch. The first node may already have accepted it, and a “helpful” retry could create a duplicate payment. - Definitive rejection. The provider proves the transaction was not accepted. The screen shows the sanitized, actionable reason and can offer a fresh attempt through Review and a new authorization. - Accepted or already known. The node accepts the transaction or proves that the identical signed payload is already in its pool or chain. Aperture keeps the locally derived identity and begins status monitoring. - Outcome unknown. The app has transaction evidence but cannot prove whether the node accepted it. Aperture shows the exact local hash, tells you to check activity or a block explorer, and intentionally withholds Retry. - Executed failure. The network included or executed the transaction but reported failure. The hash is retained, fees may have been charged, and the consumed nonce or sequence makes blind retry unsafe. ## Submitted is not the same as final As soon as Aperture has an accepted receipt—or an unknown outcome with a locally derived hash—the Transaction screen starts an exact-hash status monitor. It reads every four seconds while the screen is open and stops only at a confirmed or failed terminal result. A temporary provider or decoding problem becomes a warning, not a fictional failure. Each chain keeps its own finality definition. EVM networks require the exact transaction receipt. Bitcoin-family networks require the transaction in the sender’s script history at a positive block height. Solana checks signature status with transaction-history search. TRON waits for its solidity-node result and block. TON verifies the external-message trace and action outcomes. Sui, XRP Ledger, NEAR, Aptos, and Stellar resolve their native exact transaction identity and terminal execution state. “Not found yet” remains pending. When a terminal state arrives, Aperture updates only the matching local record: same wallet account, same mainnet, same normalized hash. A local database write failure is shown separately and never changes what the blockchain actually reported. ## The receipt remains useful after submission The Transaction screen keeps Status first, then the exact asset, recipient, transaction ID, amount, and network fee. The complete recipient or transaction ID opens in its own selectable detail sheet, and the transaction ID can be copied, shared, or opened in the correct mainnet explorer when supported. After network acceptance, you can add a local note. Notes live in Aperture’s database and are never inserted into transaction calldata, a Solana memo, an XRP tag, or another on-chain field. A scoped wallet refresh begins shortly after broadcast so balances and activity can reconcile even if you close the Send sheet. ## A practical no-guesswork sending ritual - Choose the exact asset and mainnet variant. For tokens, verify the contract or mint when the name exists on more than one chain. - Use Paste or Scan QR when possible, then compare the full destination with the source you trust. Treat every new-recipient warning as a reason to pause. - Enter the quantity in asset units or local currency and confirm the exact asset amount Aperture will sign. Use Max only when you mean to spend the calculated maximum. - Open Network Fee when speed or custom policy matters. Read the total as a network cost, not as an Aperture charge. - On Review, verify the asset, network, contract or mint, full recipient, routing memo or tag, amount, and fee—once, slowly. - Authorize only while that Review still matches your intention. Aperture binds the resulting capability to that exact draft. - After submission, keep the transaction ID. If Aperture says the outcome is unknown, check that exact hash before doing anything else and do not rebuild the payment blindly. - Wait for the chain-specific confirmed state when finality matters. A mempool or submitted state is progress, not completion. ## What the status language is telling you - New recipient. Aperture has no matching accepted app send from this wallet on this mainnet. Verify the full destination and routing detail. - Submitted. A provider accepted the signed transaction or proved the identical payload was already known. Confirmation is still pending. - Confirmed. The network-specific finality monitor found the exact transaction and verified its successful terminal state. - Status unconfirmed. Aperture has transaction evidence but cannot currently prove acceptance or finality. Check the exact hash; do not assume failure and resend. - Not sent. The failure was proven before acceptance. A retry, when offered, returns through Review and obtains a fresh authorization. - Execution failed. The transaction reached the network but did not complete successfully. Keep the hash and inspect the chain result before deciding what comes next. ## Confidence comes from preserving distinctions A wallet cannot make an irreversible network feel reversible. What it can do is preserve the distinctions that matter: a ticker versus an exact asset, a plausible address versus a validated destination, a decimal display versus an atomic amount, an estimate versus a prepared fee, authentication versus signing authority, submission versus acceptance, and acceptance versus finality. That is the Aperture Send flow. It makes the human decision legible, binds the key to that decision, submits the signed transaction once, and follows the exact result without pretending uncertainty is failure. > Verify the destination. Bind the intent. Broadcast once. Follow the hash. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # Move Everything to a New iPhone—Directly, Encrypted, and Serverless - Canonical URL: https://aperturex.io/articles/move-aperture-to-new-iphone-direct-encrypted-serverless/ - Category: Security - Author: Aperture Editorial - Published: 2026-08-30T22:46:06+00:00 - Updated: 2026-08-30T22:46:08+00:00 - Reading time: 8 minutes - Topics: Device Transfer, Encryption, Serverless, iPhone, Keychain, Self-Custody Move wallets, accounts, activity, contacts, and settings straight from your old iPhone to a clean new one—through a short-lived, mutually authenticated, encrypted nearby connection with no Aperture transfer server. ![Editorial still life of two phone-shaped objects connected directly by a bridge carrying a sealed blue data capsule](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/direct-iphone-transfer/aperture-direct-iphone-transfer-editorial-cover.webp) A new iPhone should not force you to rebuild your self-custody setup one wallet, network, contact, preference, and history record at a time. Aperture can move the complete portable app state directly from the old iPhone to a clean new installation while both devices are in your hands. This is not a cloud export and it is not a recovery phrase hidden inside a QR code. The QR is only a short-lived invitation. After the new phone scans it, the two devices authenticate the invitation, derive a fresh transfer key, and exchange the package over an encrypted nearby-device session. Aperture does not upload that package to an Aperture server. > One temporary invitation. One nearby encrypted session. No transfer archive waiting on a server. ## Begin on the iPhone that already has everything On the old iPhone, open Settings → Security and choose Begin Secure Transfer under Transfer to a New iPhone. Aperture authorizes the sensitive export using the app’s current protection state before it opens the invitation screen. If App Lock is enabled, that means the normal approved passcode or biometric route; the authorization is short-lived and cannot be reused indefinitely. ![Aperture Security settings showing the Transfer to a New iPhone section and Begin Secure Transfer action](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/direct-iphone-transfer/aperture-security-direct-transfer.png) Captured from Aperture 2.40.12 running in the iOS Simulator. The screen contains no recovery phrase, private key, wallet address, or account balance. At this stage, Aperture has not sent the wallet database anywhere. It advertises a nearby transfer session and waits for exactly one receiver that can prove it scanned the invitation. The portable database snapshot and wallet-secret bundle are prepared only after the devices establish the approved connection. ## The QR code is a rendezvous, not the cargo Aperture creates a new invitation for each attempt and displays it for about three minutes. The code contains four pieces of connection information: the transfer-protocol version, a cryptographically random 128-bit session identifier, the old phone’s ephemeral P-256 public key, and the expiration time. ![Aperture displaying a temporary direct-transfer QR code and awaiting the new iPhone](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/direct-iphone-transfer/aperture-direct-transfer-qr.png) A real Simulator capture. This invitation had a visible countdown and is now expired. The QR never contained a recovery phrase, private key, wallet database, or readable account data. - It expires quickly. A code that sits unused stops advertising the transfer and cannot be treated as a permanent pairing token. - It carries only public and temporary connection material. The old phone’s private agreement key stays on that device, and wallet secrets are not encoded into the image. - It binds the receiver to this attempt. The new phone generates its own ephemeral key after scanning and authenticates its join request against the scanned session. - It accepts a single peer. Once the old phone accepts the authenticated receiver, it stops advertising to other nearby devices. ## Start the clean setup on the new iPhone Install Aperture on the new iPhone and choose Import an Existing Wallet → Transfer from Another iPhone. Direct migration is intentionally limited to a clean destination with no existing wallet records. That prevents a “merge” from silently replacing or mixing two self-custody states. ![Aperture clean setup showing Transfer from Another iPhone among the import methods](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/direct-iphone-transfer/aperture-new-iphone-transfer-option.png) Captured from a separate clean iPhone Simulator running the current Aperture build. Transfer from Another iPhone appears only when the destination is eligible for a full migration. - Keep both iPhones nearby, unlocked, and open in Aperture. Enable Wi-Fi and Bluetooth. - On the new iPhone, open Transfer from Another iPhone and scan the temporary code on the old phone. - Review the invitation and continue only when both phones are yours and you initiated the transfer. - Leave both devices in Aperture while the new phone connects, receives, verifies, and restores the package. - Wait for success on both devices before navigating away or erasing anything. ## How the two phones build the encrypted path The cryptography is layered so the QR alone is insufficient and the transfer contents are not trusted merely because a nearby connection exists. - Fresh P-256 keys for this attempt. The old phone creates an ephemeral key pair before showing the QR. The new phone creates a separate ephemeral pair after scanning it. - A shared 256-bit transfer key. Each device performs P-256 key agreement and derives the same 32-byte symmetric key with HKDF-SHA-256, salted by the random session identifier. The private agreement keys never need to cross the connection. - Authenticated joining. The receiver proves possession of the derived key with HMAC-SHA-256 over the protocol version, session identifier, both public keys, and expiration time. The source rejects a request that does not match the scanned invitation. - Encrypted nearby transport is required. Aperture uses Apple’s Multipeer Connectivity with encryption required, then sends the portable database directly to the accepted nearby peer. - Sensitive control payloads are sealed again. The manifest, wallet-secret bundle, completion message, and final receipt use ChaCha20-Poly1305 authenticated encryption with domain- and session-bound associated data. “Serverless” here has a precise meaning: Aperture does not relay the migration through an Aperture API, upload it to a cloud holding area, or create a downloadable server copy. The devices discover each other nearby and the package travels through their direct encrypted peer session. ## What actually moves Aperture takes a consistent snapshot of the portable database and pairs it with the wallet secrets required to make its accounts usable on the new installation. This carries far more than a seed-only import. - Wallets and accounts. App-created and recovery-phrase wallets, standalone private-key wallets, supported account records, selected-wallet state, networks, and hardware-wallet records move with the profile. - Recovery material for secret-bearing wallets. Recovery credentials and imported private keys are read from the old device’s protected vault for this transfer and saved under fresh Keychain references on the new iPhone. - Portfolio state. Assets, balances, prices, transaction history, transfers, synchronization state, and relevant cached data move so the new installation starts from a familiar state and can refresh from the networks. - Organization. Contacts, tags, visibility choices, wallet ordering, notification history, and local labels remain part of the experience. - App preferences. Appearance, language, currency, privacy, DApp, cache, and other portable settings are restored with the database. Aperture deliberately does not clone installation-bound security references. Old Keychain references, device-bound biometric authorization, temporary Bitcoin key caches, and the old phone’s push-registration binding are stripped or regenerated. That is why Face ID must be enabled again on the new hardware and why some external integrations may need a fresh device-level confirmation. ## Verification happens before restoration A fast copy is not enough for private wallet material. The receiving iPhone treats the package as untrusted until it passes a sequence of structural, cryptographic, and wallet-specific checks. - Destination check. The receiving database must contain no wallets before a full migration begins. - Version check. The incoming database migrations must be compatible with the Aperture build on the new phone. Updating both phones before transfer avoids an avoidable mismatch. - File integrity. The received byte count and SHA-256 digest must match the encrypted manifest. - Database integrity. Aperture runs SQLite integrity and foreign-key checks and rejects non-mainnet network records. - Complete secret coverage. Every wallet that should have a recovery phrase or private key must have exactly one matching secret, and wallets that should not carry a secret cannot smuggle one into the import. - Account derivation. The transferred recovery material is checked against the wallet’s persisted accounts using the app’s canonical derivation rules before it is accepted. Only after those checks pass does Aperture write fresh Keychain entries and restore the database. The operation keeps a rollback copy of the clean destination state. If the restore fails, Aperture rolls back and removes newly created secret references rather than leaving a half-imported wallet. ## Both phones confirm the finish After the new iPhone completes the atomic restore, it sends an encrypted receipt tied to the same transfer identifier. The old phone does not show success merely because bytes were sent; it waits for the destination to confirm that the import succeeded. Temporary transfer files and in-memory session keys are then discarded. The old iPhone keeps its original data. This is intentionally a copy-and-verify migration, not an automatic remote wipe. Check the new installation before deciding what to do with the old device. ## Verify the new iPhone before erasing the old one - Confirm the expected wallet count, wallet names, ordering, and selected wallet. - Compare at least one known public receive address for every important wallet. - Allow balances and transaction history to refresh, then investigate anything unexpected before moving funds. - Open contacts, tags, currency, appearance, privacy, and visibility settings to confirm the app feels complete. - Reconnect or reauthorize hardware- and device-bound features where the new iPhone requires it. - Enable Face ID again, review App Lock, and confirm your backup and recovery plan still works. ## Know when direct transfer is—and is not—the right tool - Use direct transfer when both phones work. The old iPhone must still open Aperture, authorize the export, and remain nearby until the new phone confirms the import. - Use recovery when the old phone is gone. A recovery phrase, exact BIP-39 passphrase where applicable, or a verified passkey-encrypted iCloud backup is the correct path when the source device is unavailable. - Start with a clean destination. Direct migration is a complete-state restore, not a tool for merging wallets into an already populated Aperture installation. - Keep the apps current. Incompatible database versions are rejected rather than guessed through. Update Aperture on both iPhones before beginning. - Treat transfer as convenience, not backup. The old device remains a single point of failure until the move begins. Maintain an independent manual or encrypted recovery route even after a successful migration. ## A complete move without surrendering custody The easiest migration would be to upload everything to a server and download it later. For a self-custody wallet, that convenience creates the wrong kind of copy. Aperture instead uses the moment when both trusted devices are present: the old phone authorizes, the new phone scans, both derive a fresh key, and the package moves directly. The result is more than a wallet import and less than a device clone. It restores the portable Aperture experience, regenerates what must belong to the new installation, verifies the cryptographic identity of every secret-bearing wallet, and leaves the source untouched until you decide the move is complete. > Move the experience. Recreate device-bound trust. Verify first. Erase later. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # Lose Your Phone, Not Your Wallet: Backup and Restore in Aperture - Canonical URL: https://aperturex.io/articles/backup-restore-aperture-wallet/ - Category: Security - Author: Aperture Editorial - Published: 2026-08-30T22:33:18+00:00 - Updated: 2026-08-30T22:33:19+00:00 - Reading time: 8 minutes - Topics: Backup, Restore, iCloud, Apple Passkeys, Recovery Phrase, Self-Custody A phone is replaceable. Your recovery access is not. Learn how Aperture combines verified manual backups with passkey-encrypted iCloud restore—and what to prepare before a device disappears. ![Editorial still life of a phone slipping away while a recovery tile, cloud token, and blue passkey remain secured](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/icloud-backup-restore/aperture-backup-restore-editorial-cover.webp) A self-custody wallet does not live inside one phone. The phone holds the credentials and software that let you reach it. Your assets remain on their networks; what decides whether a replacement device can reach them is the recovery access you prepared before the old device disappeared. Aperture gives every eligible wallet two complementary recovery paths: a verified manual backup and a passkey-encrypted iCloud backup. One is deliberately offline and portable. The other is designed to make restoring on a new Apple device direct without sending unencrypted wallet material to a server. > The device is replaceable. The recovery phrase, any BIP-39 passphrase, and access to the wallet’s encrypted backup are not. ![Aperture wallet settings showing iCloud Backup and manual backup options](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/icloud-backup-restore/aperture-wallet-backup-options.png) A real Simulator capture from the current Aperture build. It shows both backup paths and contains no recovery phrase, passphrase, private key, wallet address, or other private account data. ## Start with the failure you are preparing for “I lost my phone” can mean several different things: the device was stolen, the screen failed, the app was removed, or you moved to a new iPhone. In each case, the goal is the same: reproduce the wallet credential on a trusted device and confirm that it derives the expected public accounts. Aperture cannot look up a recovery phrase, reset a forgotten BIP-39 passphrase, or bypass an unavailable Apple passkey. That is the point of self-custody: there is no recovery desk that secretly holds another copy. A good backup plan therefore avoids depending on a single device, a single storage system, or memory alone. ## Two backup paths are stronger than one The manual and iCloud options protect against different failures. They are most useful together, not as competing choices. - Manual backup protects portability. For an app-created wallet, securely record the 12- or 24-word recovery phrase offline. If the wallet uses a BIP-39 passphrase, record that exact passphrase separately. Compatible recovery software can reproduce the wallet without depending on Aperture or iCloud. - Encrypted iCloud backup protects convenience. Aperture encrypts the wallet locally, saves the encrypted backup document in your private iCloud Drive container, and protects restoration with a unique Apple passkey for that wallet. - Verification protects against false confidence. Aperture does not mark a manual backup complete until you prove you recorded it, and it does not mark an iCloud backup complete until it reads the stored document back and verifies it. A screenshot of recovery words, a note in an email draft, or a copy stored beside its passphrase is not the same as a resilient backup. The objective is a durable record that can survive the loss of the phone without giving one stolen item everything needed to move the funds. ## Manual backup: the universal recovery route Choose Back Up Manually from the wallet’s settings. After Aperture authenticates the sensitive action, it shows the wallet’s recovery phrase so you can record it in a private environment. The next screen hides a random set of words and asks you to enter them again. Only a correct verification marks the manual backup complete. For a passphrase-protected wallet, the passphrase is part of the recovery credential. The same recovery words with an empty, different, or mistyped passphrase derive a different wallet. Keep a durable copy of the exact passphrase—including case, spaces, and punctuation—separate from the words. - Write the recovery phrase in the numbered order shown by Aperture. - Keep the record offline and protected from fire, water, theft, and casual photography. - If a BIP-39 passphrase is used, store it in a different secure location. - Never enter either secret into a website, support chat, form, or message. - Perform a private recovery test before treating the backup as finished. ## What Aperture does when you enable iCloud Backup Turn on Create an iCloud Backup for a wallet and Aperture begins a wallet-specific protection flow. The design separates the encrypted file, the key that encrypts it, and the Apple credential that authorizes recovery. - A wallet-specific Apple passkey is created or verified. The passkey belongs to that wallet rather than acting as one master credential for every Aperture wallet. - A separate 256-bit data key protects the wallet material. Aperture uses AES-GCM authenticated encryption and wraps the data key with material derived through the Apple passkey. - Encryption happens locally. The recovery phrase, optional BIP-39 passphrase, or imported private-key material is encoded and encrypted on the device before the backup document reaches iCloud Drive. - The stored document is read back. Aperture fetches the backup it just saved, authenticates and decrypts it locally, and checks that it matches the wallet. A failed read-back is not presented as a completed backup. - The verified time is recorded. Once the remote copy is confirmed, the wallet settings can show when the most recent successful iCloud backup was completed. The encrypted document includes the protected wallet payload plus limited metadata needed to identify and list the backup. Aperture’s website verifies only the app’s passkey association; it never receives the wallet’s recovery material or encrypted backup file. ## Restore after losing the phone On a replacement iPhone or after reinstalling Aperture, sign in to the Apple Account that has the relevant iCloud Drive data and Apple passkey in Passwords & Keychain. Then open Wallets Management and choose Restore an iCloud Backup. ![Aperture Wallets Management showing the Restore an iCloud Backup action](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/icloud-backup-restore/aperture-wallet-management-restore.png) This is a real capture from Aperture running in Simulator. The restore action is available beside the normal create and import paths. - Open Aperture on the trusted replacement device. - Choose Restore an iCloud Backup from Wallets Management, or select it from the import-method screen. - Select the backup by its wallet name and verified backup time. - Approve the wallet’s Apple passkey with the system authentication offered by the device. - Aperture derives the wrapping key, unwraps the backup data key, authenticates and decrypts the backup locally, validates the recovered wallet, and then imports it. - Compare a known public address or receive address before sending meaningful funds. An explicit restore always asks the wallet’s Apple passkey to authorize the operation. A cached local key is not used to silently restore a wallet on a new device. If the correct passkey is unavailable, the encrypted document remains unreadable. ## Choose the recovery credential you still have Aperture keeps the recovery routes together so the next step follows the credential available to you—not the way the wallet happened to be created on the old phone. ![Aperture Import an Existing Wallet screen showing recovery phrase and iCloud restore methods](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/icloud-backup-restore/aperture-wallet-restore-methods.png) A real Simulator capture of the current import flow. The screen presents recovery phrase and encrypted iCloud restore as separate choices and contains no entered secret. - You have the recovery phrase. Choose Recovery Phrase and enter the 12 or 24 words on the trusted device. Add the exact BIP-39 passphrase if the wallet used one. - You have the iCloud backup and Apple passkey. Choose Restore an iCloud Backup, select the wallet, and approve the system passkey request. - You imported a single private key. Use its private-key import route or restore the encrypted iCloud backup created for that wallet. A seed phrase for another wallet cannot reproduce that standalone account. ## A practical lost-phone playbook - Secure the missing device. Use Apple’s device controls to mark it lost or erase it when appropriate. Change unrelated account credentials if the device may have exposed them. - Use a trusted replacement. Update the operating system, install Aperture from its official distribution, and avoid restoring wallet secrets on a borrowed or modified device. - Take the strongest available recovery path. Use the encrypted iCloud backup when the Apple passkey is available; keep the manual recovery phrase as the independent fallback. - Verify before acting. Confirm known public addresses, wallet names, and networks. A passphrase typo can open a different valid wallet without displaying a “wrong passphrase” warning. - Refresh the recovery plan. After the new device is established, confirm the manual backup remains accurate and create a fresh, verified iCloud backup if needed. ## Know what each path cannot do - iCloud Backup is not a substitute for the recovery phrase. It depends on iCloud Drive, the correct Apple Account, and the wallet’s Apple passkey remaining available. - The recovery phrase cannot replace a lost BIP-39 passphrase. Both are required to reproduce a passphrase-protected wallet. - A completed backup can become stale. Wallet credentials are stable, but imported-wallet configuration and backup metadata should still be reverified after meaningful changes. - Each wallet must be checked separately. A backup status shown for one wallet does not prove that every wallet in Aperture has a verified recovery path. - Support cannot decrypt the backup. Without the correct recovery credential or Apple passkey, Aperture cannot manufacture access—and neither can anyone else. ## The five-minute recovery audit - Open every wallet in Wallets Management and review its backup status. - Confirm the manual recovery phrase is recorded offline and readable. - Confirm any BIP-39 passphrase is recorded exactly and stored separately. - Confirm iCloud Backup shows a recent successful verification where you use it. - Make sure Passwords & Keychain and iCloud Drive are available on the Apple Account you expect to use. - Know which public address you will compare after a restore. > A backup is finished only when you know what it contains, where the independent recovery credential is, and how you will verify the restored wallet. Losing a phone should be an equipment problem, not a custody crisis. Aperture cannot remove the responsibility of self-custody, but it can make that responsibility visible: two recovery paths, local encryption, explicit verification, and a restore flow that tells you exactly which credential is required. Prepare both paths while the wallet is accessible. Then if the device disappears, the important thing does not disappear with it. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # One Recovery Phrase. A Separate Wallet: BIP-39 Passphrases in Aperture - Canonical URL: https://aperturex.io/articles/add-bip39-passphrase-aperture-wallet/ - Category: Security - Author: Aperture Editorial - Published: 2026-08-30T21:59:10+00:00 - Updated: 2026-08-30T22:08:35+00:00 - Reading time: 5 minutes - Topics: BIP-39, Passphrase, Wallet Security, Recovery Phrase, Self-Custody Add an optional BIP-39 passphrase to derive a separate wallet from the same recovery words—then back up both secrets without confusing one wallet for another. ![Editorial still life of blank recovery tiles and a separate blue key converging on a secure black wallet](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/bip39-passphrase/aperture-bip39-passphrase-editorial-cover.webp) A recovery phrase can create more than one wallet. Add a BIP-39 passphrase and the same 24 words lead to a completely separate set of accounts and addresses—one that can be reproduced only with both inputs. Aperture brings that advanced option into wallet creation and recovery without hiding the consequences. It confirms the passphrase twice, explains exactly what changes, and gives you a clear path to back up the two secrets safely. > The passphrase does not lock, rename, or modify the wallet made from your recovery phrase alone. It derives another valid wallet. ![Aperture BIP-39 guide showing two secrets deriving one wallet and the seed derivation process](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/bip39-passphrase/aperture-passphrase-guide.png) A real Simulator capture from the current Aperture build. The guide uses labels only; no recovery phrase, passphrase, wallet address, or private account data appears in this image. ## Two secrets, one deterministic result Under BIP-39, the normalized recovery phrase is used as the PBKDF2 password. The salt is the word “mnemonic” followed by the normalized passphrase. PBKDF2-HMAC-SHA512 runs for 2,048 iterations and produces a 512-bit seed; wallet accounts and addresses are then derived from that seed. The empty string is a valid passphrase. That is the familiar wallet derived from the recovery phrase alone. Any nonempty passphrase derives its own wallet. Because the process is deterministic, the same normalized recovery phrase and exact passphrase reproduce the same result on compatible BIP-39 software. This is why calling a passphrase a “25th word” can be misleading. It is not an extra word appended to the mnemonic, and it does not need to come from the BIP-39 word list. It is a separate input whose case, spaces, punctuation, and ordering matter. ## There is no “incorrect passphrase” warning BIP-39 does not know which wallet you intended to open. Every passphrase produces a valid seed. A one-character typo therefore does not fail like a wrong login password—it quietly opens a different wallet, usually with a zero balance. ![Aperture BIP-39 guide showing two passphrases deriving two separate wallets](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/bip39-passphrase/aperture-passphrase-separate-wallets.png) The current app makes the separation explicit: Wallet A remains unchanged when another passphrase derives Wallet B. That behavior is powerful, but it changes the backup model. Your recovery phrase alone is no longer enough to restore the passphrase wallet. If the passphrase is lost, there is no reset link, recovery service, or support override that can reconstruct it. ## Protection comes from strength and separation If someone finds only the recovery phrase, they still need the exact passphrase to derive the protected wallet. But this benefit is only as strong as the passphrase and the way it is stored. A name, birthday, quotation, pattern, or reused password may be guessed quickly. ![Aperture BIP-39 guide explaining strong passphrases and separate backups](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/bip39-passphrase/aperture-passphrase-safety.png) A real capture of Aperture’s in-app safety guidance: choose an unpredictable secret and keep its backup separate from the recovery phrase. - Make it unique. Use several randomly selected words or another high-entropy value created only for this wallet. Do not reuse an account password. - Record it exactly. Preserve every uppercase letter, lowercase letter, space, punctuation mark, and word in its exact position. - Back it up offline. Create a durable copy and store it separately from the recovery phrase so one stolen backup does not reveal both secrets. - Do not rely on memory. A memorable passphrase can still be forgotten, altered, or remembered with the wrong spacing years later. - Test before funding. In a private, controlled recovery test, confirm that both inputs reproduce the expected addresses before receiving a significant amount. ## Adding a passphrase in Aperture When creating a wallet, Aperture first generates the recovery phrase. On the recovery-phrase screen, open the options menu and choose Add BIP-39 Passphrase. Enter the secret twice, then confirm it. Both fields can remain empty if you want the standard wallet derived from the recovery phrase alone. ![Aperture wallet creation form with secure passphrase and verification fields](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/bip39-passphrase/aperture-passphrase-form.png) The production screen uses two secure fields and validates their normalized values before continuing. This capture contains no entered secret. - Start the normal Create New Wallet flow and securely record the generated recovery phrase. - Open the recovery screen’s options menu and choose Add BIP-39 Passphrase. - Enter the exact passphrase in both secure fields and confirm. Aperture derives the wallet again using both inputs. - Complete wallet creation, then back up the passphrase separately from the recovery phrase. - Before using the wallet for meaningful funds, verify that a controlled recovery reproduces the expected public addresses. Restoring works the same way. Choose the recovery-phrase import flow, open its options menu, select Add BIP-39 Passphrase, and enter the exact original passphrase twice. Leave it blank only if the wallet was originally created without one. ## What Aperture keeps on the device Aperture normalizes the passphrase as required by BIP-39 before deriving the seed. When the wallet is saved, the complete recovery credential—the normalized recovery phrase and passphrase—is stored in Aperture’s device-only Keychain vault. The wallet database keeps an opaque Keychain reference rather than the secret itself. The passphrase is not a substitute for the app passcode, Face ID, a safe backup, or a trusted device. It solves a different problem: it changes the seed required to derive the wallet. Good device security and careful offline recovery practices still matter. ## The backup rule that matters > Recovery phrase + exact passphrase = passphrase wallet. Lose either one, and that wallet cannot be recovered. Expose both, and the passphrase adds no protection. BIP-39 passphrases reward precision. They can create meaningful separation between a recovery phrase and the wallet that holds your assets, but there is no safety net for a weak, mistyped, or lost secret. Use the feature deliberately: choose a strong passphrase, make two separate backups, verify the derived addresses, and treat the pair as the complete key to that wallet. Aperture gives you the controls and the explanation. Self-custody still depends on how carefully you use them. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # One Amount, Every Context: Meet Aperture’s Currency Converter - Canonical URL: https://aperturex.io/articles/aperture-currency-converter-crypto-fiat-metals/ - Category: Product - Author: Aperture Editorial - Published: 2026-08-30T21:44:02+00:00 - Updated: 2026-08-30T22:08:35+00:00 - Reading time: 4 minutes - Topics: Currency Converter, Crypto, Fiat, Precious Metals, Market Data Convert crypto, fiat currencies, and precious metals together in one editable view—then keep the tool one tap from Home. ![Editorial still life of generic digital, fiat, silver, and gold forms connected in a conversion network](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/currency-converter/aperture-currency-converter-editorial-cover.webp) Crypto rarely arrives with just one useful frame of reference. A Bitcoin amount might need to make sense in your local currency, in US dollars, beside Ethereum, or even against gold. The arithmetic is simple. The context switching is not. Aperture’s Currency Converter turns that scattered work into one calm, editable view. Choose the units that matter, type into any row, and every other value updates around it. No fixed “from” and “to” pair. No bouncing between calculators. > One amount becomes a shared point of reference across the currencies and assets you actually think in. ![Aperture Currency Converter showing one Bitcoin converted to Jordanian dinar, US dollars, and gold](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/currency-converter/aperture-currency-converter-main.png) A real capture from the current Aperture app in Simulator. Values are point-in-time references and will change with market and exchange-rate updates. ## A converter that behaves like a workspace Most converters are built around a rigid pair: one source and one destination. Aperture keeps every selected unit visible at the same time. In the view above, 1 BTC is expressed simultaneously in Jordanian dinar, US dollars, and gold. Each converted row also shows its rate relative to the amount you last edited. The important detail is that no row is permanently the source. Tap into USD and enter 100; JOD, BTC, and XAU recalculate. Edit the gold amount instead, and gold becomes the new reference. The interface follows the question you are asking now. ## Build the comparison you need Tap a unit code to replace it, or choose Add Currency to expand the view. Aperture’s searchable catalog brings supported fiat currencies, precious metals, and crypto assets into one picker. The selected set is yours: a compact two-row conversion for quick checks, or a broader comparison across several markets. ![Aperture currency and asset search showing Ethereum under Crypto Assets](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/currency-converter/aperture-currency-converter-search.png) Search spans the same catalog: this real app capture narrows the available crypto assets to Ethereum. - Fiat currencies. Keep your local currency beside common reference currencies for travel, purchases, accounting, or everyday intuition. - Crypto assets. Compare core assets and supported wallet assets without leaving Aperture. - Precious metals. Add gold or silver when a hard-asset reference helps make a number more concrete. ## Ask the question in either direction A useful converter should work with the thought you already have, not force you to reverse it first. Aperture makes every amount field editable, which changes the kinds of questions you can answer quickly: - “What is this BTC amount worth in my selected local currency?” - “How much Bitcoin corresponds to a 500 USD budget?” - “What does one ounce of gold look like beside USD and BTC?” - “If I change the local-currency amount, how do all the other references move?” The displayed precision adapts to the kind of unit. Fiat remains readable, while small crypto values can retain the additional decimal places needed to stay useful. Rate summaries stay attached to the rows, so the relationship is visible as well as the result. ## Fast on open, current when available When the converter opens, Aperture can use saved market data immediately while refreshing foreign-exchange, metal, and asset prices. If a fresh request is temporarily unavailable, usable cached data can keep the workspace from collapsing into an empty screen. Your chosen rows and their order are saved, too. The next visit starts with the comparison you built instead of resetting to a generic pair. You can reorder or remove rows with Edit, while Aperture always keeps at least two usable units in the conversion. > Converter values are informational references, not executable quotes. Markets move, providers can update at different times, and an exchange or merchant may use a different rate. ## Keep it one tap from Home The full tool lives at Settings → Tools → Currency Converter. If you use it often, turn on Show on Home Screen. Aperture adds a converter shortcut beside the wallet controls, opening the same saved units in a focused sheet without making you leave Home. ![Aperture Home screen with the Currency Converter open as a sheet](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/currency-converter/aperture-currency-converter-home.png) With the optional shortcut enabled, the saved converter opens directly over Home. This is a real capture from the current app build. ## How to use it - Open Settings, choose Tools, then open Currency Converter. - Tap a currency or asset code to replace that row, or tap Add Currency to add another comparison. - Enter an amount in any row. That row becomes the reference and every other selected unit recalculates. - Use Edit to reorder the view or remove units you no longer need. - Enable Show on Home Screen if you want the converter available from the wallet’s top controls. ## Numbers with context A currency converter is a small tool, but it sits at the center of how people understand value. Aperture’s version is designed for the messy reality around crypto: several useful units, changing questions, tiny decimals, local currencies, and reference assets that do not fit into a single pair. Choose the contexts that matter to you once. After that, one edited amount is enough to bring the whole picture into view. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant. # Make Randomness Physical: Build an Aperture Wallet with Dice, Coins, or Digits - Canonical URL: https://aperturex.io/articles/build-wallet-with-dice-coin-flips-random-digits/ - Category: Product - Author: Aperture Editorial - Published: 2026-08-30T21:30:44+00:00 - Updated: 2026-08-30T21:34:43+00:00 - Reading time: 4 minutes - Topics: Physical entropy, BIP-39, Wallet security, Self-custody Aperture turns fair physical outcomes into the exact 256 bits behind a 24-word BIP-39 recovery phrase—entirely on your device. ![Editorial still life of a black die, two silver coins, and cobalt number tiles representing physical wallet entropy](https://rfjdenxkgjgepgbmxxkd.supabase.co/storage/v1/object/public/article-images/af89b673-a767-4029-b24e-76c41eb2b445/physical-entropy/aperture-physical-entropy-editorial-cover.png) Most wallets create their recovery phrase from randomness generated inside the device. That is a sound, widely used default. Aperture also gives advanced users a radically tangible alternative: supply the wallet’s randomness yourself, one fair physical event at a time. Roll a die. Flip a coin. Record a digit produced by a genuinely random physical process. Aperture converts those outcomes into one continuous bitstream and stops only when it has exactly 256 bits—the entropy required for a standard 24-word BIP-39 recovery phrase. > The point is not ceremony. It is direct control: every entropy bit begins with an event you performed and recorded. ## Randomness you can hold in your hand Physical entropy changes where wallet randomness comes from. Instead of asking the device to create the initial value, Aperture accepts outcomes from a source you can observe. The conversion happens locally, and the custom entropy contains only the values you enter. Aperture does not mix in device-generated randomness behind the scenes. The interface keeps the process legible. It shows how many bits have been collected, preserves the recent input sequence, lets you undo the latest entry, and allows a complete reset. The final wallet action remains unavailable until the accumulator contains exactly 256 bits. ## Three physical inputs. One continuous bitstream. Dice rolls, coin flips, and random digits are not separate wallet modes. You can switch between them at any time. Every accepted result contributes to the same ordered stream, so the method can match the physical source in front of you. ### Dice rolls Use a fair six-sided die and enter every result in order. Faces 1 through 4 each map to two unbiased bits. Faces 5 and 6 each map to one bit. The variable contribution avoids forcing six equally likely outcomes into a four- or eight-value space, which would introduce bias. ### Coin flips A fair, independent coin flip is already binary: heads contributes one bit and tails contributes the other. Aperture records each side in sequence and updates the shared total immediately. ### Random digits Digits must come from a genuinely random physical process—not a birthday, a remembered number, or a pattern you invent. Digits 0 through 7 each contribute three bits; 8 and 9 each contribute one. As with dice, Aperture uses power-of-two groups so accepted outcomes do not favor one bit value over another. ## What happens when the counter reaches 256 - Aperture packs the bits into 32 bytes. Inputs stay in their recorded order and are packed most-significant bit first. - BIP-39 adds an 8-bit checksum. The checksum comes from the beginning of SHA-256 over the 32-byte entropy value. - The resulting 264 bits become 24 words. They are split into 24 groups of 11 bits; each group selects one entry from the standard 2,048-word BIP-39 list. - Wallet Core derives the wallet. The recovery phrase, plus an optional BIP-39 passphrase if you choose one, deterministically recreates the same accounts and addresses. This is the standard relationship defined by the BIP-39 specification: 256 entropy bits, 8 checksum bits, and a 24-word mnemonic. Aperture uses Trust Wallet Core for standards-based wallet derivation. ## Why this design matters - Your source is explicit. The custom entropy is built from the physical outcomes you record, not from an opaque mixture of additional random values. - Processing stays on-device. Aperture converts the sequence and creates the recovery phrase locally; the entropy sequence is not uploaded for processing. - Different sources can be combined. Switching input types never starts over. All accepted results join the same ordered 256-bit value. - The process is inspectable. Progress, recent inputs, undo, and reset controls make the state visible before a wallet can be created. Physical entropy is an alternative source of wallet randomness. It is not an extra password, and it is not automatically safer than the standard creation flow. Its security depends entirely on the fairness, independence, privacy, and accuracy of your physical process. ## Use physical entropy safely > If you cannot guarantee a fair source, private surroundings, and exact recording, use Aperture’s standard wallet creation instead. - Use a fair coin or die, and make each event independent of the last. - Keep the complete process away from cameras, screen recording, and other people. - Record every result exactly once and in the order it occurred. One missing, duplicated, or reordered entry creates a different wallet. - Never invent “random-looking” digits. Human choices and familiar patterns are predictable. - Back up the completed recovery phrase offline, verify it before funding the wallet, and securely destroy intermediate notes you no longer need. ## How to build yours - Open wallet setup in Aperture and choose Build Your Entropy. - Select Dice Rolls, Coin Flips, or Random Digits. - Perform each physical event and record the result immediately. Switch methods whenever you need to—the progress continues. - Review the visible history as the counter approaches 256 bits. Use Undo if the latest entry is wrong; reset if the sequence cannot be trusted. - When all 256 bits are collected, create the wallet and make a durable offline backup of the resulting 24-word recovery phrase. Aperture’s physical-entropy flow makes an invisible cryptographic starting point visible, deliberate, and yours. The final result remains a familiar, interoperable BIP-39 wallet—but the first moment of randomness can begin in your own hands. --- Security: Never share a recovery phrase, private key, BIP-39 passphrase, app passcode, or backup secret with Aperture support or an AI assistant.