A mid-sized fintech firm has adopted Bitcoin and Ethereum as part of its treasury reserve strategy. Several team members use browser wallets to manage custody or execute transfers, each relying on personal security practices—strong passwords, backup recovery phrases, two-factor authentication on email accounts. Yet the firm has no written policy governing which wallets are permitted, how access is logged, whether multiple signatories are required, or what happens when an employee leaves. A single compromised laptop or a forgotten seed phrase could move significant assets without any organizational record of who authorized the transaction or when. This scenario is far from uncommon. Browser-based wallets like Alby, Ambire, Backpack, and Exodus offer genuine advantages for small teams and individuals: fast onboarding, cross-platform availability, and direct control over private keys without relying on a third-party custodian. Those same features create organizational blind spots when applied to business use without supporting governance structures. Security guides designed for individuals—which emphasize personal key control and anti-phishing checks—do not address the audit trails, access controls, and multi-signature verification that enterprises require to protect assets and comply with financial oversight. The audit and accountability gap in browser wallet deployments Enterprise accounting systems are built on the principle of the audit trail. When an employee submits an expense, transfers funds to a vendor, or executes a financial transaction, the company maintains a record: who initiated it, when, why, and what authorization chain was followed. That record serves multiple purposes. It deters fraud, simplifies tax reporting, supports internal controls, and demonstrates compliance to auditors and regulators. A browser wallet, by design, does not create an enterprise audit trail. When an employee uses Coinbase Wallet or Crypto.com’s browser extension to sign a transaction, the wallet records the private key holder’s action—what was sent, to which address, and at what time. But it does not track who in the organization authorized the transfer, whether it was approved by a manager or compliance officer, or whether it aligns with company policy. The wallet’s log is a cryptographic record; the organization’s record is silent. This creates a material control failure. An employee might move treasury assets to a personal address, claim a network error occurred, and later transfer them back—but without organizational records, the company would discover the discrepancy only through periodic reconciliation or blockchain analysis. A more sophisticated fraud might involve an employee executing transfers below audit thresholds to avoid scrutiny, or routing assets through multiple addresses to obscure their origin. The browser wallet itself has no mechanism to prevent, detect, or record such actions in a way that integrates with the company’s financial systems. Regulatory bodies and auditors expect enterprises to demonstrate control over material assets. If a company holds cryptocurrency treasury, that expectation applies even when the assets are held in non-custodial wallets. An auditor will ask for evidence that transfers were authorized, that the organization knows the balance, and that there is a process to verify that assets are still under the company’s control. A collection of seed phrases stored by individual employees does not satisfy that requirement. Multi-signature solutions and the limits of single-person browser wallets The most direct organizational safeguard is a requirement that significant transactions be signed by multiple parties. An enterprise using a single-key browser wallet has concentrated authority in whoever holds that key. If the key is compromised—by malware, social engineering, or insider action—no secondary check prevents the theft. Multi-signature wallets, such as those offered by Ambire and Braavos, partially address this problem. A multi-sig setup requires two or more signatories to approve a transaction before it is broadcast. If the organization sets a policy that all transfers above a threshold require approval from both a treasury manager and a compliance officer, neither person can unilaterally move assets. This raises the operational cost: each transaction requires coordination between multiple parties, and if a signer is unavailable, the process stalls. Yet multi-signature solutions introduce their own organizational complications. Someone must manage the recovery phrases for each signer’s key; if the treasury manager and compliance officer both store their phrases in insecure locations, the multi-sig architecture provides no real protection. The organization must decide: Do we store backup keys in a physical vault? In an encrypted secrets-management system? Who has access, and what is the process for recovering a signer’s key if they leave the company? Browser wallet implementations of multi-signature are also less flexible than dedicated enterprise solutions. An Ambire multi-sig wallet requires coordination through the browser extension, which means signers must be using compatible devices and have their wallets set up. If one signer is traveling without their usual computer, or if a device fails, approval can be delayed. Some enterprise systems use hardware wallets or offline signing to create stronger key isolation; browser wallets sacrifice some of that isolation in favor of convenience. Key management and organizational lifecycle events Personal security guides—including those on Safety-First Wallet—emphasize that an individual should never share their seed phrase, private key, or keystore file. That advice is sound for personal use. It becomes operationally paralyzing when an employee who manages cryptocurrency leaves the company, retires, or moves to a different role. If the departing employee holds the seed phrase in their personal safe or password manager, the organization faces a choice: Ask the employee to reveal the seed phrase (undermining the principle that seed phrases are never shared), attempt to recover access through the wallet provider (who has no organizational relationship with the company), or accept that the assets are now permanently inaccessible. All three options are unacceptable in an enterprise context. Proper key management for organizations requires a fundamentally different approach. Rather than entrusting a seed phrase to an individual’s memory or personal storage, the organization should use a vault or key-management system that allows authorized personnel to access keys without any single person needing to memorize or store them. Hardware security modules, encrypted key databases with access controls, and multi-party computation (MPC) schemes all serve this purpose—but none of them fit neatly into a personal

