Skip to content

Instantly share code, notes, and snippets.

@roninjin10
Created February 2, 2026 21:36
Show Gist options
  • Select an option

  • Save roninjin10/7b5fad062c0c328e453353ea7573d9cf to your computer and use it in GitHub Desktop.

Select an option

Save roninjin10/7b5fad062c0c328e453353ea7573d9cf to your computer and use it in GitHub Desktop.
Misty Browser for Base

Misty Browser for Base — Product Requirements Document

Status: Draft (v0.2) Owner: Product/Eng Last updated: 2026-02-02 Platforms: macOS (Electrobun) Default chain: Base mainnet (chainId 8453)


1. Executive summary

Misty is a native, Base-first Web3 browser that lets users browse the web and complete onchain tasks (swap, send, sign, approve, mint) without leaving the browser. The primary UI is a conversational agent (home screen) that can render safe, typed, interactive UI components, not just text. The browser includes a built-in wallet, an integrated explorer, and transaction simulation.

Indexing strategy: Misty uses TrueBlocks for local-first, private blockchain indexing. Since building the local index takes time, Misty falls back to Index Supply until the local index catches up. Once TrueBlocks is synced, all queries stay local.


2. Problem

Today, Base users rely on:

  • A standard browser + a wallet extension
  • Separate block explorer tabs
  • Separate simulation tools (if any)
  • Fragmented UX and high signing risk

Key pain points:

  1. Context switching: dApp → wallet popup → explorer → back
  2. Phishing risk: fake sites, malicious approvals, no way to verify what you're signing
  3. Low trust signing: unclear calldata, unknown contracts, unlimited approvals
  4. History is inconsistent: token transfers/approvals require third-party APIs
  5. App discovery: hard to find quality dApps, no trusted catalog
  6. Locked into developer UIs: users can't build their own interfaces on top of open contract standards — they're stuck with whatever UI the developer ships
  7. Users want intent-based actions ("swap 0.1 ETH for USDC") rather than multi-step UI navigation

3. Target users

Primary: The "intender"

Users who want to use the chain but find current UX too friction-heavy:

  • Have some funds and general interest in Base
  • Get blocked by complexity — too many steps, confusing UIs, unclear what to do next
  • Would engage more if discovering and doing things were easier
  • Prefer saying what they want over navigating multiple apps

The agent-first UI is built for this user: just describe your intent and Misty handles the rest.

Secondary

  • Privacy-conscious users who want local-first data (no third party sees their queries)
  • Power users who want transaction simulation and detailed inspection

4. Goals and non-goals

Goals

  • Make Base onchain tasks fast, safe, and explainable
  • Reduce signing risk via simulation + decoding + warnings
  • Provide an agent UI that can produce runnable interfaces (not just advice)
  • Provide a built-in explorer that is "good enough" for daily use
  • Local-first indexing via TrueBlocks, with Index Supply fallback during sync

Future

  • Hardware wallet support
  • Mobile / Windows / Linux
  • Sync across devices
  • Full multi-chain support (Base is primary for v1)
  • Companion browser extension

Companion browser extension

A browser extension that brings Misty functionality to Chrome/Firefox/Safari. The extension requires the full Misty app to be installed — it's not standalone.

How it works (Frame-style architecture):

  • Misty runs a local WebSocket/HTTP server on 127.0.0.1:1248
  • The extension injects window.ethereum into web pages
  • All provider requests route back to Misty via localhost
  • Signing, simulation, and approval happen in the native Misty UI
  • Private keys never touch the browser — only the native app

What the extension enables:

  • Use Misty wallet on any dApp in Chrome/Firefox/Safari
  • Get transaction simulation even outside the Misty browser
  • Unified permission management across all browsers
  • "Appear as MetaMask" mode for dApp compatibility

User flow:

  1. Install Misty desktop app
  2. Install Misty Companion extension from browser store
  3. Extension auto-detects running Misty app
  4. dApp requests route to Misty → user approves in native UI → result returns to dApp

5. Product principles

  1. No compromises UX: Safety and speed, not safety or speed
  2. Explain, then act (decode + simulate before confirmation)
  3. Typed UI only for agent-rendered components (no arbitrary HTML)
  4. Base-first defaults everywhere (network, explorer views, app catalog)
  5. Local-first: TrueBlocks indexes locally by default, with Index Supply as fallback during sync
  6. User-consented updates: server-side data (labels, app catalog, blocklists) syncs only with explicit user approval — user can review what changed before accepting

