> For the complete documentation index, see [llms.txt](https://wallet-docs.catfee.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wallet-docs.catfee.io/catfee-air-wallet.md). # CatFee Air Wallet CatFee Air Wallet is CatFee's Chrome MV3 browser extension. It exposes a provider for TRON DApps that is designed to be as compatible with TronLink as possible, while also exposing `window.ethereum` / EIP-1193 provider support for EVM DApps. When private-key signing is required, the extension does not store or use private keys in the browser. Instead, it converts signing requests into an offline QR-based flow handled by `Offline Signer`. ## Product Goals The project is intentionally focused on a narrow set of goals: * Allow mainstream TRON DApps to invoke the extension and complete connection approval * Allow ETH / EVM DApps to connect, sign messages, sign transactions, and send transactions through `window.ethereum` * Route DApp transaction signing and message signing through offline phone-based signing * Minimize sensitive browser-side data and store only addresses, networks, and DApp authorization relationships ## Security Boundary The extension does not store private keys, generate private keys, import seed phrases, or rely on an online backend to complete DApp signing on the user's behalf. The extension stores only: * The list of TRON signing addresses and the current default TRON address * The list of EVM signing addresses and the current default EVM address * The current TRON network and current EVM network * Authorized DApp origins and the address bound to each site * Discovered and disconnected DApp origin states Each DApp origin records the address selected during authorization. If the user later changes the default address on the extension home screen, the address already granted to an existing DApp origin does not change silently. Transaction signing and message signing still require an approval window each time, and the result is returned only after QR-based signing in `Offline Signer`. ## User Guide ### Add And Select Addresses After opening the extension popup, users can add an ETH `0x...` address or a TRON base58 address by clicking `+` in the upper-right corner. They can also go to: ``` Settings -> Wallet Management ``` The wallet management page is used to add, select, or delete addresses. The home screen is mainly for displaying the current address and switching it quickly. Address creation and deletion remain centralized in wallet management. These are signing addresses, not private keys. The actual private keys remain on the phone in `Offline Signer`. ### Switch Networks Network configuration is available at: ``` Settings -> Network ``` After switching networks, the extension updates the `chainId`, TRON node endpoint, EVM RPC configuration, and provider state exposed to the DApp. Ethereum Mainnet is built in for EVM. Users can also add custom EVM networks by entering the network name, `chainId`, RPC URL, and native currency symbol. Custom EVM networks reuse the current ETH / EVM offline signing foundation and are suitable for onboarding EVM-compatible chains such as HyperEVM. ### Connect To DApps In a DApp, the user selects a TronLink or browser wallet connection option. The extension emulates a TronLink-style provider, and a connection approval window opens when the DApp initiates the request. After approval: * The DApp can read the authorized address for that session * The extension remembers the site origin and the authorized address * The same origin can restore its connection later without prompting again * After the user disconnects, that origin is marked as disconnected to avoid automatic reconnection from ads or background pages ### TRON Transaction Signing When a DApp calls `tronWeb.trx.sign(transaction)` or `tronWeb.trx.multiSign(transaction)`, the extension opens a transaction approval window. The flow is: 1. The extension reads the TRON transaction provided by the DApp 2. It calculates `tx_id = sha256(raw_data_hex)` from `raw_data_hex` 3. If the DApp provides `txID`, the extension validates that it matches the calculated result 4. The extension generates an `xcoin-wallet-protocol/v2` protobuf envelope QR code 5. The user signs it with `Offline Signer` on the phone 6. The user scans or pastes the returned signing result back into the approval window 7. The extension parses the v2 `SignatureResult` and validates the signer and transaction digest 8. The extension appends the signature to `transaction.signature[]` and returns the signed transaction to the DApp ### TRON Message Signing When a DApp calls `tronWeb.trx.signMessageV2(message)` or a compatible entry point, the extension calculates the TronWeb v2 message digest: ``` keccak256("\x19TRON Signed Message:\n" + byteLength(message) + message) ``` The extension generates a v2 `MessageRequest`, the phone returns a v2 `SignatureResult`, and the extension validates the signer and message digest before returning a `0x`-prefixed hexadecimal signature to the DApp. ### ETH / EVM DApp EVM pages can connect through `window.ethereum` or an EIP-6963 provider announcement. The extension currently supports: ``` ethereum.request({ method: "eth_requestAccounts" }) ethereum.request({ method: "eth_accounts" }) ethereum.request({ method: "eth_chainId" }) ethereum.request({ method: "net_version" }) ethereum.request({ method: "wallet_getPermissions" }) ethereum.request({ method: "wallet_requestPermissions" }) ethereum.request({ method: "wallet_revokePermissions" }) ethereum.request({ method: "wallet_disconnect" }) ethereum.request({ method: "wallet_switchEthereumChain" }) ethereum.request({ method: "wallet_addEthereumChain" }) ethereum.request({ method: "personal_sign" }) ethereum.request({ method: "eth_sign" }) ethereum.request({ method: "eth_signTypedData_v3" }) ethereum.request({ method: "eth_signTypedData_v4" }) ethereum.request({ method: "eth_signTransaction" }) ethereum.request({ method: "eth_sendTransaction" }) ``` For EVM message signing, the extension generates a v2 `MessageRequest`: `personal_sign` / `eth_sign` use `MESSAGE_PERSONAL`, while EIP-712 typed data uses `MESSAGE_TYPED_DATA`. For EVM transaction signing, the extension first fills nonce, gas, and fee fields, generates an unsigned transaction signing payload, and passes it to the phone through a v2 `TransactionRequest`. `eth_signTransaction` returns a signed raw transaction, while `eth_sendTransaction` broadcasts the signed raw transaction and returns the transaction hash. ### Manage Connections And Language Go to: ``` Settings -> Manage Connections ``` There, users can inspect discovered or connected DApps and remove a site's authorization relationship. Language settings are available at: ``` Settings -> Language ``` The default language is English, with support for both English and Chinese. The language setting is stored locally and persists after refresh. Version information is available at: ``` Settings -> About ``` The About page shows the app version, code version, build number, branch, and build time. The code version is typically displayed as a short hash, while the full hash remains available in the title information. ## Related Notes * To understand what data the extension collects and stores, read the [Privacy Policy](/catfee-air-wallet/privacy-policy.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://wallet-docs.catfee.io/catfee-air-wallet.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.