A user opens their phone and sees a notification: “MetaMask Alert: Unusual activity detected on your account. Verify now.” The message appears to come from MetaMask, includes official branding, and requests immediate action. The user taps through and finds a login screen that looks identical to the real application. Only after entering credentials does the reality become clear—the notification was fabricated, the screen was fake, and the private key is now compromised. This scenario repeats across thousands of users every week, each one convinced that MetaMask itself sent the alert. The fundamental problem is that MetaMask’s legitimate notifications and fraudulent impersonations often follow the same pattern: urgency, visual familiarity, and a call to action. Distinguishing between them requires understanding what MetaMask actually notifies users about, how those notifications function technically, and what characteristics reveal a phishing attack. A real price alert behaves differently from a fake account-recovery prompt. A genuine pending transaction notification comes from specific sources and contains verifiable details. Fake alerts exploit the speed of mobile interaction and the psychological weight of official-looking branding. What MetaMask actually notifies users about MetaMask sends notifications for a finite set of events, each tied to activity that the wallet can independently verify on the blockchain or within its own application state. The clearest legitimate notification is a pending transaction alert. When a user initiates a transaction—whether a token transfer, smart contract interaction, or network change—MetaMask displays a confirmation screen and may send a push notification when that transaction is submitted to the network and again when it is confirmed. Price alerts represent another category, but with important constraints. Users can enable notifications when assets they hold reach specified price thresholds. These alerts are triggered by price data that MetaMask sources from external APIs, typically services like CoinGecko or CoinMarketCap. A legitimate price alert will display the specific asset, the threshold that was crossed, and the current price. It will not ask for a password, recovery phrase, or account verification. The notification is informational; it does not require authentication to be useful. Activity notifications may also arrive when account state changes significantly—for instance, when a token balance increases unexpectedly or when a large gas spike is detected on the network. These are rare and secondary to the core functions. MetaMask’s core notification system does not include prompts asking users to verify identity, prove ownership, unlock access, or approve security actions in response to the notification itself. Any notification asking for those things is a phishing attempt, regardless of how authentic the branding appears. The technical source of legitimate MetaMask notifications is equally important. On mobile, the MetaMask mobile app itself generates push notifications through Apple’s or Google’s official notification systems. These notifications originate from MetaMask’s servers and arrive through the app’s legitimate push certificate. A notification that appears to come from MetaMask but was actually delivered through an SMS phishing campaign, email, or third-party social media account is fraudulent by definition. Users should verify that notifications arrive through the MetaMask app’s official notifications panel, not from browser extensions pretending to be MetaMask, counterfeit apps, or external messaging services. How phishing notifications exploit urgency and trust Phishing notifications succeed because they compress social engineering into a few seconds of interaction. The attacker creates visual parity with MetaMask’s real interface, adds language suggesting account danger or opportunity, and places a link or button that redirects to a fraudulent site. The entire exchange happens on a mobile screen where users are conditioned to tap quickly and authenticate without deliberation. Trust in the MetaMask brand is weaponized: because MetaMask is legitimate, a well-forged notification appears legitimate by association. Common phishing notification themes include account recovery (“Your recovery phrase has been flagged as compromised”), security verification (“Confirm your identity to restore access”), and opportunity exploitation (“Claim your airdrop—verify wallet now”). Each theme is chosen because it triggers a specific emotional response. Recovery-focused messages create fear. Opportunity messages create greed. Both bypass the analytical part of decision-making and push users toward immediate action. The notification is designed to be answered before it is questioned. The mechanics of delivery vary. Some phishing notifications arrive through compromised email accounts or SMS services impersonating MetaMask support. Others come through fake social media accounts, Discord servers, or Telegram groups that mimic official MetaMask communities. A particularly sophisticated attack involves installing a malicious app that mimics MetaMask’s interface and sends fake notifications from within that counterfeit application. Because the user granted notification permissions to what appeared to be MetaMask, the fake notifications appear to have the same system-level authority as real alerts. The redirect after tapping a phishing notification is where the actual theft occurs. The fraudulent site may present a login screen, password prompt, recovery phrase field, or transaction approval interface. It may be a pixel-perfect copy of MetaMask’s real screens, or it may contain obvious spelling errors and awkward phrasing that should trigger skepticism. The variation in quality suggests that attackers use both automated cloning tools and manual design work, meaning no single visual indicator reliably separates real from fake. The only reliable indicator is the source: whether the notification came through the official MetaMask app and whether the action it proposes matches MetaMask’s actual notification behavior. The difference between app notifications and browser-based alerts MetaMask operates in two primary environments: as a browser extension and as a mobile application. Each has different notification capabilities and different vulnerability surfaces. The MetaMask mobile app can send true push notifications through Apple’s or Google’s official notification infrastructure. These notifications arrive even when the app is closed, can display on the lock screen, and are cryptographically tied to the app’s official certificate. Only the legitimate MetaMask app can send notifications that display as “MetaMask” in the notification center. The browser extension version of MetaMask has more limited notification capabilities. It primarily uses in-app alerts and browser-level notifications, which are less persistent and less trusted by operating systems. A browser notification claiming to be from MetaMask could theoretically come from a malicious browser extension,