6. Key experiences

6.1 Home: Agent + autocomplete + browser (primary surface)

The home input is a unified bar that handles:

  • URLs — browse to any website (full browser)
  • ENS / Basenames — resolve and navigate (e.g., vitalik.eth, jesse.base.eth)
  • Built-in apps — type /send, /swap, /velodrome, etc.
  • Quick actions — clickable shortcuts (swap, send, check balance)
  • Free-form questions — go to the agent

Built-in apps: Native interfaces for top Base protocols. Users type /name to launch.

Core utilities:

  • /send — Send tokens
  • /swap — Token swap (via Coinbase CDP Swap API or Aerodrome)
  • /bridge — Bridge assets (Superbridge, Across, Relay)
  • /buy — Fiat onramp (Coinbase Onramp — zero fees for USDC)
  • /sell — Crypto offramp (Coinbase Offramp)
  • /approvals — Manage token approvals
  • /wrap — Wrap/unwrap ETH

DeFi (by TVL/usage):

  • /aerodrome — Aerodrome (dominant DEX, $600M+ TVL)
  • /morpho — Morpho (largest lending, $5B+ TVL)
  • /uniswap — Uniswap
  • /moonwell — Moonwell (lending)
  • /seamless — Seamless Protocol (lending)
  • /compound — Compound
  • /synthetix — Synthetix Perps
  • /avantis — Avantis (derivatives)

NFTs/Social:

  • /zora — Zora (NFT minting, 1.6M+ tokens minted)
  • /opensea — OpenSea
  • /farcaster — Farcaster social
  • /virtuals — Virtuals Protocol (AI agents)

Identity/Other:

  • /basename — Claim/manage Basenames
  • /ens — ENS lookup
  • /safe — Safe multisig
  • /stake — cbETH staking

Coinbase integrations (prioritized):

  • Coinbase Onramp/Offramp for fiat (zero-fee USDC)
  • Coinbase Paymaster for gasless transactions
  • Coinbase Smart Wallet support
  • Coinbase Verifications for onchain KYC attestations

Agent capabilities:

  • Read onchain state
  • Explain transactions
  • Simulate before signing
  • Render typed UI components inline
  • Execute transactions only with explicit confirmation

LLM configuration:

  • Default: Cloud model (best quality)
  • Optional: "Use local model" button downloads and installs model for full privacy
    • Recommended: Qwen3-8B (best speed/accuracy balance, F1: 0.933 on tool calling)
    • Runs via Ollama on Apple Silicon Macs

Conversation history persisted locally + searchable.

6.2 Browser: full browsing + Web3 provider injection

  • Full tabbed browser, URL bar, bookmarks, history
  • Inject window.ethereum (EIP-1193) into webviews
  • Handle connect/sign/send with Misty overlays (not popups)

ENS resolution behavior:

When user enters an ENS name (e.g., vitalik.eth):

  1. If the ENS has a URL record → navigate to that website
  2. Show a small indicator/popup: "This is vitalik.eth's website — [View ENS profile]"
  3. Clicking "View ENS profile" opens the ENS explorer page (address, records, etc.)

This lets users browse ENS-linked websites while still being able to inspect the underlying ENS.

6.3 Wallet: Coinbase Smart Wallet native

This is a flagship feature. Misty's wallet is built on Coinbase Smart Wallet (ERC-4337), giving users account abstraction benefits while maintaining full self-custody.

Smart Wallet benefits:

  • Gasless transactions — sponsored via Coinbase Paymaster
  • Batch transactions — multiple actions in one signature
  • Same address on all chains — deterministic deployment
  • Passkey support — Face ID / Touch ID, no seed phrase required
  • Social recovery — add backup owners (other devices, trusted contacts)
  • Session keys — grant limited permissions to dApps

Supported owner types:

  • Passkeys (P-256) — create wallet with just biometrics, no seed phrase
  • HD wallet (secp256k1) — import existing mnemonic, EOA becomes Smart Wallet owner
  • Mix both — passkey for daily use, HD wallet as backup

