Wallet Brand Landing vs Real Extension Scope (Wallet Brand Landing Vs Real Extension Scope)

A download button is not a signing engine

The wallet-app sells the Bare Wallet brand via Home plus Download tabs (Chrome, Firefox, Opera, Brave, Edge). public/manifest.json is Create React App's default PWA skeleton (short_name: React App, display: standalone) — there is no manifest_version, background service worker, chrome.runtime, or content script. This case study narrows scope on purpose: the product surface is a funnel; a real browser wallet is a different architecture universe.

What shipped (Bare Wallet app)
  CRA React SPA
    Home (brand)
    Download tabs (install CTAs)
    public/manifest.json  ← PWA sample, NOT MV3

What a real extension needs
  MV3 manifest_version: 3
    background service worker
    contentscripts / injected provider
    permissioned RPC + keyring
    popup UI ≠ marketing landing

This part writes the ADR for not confusing a brand landing with real extension scope.

Concepts, defined where they first appear

📦 Marketing SPA
Single-page app that sells trust and download CTAs before any wallet is installed.

📦 PWA Manifest
Installable-web hints; not the browser extension API surface.

📦 MV3 Extension
Manifest V3 add-on with service worker, permissions, and an injected page provider.

📦 Scope Honesty
Separating what the repo contains from what marketing copy implies.

Saying 'Install for Chrome' in the UI does not mean the repo contains chrome.scripting.

What is actually there?

Routes: Home and Download. DownloadPage shows tabbed CTAs; even some labels look swapped (iOS copy on a Brave tab) — a funnel prototype trace, not extension quality. No Web3 signing, keyring, or chain switching.

PWA ≠ Extension

CRA manifest.json carries icons, start_url, display: standalone. A Chrome extension needs manifest_version, background.service_worker, host_permissions, content_scripts. Drawing both as one system misleads readers.

ADR: Wallet product surface
  Decision: ship brand landing + download funnel only
  Non-goal: Chrome MV3 keyring / injected ethereum provider
  Why: marketing speed; wallet core is a different product
  Risk: users confuse CTA with installed extension
  Mitigation: honest copy + separate extension repo when real

Real extension architecture (contrast)

A production wallet needs a locked keyring, confirmation popup, window.ethereum / provider injection, network management, phishing warnings, update channel. The landing SPA carries none of that; claiming it does is a security debt.

Same honesty as the generator

The previous part keeps trait vocabulary explicit. This part keeps the product boundary explicit: Bare Wallet brand is a funnel. The case study does not inflate; readers who want MV3 need a separate architecture series — not a lie in this repo.

The mappings that get confused most often

❌ CRA manifest = Chrome extension
✓ PWA hints ≠ MV3 extension contract

❌ Download CTAs prove an extension exists
✓ CTAs are marketing; runtime APIs are proof

❌ Naming the landing 'wallet' means keyring
✓ The name is brand; scope is bounded by ADR

❌ Inflating scope to grow the portfolio
✓ Honest narrow scope is a trustworthy case study

A checklist for auditing your own system

1. Does the repo mention manifest_version or chrome.runtime?
2. Do download buttons hit real store URLs or dead CTAs?
3. Which user promise do PWA manifest fields actually meet?
4. What security misunderstanding arises if a user thinks they 'installed' it?
5. Is a separate repo/ADR drawn for a real extension?

What to take away from this part

1. The Bare Wallet app is a brand landing / download funnel.
2. A CRA PWA manifest is not MV3 extension evidence.
3. Honest scope beats an inflated wallet claim.

Writing 'wallet' and being a wallet are not the same commit.