A user wants to hold Solana tokens, Ethereum assets, a Bitcoin position, and NFTs across multiple chains in a single wallet application. Phantom Wallet makes this technically possible. But the convenience of managing seven different networks—Solana, Ethereum, Base, Polygon, Robinhood Chain, Bitcoin, HyperEVM, and Sui—through one interface creates a practical problem that no amount of UI design can fully eliminate: when assets live on different blockchains with different transaction models, address formats, and finality guarantees, the likelihood of sending funds to the wrong destination, approving a malicious contract, or misunderstanding the cost of an irreversible mistake increases measurably. The core issue is not whether Phantom Wallet is secure in isolation. It is that multi-chain support encourages users to treat fundamentally different systems as interchangeable, and that substitution error—not the wallet’s cryptographic implementation—becomes the primary risk surface. A hardware wallet solves some of these problems through disconnection; an application that adds a seventh network does not. The real security question is whether the interface and user education can adjust fast enough to prevent the mistakes that now look plausible at scale. The mechanics of chain-specific address confusion Bitcoin addresses, Ethereum addresses, and Solana addresses are not created equal, even when they appear similar to a casual glance. A Bitcoin address may start with “1,” “3,” or “bc1” depending on the transaction type. An Ethereum address or any EVM-compatible chain address begins with “0x” and is 42 characters long. A Solana address is a base58-encoded string. These formats exist for a reason: they encode information about the network and prevent accidental or deliberate cross-chain transfer attempts. The security model begins to break down at the user level, not the protocol level. When Phantom displays an account balance and asks “where would you like to send this,” the wallet must assume the user knows which blockchain they are on. For experienced users operating Bitcoin on one phone and Ethereum on another, this assumption holds. For a single-device user managing seven networks in one application, the assumption becomes brittle. A user might copy a Bitcoin address from an exchange, switch network tabs in Phantom, and attempt to send Ethereum-based stablecoins to that Bitcoin address. The address format check should prevent this, but the wallet cannot distinguish between a deliberately chosen cross-chain transfer and a user error that originated three clicks ago. The Phantom browser extension and mobile versions present this challenge slightly differently. The browser extension may have clearer network indicators through tab context and address bar awareness. The mobile application, where Phantom is increasingly used, must convey network state more compactly. Neither interface can fully eliminate the human habit of copying, switching, and pasting in an order that does not match the user’s actual intention. Transaction preview features, which Phantom provides to show recipients and amounts before confirmation, are useful but incomplete. A preview shows the destination address and the amount, but a user who is already confused about which chain they are on will approve a transaction to the wrong address confidently. The preview confirms the user’s input rather than correcting the misunderstanding that produced it. Scam warnings, another Phantom security feature, are designed to catch obviously malicious destinations—but sending funds to one’s own Bitcoin address from an Ethereum account is not a scam. It is a loss. When account management becomes a liability Phantom’s account management tools include the ability to create multiple accounts, import addresses, and use watch-only addresses. These features serve legitimate purposes: managing separate contexts, recovering accounts, and monitoring positions without private key exposure. They also expand the surface area where confusion can take root. A user with five accounts across Phantom might maintain separate accounts for trading, long-term holding, and NFT operations. Each account has its own private key, recovery phrase, and address set. When the user receives a deposit instruction from an exchange or service provider, they may correctly remember they hold assets in Phantom but incorrectly recall which account they were using. Watch-only addresses compound this: a user might import a Bitcoin address from a hardware wallet to monitor the balance, then later become confused about whether that address is controlled by Phantom or the hardware wallet itself. The most dangerous pattern emerges when account switching becomes automatic. If Phantom defaults to a recently-used account or suggests an account based on transaction history, a user operating on autopilot may send funds to the wrong account within the same wallet. This is not necessarily irreversible—the funds belong to the same person—but it can create operational confusion when the intended recipient expects the deposit to arrive in a specific time or context. Multi-account support becomes genuinely valuable when combined with explicit naming, consistent address preview, and a friction step that requires the user to confirm the account name and chain before signing. Without these safeguards, the feature transforms from convenience into a reliable mechanism for sending funds to the right wallet but the wrong place within it. Hardware wallet connectivity and the false sense of completeness Phantom’s support for Ledger hardware wallets addresses one critical failure mode: a compromised computer or phone cannot directly steal private keys stored on the Ledger device. This is a genuine improvement over keeping private keys only on the internet-connected device. Yet hardware wallet integration through an application creates new decision points that users must evaluate correctly. When a user connects a Ledger device to Phantom, the Ledger becomes a signer; Phantom remains the interface and transaction composer. The Ledger will display the destination address and amount before the user confirms the transaction on the device. This two-step verification is valuable: a malicious version of Phantom could theoretically construct a transaction sending funds to an attacker’s address, but the Ledger would display that address and wait for the user to confirm it. The assumption is that the user can read an address correctly on the Ledger’s small screen and understand that it represents their intended destination. In practice, hardware wallet integration introduces another layer of interface complexity. A user must remember