Key flows:

  • New user → create with passkey (zero friction onboarding)
  • Existing user → import mnemonic → deploy Smart Wallet owned by that EOA
  • Power user → multiple owners (passkey + hardware wallet + recovery contact)

Recovery policy (v1):

Passkey-only wallets risk permanent loss if the device is lost. v1 requires:

  • Onboarding prompt: After passkey wallet creation, immediately prompt "Add a backup owner" with options:

    • Add second device passkey
    • Import seed phrase as backup owner
    • Skip (with explicit warning: "If you lose this device, you lose access to your wallet")
  • Soft gate: If user skips backup and wallet balance exceeds threshold (e.g., $100), show persistent reminder banner: "Add a backup owner to protect your funds"

  • Recovery options available in v1:

    • Add additional passkey (another device)
    • Add HD wallet (seed phrase) as owner
    • Add another EOA address as owner

Future: Additional recovery options

  • iCloud backup — encrypted backup enabling wallet recovery
  • Social recovery — trusted contacts can help recover
  • Additional methods TBD

Traditional wallet features (still supported):

  • Create/import HD wallet (BIP-39/BIP-44)
  • Multi-account derivation
  • Transaction/message signing (EIP-191 / EIP-712 / EIP-1559)
  • Approval management
  • Local encrypted storage + auto-lock

6.4 Safety flows

This is critical infrastructure.

There are two distinct safety flows depending on the request type:


6.4.1 Transaction / UserOp safety (fork simulation)

Every eth_sendTransaction or UserOperation goes through:

1. Decode

  • Parse calldata using known ABIs (top Base protocols)
  • For unknown contracts: 4-byte selector lookup + parameter extraction
  • For Smart Wallet UserOperations: decode inner transaction(s)
  • Show human-readable summary: "Swap 1.5 ETH → 3,200 USDC on Aerodrome"

2. Simulate

  • Fork Base at current block via Tevm
  • Execute transaction in forked state
  • Extract state diffs: token transfers, approval changes, ETH deltas
  • Simulation must succeed — if RPC fails, retry with fallback endpoints
  • Cache fork state for fast repeated simulations

3. Show deltas & warnings

Always show:

  • Token balance changes (with USD values)
  • ETH balance change
  • Approval changes (new, modified, revoked)
  • Gas cost estimate

Warnings (with severity levels):

Severity Warning Description
Critical Unlimited approval Approving max uint256 to spender
Critical Drain risk Transaction sends all tokens to external address
Critical Known phishing Contract/domain on blocklist
High Unverified contract No source code on explorer
High New contract Deployed < 7 days ago
High Approval to EOA Approving tokens to a non-contract
Medium High slippage > 5% value loss detected in simulation
Medium Unusual gas Gas estimate 10x higher than typical
Low First interaction Never interacted with this contract before

4. Confirm

  • User reviews simulation results
  • Critical/High warnings require explicit acknowledgment (checkbox)
  • "Confirm" button disabled until simulation completes
  • Show which owner will sign (passkey icon vs key icon for Smart Wallets)

Expected failure modes (show clear explanations to user):

Failure User-facing message What it means
Insufficient balance "You don't have enough ETH/tokens for this transaction" User needs to fund wallet
Insufficient gas "This transaction will fail — not enough ETH for gas" Need more ETH for fees
Reverts with reason "Transaction will fail: {reason}" (e.g., "INSUFFICIENT_LIQUIDITY") Contract rejected the call
Reverts without reason "Transaction will fail (no reason provided)" Contract reverted silently
Nonce too low "Transaction outdated — you have a pending transaction" Previous tx not confirmed yet
Gas estimate too high "Transaction may fail — gas estimate exceeded limit" Likely to revert

Infrastructure failures (retry silently, only show if persistent):

Failure Response
RPC timeout Retry with fallback RPC (up to 3 attempts)
Fork state stale Re-fork at latest block, re-simulate
RPC rate limited Switch to backup endpoint

Edge cases:

Situation Response
Unknown calldata Show raw hex with "Unable to decode" note, still simulate
Simulation takes > 5s Show "Simulating..." spinner, never timeout
All RPCs fail Show "Simulation unavailable — network issue" with option to retry or proceed with extra warning