A privacy-focused cryptocurrency user faces a recurring dilemma: most popular non-custodial wallets offer broad asset support and convenience but remain deliberately agnostic about privacy. They will hold Bitcoin, Monero, Zcash, and dozens of other assets in the same interface without optimizing for any of them. A user seeking to move between privacy coins, manage transparent and shielded addresses, or control transaction metadata must evaluate whether a general-purpose wallet like Guarda meets the actual threat model or whether dedicated alternatives such as Cake Wallet, Monero CLI, or Zcash-specific clients offer essential protections that are absent from broader platforms. That distinction matters because non-custodial architecture—where private keys remain on the user’s device rather than a company server—is a necessary but insufficient condition for privacy. The wallet’s data collection practices, default behaviors, network exposure, and feature design can either reinforce or undermine the privacy properties of the underlying asset. Understanding what Guarda actually protects, what it does not, and where its design decisions create risks or assumptions is essential for informed use rather than misplaced confidence in the interface alone. Non-custodial architecture does not equal anonymity or privacy Guarda is built on a non-custodial model, meaning the company does not hold private keys on centralized servers. This eliminates one important risk: the wallet provider cannot freeze accounts, seize funds, or use keys to authorize transactions without the user’s knowledge. Recovery phrases remain under user control, and the backup process is offline. That distinction separates Guarda from services such as Coinbase or Kraken, where the exchange controls funds and maintains customer records tied to regulatory compliance, payment details, and transaction histories. However, non-custody is only one part of a privacy analysis. A user can maintain exclusive control of private keys while the wallet application itself collects metadata, connects to third-party services, broadcasts transaction data unnecessarily, or defaults to transparent addresses and network patterns that undermine privacy. The question is not whether Guarda is custodial—it is not—but rather what visibility third parties gain during normal operation. Does the wallet contact Guarda’s servers with transaction details? Does it default to nodes or services that log IP addresses? Does it create patterns that chain analysis tools can recognize? These questions are often less visible than the headline feature of local key storage. Guarda’s platform breadth—available as desktop, mobile, web, browser extension, and supporting hundreds of cryptocurrencies and thousands of tokens—creates both operational convenience and complexity. A user can manage Bitcoin, Ethereum, Monero, Litecoin, Polygon assets, Avalanche tokens, and others in a single application. That eliminates the friction of opening separate wallets and managing multiple recovery phrases. It also means that the wallet’s default settings, node connections, and network behavior apply uniformly across assets that have fundamentally different privacy models. Bitcoin’s transparent public ledger, Monero’s ring signature obfuscation, Zcash’s optional shielding, and Litecoin’s basic layout each operate differently, yet they all route through the same application’s infrastructure. The practical implication is that convenience and privacy can be at odds. A feature that improves usability for Bitcoin holders—quick node selection, automatic network switching, or simplified address generation—may work against Monero users who depend on subaddress discipline or careful node choice. Guarda cannot optimize for all privacy models simultaneously, which means that users of privacy coins should examine whether the wallet’s defaults and capabilities actually support the specific asset’s intended use or whether they create friction, confusion, or leakage. Data collection, network exposure, and IP privacy Guarda’s privacy policy and technical design should be evaluated for three distinct types of exposure. First is data collection by Guarda itself: does the company log transaction details, IP addresses, wallet balances, or user identities? Second is exposure through wallet-to-node communication: when the wallet queries blockchain data or broadcasts transactions, is the request linkable to the user’s device or identity? Third is exposure through service integrations: if Guarda uses partners for exchange functions, price feeds, or blockchain services, what do those third parties see or collect? Guarda’s stated approach includes zero-knowledge architecture for certain operations and an emphasis on not storing transaction histories on company servers. However, the specific mechanics matter more than the general principle. When a user imports a Guarda crypto wallet, whether through browser extension, desktop, or mobile application, that instance connects to nodes and services to synchronize balances, retrieve transaction histories, and broadcast new transactions. The application must somehow determine which blockchain state is current, which requires contacting external infrastructure. For users prioritizing IP privacy, the wallet’s node configuration becomes critical. If Guarda connects directly to blockchain nodes via plain HTTP or TCP without encryption or proxy obfuscation, an IP address can be logged by those nodes or observed by network monitoring. If the wallet uses a custom node run by Guarda, all users’ requests may be routed through a single entry point, creating a visibility opportunity. If the wallet supports custom nodes or Tor integration, users can route connections through privacy infrastructure, but that depends on the user’s knowledge to enable it rather than being a default behavior. The web browser version introduces additional surface area. Browser-based wallets run within a web application, which means they operate in an environment where cookies, tracking scripts, service workers, and browser storage may be observed or manipulated. A user’s IP address, browser fingerprinting, and browsing pattern are visible to the web server and any intermediaries. While the wallet may not directly collect these details, the hosting environment does. For users concerned about IP-level privacy, desktop or mobile applications with Tor support may be preferable to browser instances. Privacy coins in a multi-asset wallet: support without optimization Guarda supports Monero, Zcash, Litecoin, and other privacy-oriented assets, but support does not mean the wallet is optimized for them. Monero’s privacy model depends on consistent use of subaddresses, careful node selection, and protection of the private view key. Zcash offers optional shielded addresses that can hide transaction amounts and recipient information. Litecoin includes optional privacy through confidential transactions or privacy protocols, depending on implementation. Each asset has specific best practices that the wallet user