Never block the user entirely — if all else fails, show "Simulation unavailable" with extra confirmation gate, but allow proceeding. Always explain why something failed in plain language.


6.4.2 Signature safety (EIP-191 / EIP-712 analysis)

Message signatures cannot be fork-simulated — they're analyzed structurally instead.

For EIP-191 (personal_sign):

  • Show the raw message content
  • Warn: "This signature could authorize actions elsewhere"
  • Flag if message looks like a transaction hash or hex data

For EIP-712 (typed data):

  • Parse and display the structured data
  • Show domain (name, version, chainId, verifyingContract)
  • Highlight the primary type and key fields

Signature-specific warnings:

Severity Warning Description
Critical Permit / Permit2 Signing token approval — spender can transfer tokens
Critical Allowance by signature Authorizing spending without onchain approval tx
Critical Delegation Signing delegation or session authorization
High Domain mismatch EIP-712 domain doesn't match requesting origin
High Replay risk Missing or suspicious chainId, nonce, or verifyingContract
High Blind signature Unrecognized typed data structure
Medium Unknown verifyingContract Contract not in known protocol list
Low First signature for domain Never signed for this domain before

Known pattern detection:

  • Permit (ERC-2612)
  • Permit2 (Uniswap)
  • Seaport orders (OpenSea)
  • CoW Protocol orders
  • Safe transaction signatures
  • Session key authorizations

Display requirements:

  • Always show the requesting origin prominently
  • For permits: show token, spender, amount, deadline
  • For orders: show what you're selling, what you're receiving
  • For delegations: show what permissions are being granted

6.5 Explorer + history (Base-first)

  • Built-in explorer views for tx/address/token/NFT
  • TrueBlocks for local-first indexing, Index Supply as fallback

Smart Wallet aware:

  • Detect Smart Wallet contracts and show "Smart Wallet" badge
  • Show owners (passkeys, EOAs) and their permissions
  • Decode UserOperations — show the inner transaction, not just calldata
  • Track account abstraction activity: bundler submissions, paymaster sponsorships
  • Link to owner addresses (both passkey identifiers and EOA addresses)

AI-powered labeling service:

  • Background AI agent continuously researches unlabeled addresses
  • Identifies: protocol contracts, known wallets, token contracts, NFT collections, multisigs
  • Sources: verified contracts, ENS/Basenames, social links, onchain activity patterns
  • Labels stored locally and improve over time
  • User can override or add custom labels
  • Show confidence level: "Verified" (onchain proof) vs "AI labeled" vs "User labeled"

Server-side label sync (user-consented):

  • Misty publishes curated label updates (new protocols, known scams, etc.)
  • User sees "Update available: 47 new labels" notification
  • User can review changes before accepting: see what's added/changed
  • Updates never auto-apply — user must explicitly accept
  • User can reject individual labels or entire update

Token pages:

  • Price (from CoinGecko/DeFiLlama)
  • Holders and distribution
  • Liquidity pools
  • Transfer history

Contract pages:

  • Verified source code (from Basescan)
  • Read/write contract interface
  • ABI download

NFT display:

  • Collection pages with floor price, volume
  • Individual NFT with metadata, traits, ownership history
  • Render images/videos inline

7. Functional requirements

7.1 Agent home

Must

  • Chat UI with persistent history + sidebar
  • Agent tool-calling for wallet/explorer/simulation actions
  • Agent can render UI components (swap card, tx details card, confirm drawer)

Should

  • Search across conversations
  • Export/share conversation transcript (redacting sensitive info)

Won't (v1)

  • Autonomous actions without confirmation

7.2 Wallet

Must

  • Coinbase Smart Wallet as default — ERC-4337 account abstraction
  • Passkey support — create wallet with Face ID / Touch ID, no seed phrase
  • HD wallet support — import existing mnemonic, EOA becomes Smart Wallet owner
  • Gasless transactions via Coinbase Paymaster
  • Send/receive ETH + tokens
  • Sign message / typed data / tx (route through Smart Wallet)
  • Auto-lock; wipe decrypted key material on lock
  • Permissions per-origin (connect, sign, send)

Should

  • Multiple owners — add passkey + HD wallet + recovery contact
  • Batch transactions — multiple actions in one signature
  • Labels/notes per account
  • Approval management UI (scan approvals, revoke)
  • Session keys — grant limited permissions to dApps