A Phantom Wallet user with holdings across Solana, Ethereum, Base, and Polygon opens the application to check their net worth and finds no single number reflecting total portfolio value. The wallet displays individual token balances clearly enough, and NFT galleries render with metadata and floor prices where available. But the cumulative calculation—the sum of all assets converted to a single fiat currency—does not appear. This is not a bug. It is a deliberate limitation in how Phantom handles price data and portfolio aggregation, one that distinguishes it from some competing wallets and creates a practical gap for users who need real-time wealth tracking across multiple blockchains. Understanding why this gap exists requires examining how price feeds work, which networks Phantom prioritizes, and how multichain custody creates new data challenges. For users accustomed to centralized exchanges or all-in-one portfolio trackers, the absence of a portfolio total can feel like missing functionality. In reality, it reflects a set of trade-offs around data freshness, third-party dependencies, and the complexity of maintaining accurate prices across dozens of blockchain networks simultaneously. The wallet remains secure and functional without it, but users who need comprehensive wealth tracking must combine Phantom with complementary tools. The architecture behind Phantom’s per-chain design Phantom is organized as a self-custody, multi-chain wallet, meaning each supported blockchain maintains its own asset list, balance display, and transaction history within the application. When a user connects to Solana, they see SOL and Solana-native tokens. When they switch to Ethereum, the interface updates to show ETH, ERC-20 tokens, and Ethereum-specific details. This per-chain approach has advantages: it keeps network-specific logic separate, reduces the complexity of supporting tokens that may have similar names across different chains, and avoids unnecessary data synchronization that could slow the interface. However, it also creates a fragmentation problem at the aggregation layer. To display a portfolio total, Phantom would need to pull price data for every asset on every supported chain, convert them all to a common currency, and refresh that calculation frequently enough to remain useful. For a wallet supporting Solana, Ethereum, Base, Polygon, Bitcoin, and other networks, that means maintaining reliable price feeds for thousands of tokens across six or more distinct ecosystems. Decentralized price oracles, centralized APIs, and on-chain price data each have their own latency, accuracy, and availability characteristics. Phantom’s design decision appears to emphasize individual chain clarity over portfolio aggregation. The wallet displays balances with high confidence because each chain has canonical state that the Phantom client can verify. Price conversion introduces a third-party dependency. If Phantom relied on a single price API and that API failed or returned stale data, users might see incorrect totals without a clear way to verify them. By keeping price information local to individual tokens and letting users manually calculate, Phantom avoids broadcasting a potentially incorrect figure. This is a meaningful distinction from competitors that do attempt portfolio totals. Some wallets use weighted price feeds, fall back to multiple sources, or accept a margin of error in exchange for the convenience of a summary number. Phantom chose not to make that trade-off at the wallet level, which may reflect confidence in the security of self-custody but also suggests that portfolio tracking was not prioritized as a core feature. Why multichain custody complicates price feeds The moment a wallet supports assets on multiple blockchains, price accuracy becomes a coordination problem. Bitcoin on the Bitcoin network, Ethereum on Ethereum, Solana on Solana, and USDC on Base all have distinct prices that may diverge slightly due to network-specific market conditions, bridge premiums, or liquidity variations. A portfolio tracker must decide which price to use for a token that exists on multiple chains, how frequently to update, and what to do if different price sources disagree. Phantom’s approach to this problem is to delegate price responsibility to the individual token and network context. When the user views their Solana balance, any price display is tied to Solana-native pricing. For Ethereum holdings, Ethereum market data applies. This prevents a situation where Phantom claims that USDC on Polygon and USDC on Ethereum should have the same price when they may briefly trade at different rates on different exchanges or liquidity sources. The deeper issue is data freshness. A centralized exchange can update prices many times per second because all trading happens on the exchange’s matching engine. Phantom cannot do this for all tokens across all chains simultaneously. It would need to either poll multiple APIs (introducing latency and potential rate limiting), query on-chain oracles (introducing blockchain transaction costs and asynchronous updates), or accept that prices are necessarily stale. Real-time portfolio tracking at the wallet level therefore becomes a performance and data architecture problem, not simply a feature request. For high-value portfolios or users who need to monitor positions during volatile market conditions, this limitation is significant. A portfolio total that updates every minute during a 10% market move could be off by potentially thousands of dollars. Phantom’s decision to omit this feature rather than provide inaccurate data is defensible from a data integrity perspective, but it does create a gap that users must fill with external tools. Token balance display versus price information Phantom does display individual token balances with high accuracy because balance information comes directly from the blockchain. When a user views their Solana wallet, the displayed SOL amount reflects the on-chain account state. This is authoritative and needs no external confirmation. Similarly, ERC-20 token balances on Ethereum or Polygon are queried from the chain itself. Phantom’s balance display is reliable precisely because it does not depend on price feeds or any single point of external data. Price information is different. A token’s market price is not stored on the blockchain in a way that Phantom can simply look up. It must come from an external source: a price API, a decentralized exchange, a centralized exchange, or an on-chain oracle. Each of these sources has different update cadences, coverage, and reliability characteristics. Phantom’s decision to display prices selectively, or not to aggregate them,