Won't (v1)

  • Hardware wallet as owner (future)
  • Cross-device sync (each device has own passkey)

7.3 Browser + Web3 provider

Must

  • Tabs, nav controls, URL bar, bookmarks/history/downloads
  • ENS / Basename resolution in URL bar
  • EIP-1193 provider injection into webviews
  • Smart Wallet aware provider — handle UserOperations, gasless transactions
  • Overlays for connect/sign/send with origin shown and verified
  • Simulation before every transaction (same safety loop as wallet)

Should

  • ENS website navigation — if ENS has URL record, go to site + show "View ENS profile" option
  • EIP-6963 provider announcement (multi-wallet discovery)
  • "Appear as MetaMask" mode for dApp compatibility
  • Companion browser extension — use Misty wallet in Chrome/Firefox/Safari
  • Per-site settings (auto-connect, gas preferences)
  • Multiple browser profiles (separate contexts, different wallets)

Won't (v1)

  • Browser extensions/plugins inside Misty

7.4 Simulation + decoding

See Section 6.4 Transaction safety loop for full details.

Must

  • Simulate every eth_sendTransaction before signing — no exceptions
  • Decode calldata (known ABIs + 4-byte fallback)
  • Decode UserOperations for Smart Wallets (show inner transaction)
  • Display state diffs: token transfers, approval changes, ETH deltas
  • Show warnings by severity (Critical / High / Medium / Low)
  • Handle failures gracefully — retry RPCs, show clear error messages
  • Never block user entirely — worst case allow proceeding with extra confirmation

Should

  • Compare simulated vs actual for completed txs (detect discrepancies)
  • Share simulation link (internal deep-link)
  • Cache fork state for fast repeated simulations

7.5 Explorer (Base-first)

See Section 6.5 Explorer + history for full details.

Must

  • Tx details: decode, logs, internal calls (when possible), fees
  • Address details: txs, token transfers, balances, approvals summary
  • Smart Wallet aware: detect Smart Wallets, show owners, decode UserOperations
  • AI-powered labeling: background research for unknown addresses
  • User-consented label sync: review server-side label updates before applying
  • Token pages: price, holders, liquidity
  • Contract pages: verified source code, read/write interface
  • NFT display: collections, individual NFTs with metadata

Should

  • L2 fee + L1 fee/batch metadata (best-effort)
  • Compare simulated vs actual state changes for historical txs
  • Export transaction history (CSV)

Won't (v1)

  • Full analytics dashboards (charts, graphs)
  • Custom API access for external tools

7.6 Indexing / history

  • Extremely fast, local-first UX
  • Product is usable immediately without a sync step

7.7 ENS + Basenames

Must

  • Resolve .eth names in URL bar, address displays, search
  • Resolve .base.eth Basenames in URL bar, address displays, search
  • Reverse resolution — show name next to addresses everywhere
  • Multi-chain address records — resolve Base-specific address if set (coinType 2147492101)
  • Cache resolutions locally for speed
  • Handle resolution failures gracefully (show address if name fails)

Should

  • Avatar resolution — show ENS/Basename avatars in UI
  • Text records — show description, Twitter, URL, etc. on profile pages
  • Primary name detection — if address has primary name set, always display it
  • Basename registration UI — /basename app for claiming names
  • ENS profile viewer — /ens app for viewing any ENS name's records

URL bar behavior:

Input Action
vitalik.eth Check URL record → if exists, navigate to website + show ENS indicator
vitalik.eth (no URL) Open ENS profile page in explorer
jesse.base.eth Same logic for Basenames
0x1234... Open address page in explorer

8. Metrics

Analytics are on by default (opt-out available in settings). Metrics are privacy-respecting — usage patterns only, no addresses or transaction data.

Activation

  • Wallet create/import completion rate
  • Time-to-first-successful onchain task

Engagement

  • DAU/WAU
  • Tasks completed per session (swap/send/sign/view tx)
  • Explorer queries per user

Safety

  • % of tx confirmations preceded by simulation
  • Warning rate (unlimited approvals, suspicious)
  • User cancels after warning (proxy for prevented mistakes)

References

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment