MegaWallet

I did not inherit a blank wallet; I inherited 217 days of direction debt

Git shows the repository starting on June 5, 2025. By my first core refactor on January 8, 2026, 217 days and 836 commits had accumulated. Expo / React Native arrived in June, then Electron in September; the first desktop build literally copied mobile/dist into the renderer. Solana keyrings, signing, RPC, transactions, and Wallet Standard grew through June–August, while the old Solana Send UI was removed on February 12. Platform and chain scope changed before their boundaries were settled, so earlier assumptions kept stacking.

• Expo / RN was the first host; Electron later reused the mobile web output
• Solana moved from explicit investment to an EVM-only product Send path while foundation code remained
• Requirement changes had no new boundary, so they kept modifying handlers, bridges, and Service
• Spaghetti code was the consequence of direction debt, not one ugly function

Seven documents made the two-month rebuild adoptable by the team

The seven documents covered the Wallet-Core mental model, architecture risks, DApp requests, the Send design review, address validation, and wallet permissions. Document 08 recorded two independent changes: splitting Service into frontend and backend paths for Electron / Extension, and moving chain capability out of crypto, vault, and utils/rpc into chain-kit. They were written for product, design, and engineering before implementation decisions hardened, so each change had shared, reviewable context.

Start with Provider / RPC: independent and easier to adopt

Provider and DApp RPC touched every host and chain, but remained relatively independent from UI, assets, and storage. That made them replaceable, testable in isolation, and easier to reconnect incrementally. The old Provider used four inheritance layers to combine EVM state, compatibility methods, events, and platform communication before ending at globalThis.$jsBridge. I replaced it with independent EthereumProvider and SolanaProvider implementations: each owns its state and events, while host communication enters only through Transport. Provider no longer knows the concrete RN, Electron, or Extension API.

The same refactor: request policy in rpc-engine

The old path entered service/src/dapp/request.ts, called getHandler(base), and constructed an EVM or Solana Handler for every request. Permission, lock behavior, approval prompts, and RPC fallback remained inside individual methods. New permissions meant editing each method; duplicate prompts required pendingApprovals in handleRequest; a new chain changed Handler classes, maps, types, and base branches. rpc-engine now runs blacklist, logging, error boundaries, permission, CAIP scope, dedupe, lock, and executor in a fixed order, including five protections that did not exist before. Each request ends in a wallet handler, user approval, or RPC proxy.

Transport: keep host communication out of Provider

The old architecture split Provider and JS Bridge across two packages. ProviderDelegate depended on globalThis.$jsBridge; the mobile Bridge hard-coded ReactNativeWebView.postMessage, the desktop Bridge hard-coded Electron IPC, and each host needed another buildInject assembly script. A new platform changed both packages, while tests mocked global host objects. Provider now has no host knowledge: React Native, Electron, and Extension each implement a Transport adapter. Supporting another platform means adding one Transport, and tests replace only the interface.

After the independent layer was done, the main-project foundation became the blocker

Provider and rpc-engine were complete and reconnected to Service by January 15. Moving them into RN, Electron, and web then exposed the missing host foundation: Electron had no React HMR, WebView DevTools interfered with reload, and cross-host runtime entry points were incomplete. I completed those paths because a refactor is not done when old code disappears; it is done when the new backbone can be developed, debugged, and run inside the real app.

UI and foundation work interleaved; this was not a waterfall

After establishing Provider / RPC, I connected product flows incrementally. Send and useAddressValidation landed on January 28. Permission / DApp and the process-aware Service architecture were authored on February 10; chain-kit followed on February 12. Relatively independent modules could be delivered and reconnected early, making each change easier for the team to adopt. UI delivery continued alongside work on permission, state authority, and chain capability.

Electron is two programs, but wallet state needs one owner

The project began with React Native, so Service was organized to run directly inside one frontend runtime. Electron later reused the mobile web output and startup model without first defining one main / renderer authority. Renderer is the frontend the user sees; main is the wallet backend that can access local storage, networks, and keys. Their memory is not shared. The old code therefore imported and started Service on both sides, producing two unrelated wallets with the same package name. I moved full Service, RPC Engine, SQLite WAL storage, and signing into main as the only real state, while renderer keeps a sanitized mirror. User actions cross IPC to main; state changes return as Immer patches, with a full snapshot when patch application fails.

Consolidate scattered chain logic and false abstractions together

chain-kit was not a directory rename. crypto, vault, and utils/rpc became one function-based chain package; Transfer merged into Tx; the Nonce Service, which never provided its implied concurrency safety, was removed in favor of pending nonce; actions and selectors became write and read boundaries; Zod schemas became runtime validation and type sources. Separately, Signer clears its own Uint8Array buffers after use. Temporary library strings remain an explicit JavaScript limitation; that security enhancement is not evidence of chain-capability consolidation.

Durable connections and one-time approvals are different kinds of state

When a site connects, it needs a durable pass recording the site, chain, and visible accounts. Signing, transfers, network changes, and asset requests need only a one-time decision. Connector stores the durable relationship; ApprovalQueue holds the current request and destroys it after approval, rejection, or timeout. Connect, Sign Message, Send Transaction, Switch / Add Network, Watch Asset, and Solana confirmation screens all use this single flow.

Send proves the product-definition work

In Figma, the Recipient Picker list state was 378×406 and the complete-address state 378×210. The issue was not merely animation: should the input search contacts or validate an address first? I defined typing, settled, complete, validating, and valid / invalid states, then composed address, domain, self-transfer, contract, address-book, and recent-recipient validators. A fixed three-row list, 64px result area, 300ms debounce, and 600ms settled hint turned continuous jumping into one meaningful transition.

A stopped project should not be rewritten as a launch story

This was not a greenfield wallet built in two months. It was incremental replacement inside 217 days and 836 prior commits. The current source contains the independent Provider / Transport, configurable RPC pipeline, a cross-host request backbone reconnected to Service, DApp connection and confirmations, main-authoritative Service, chain-kit, Send, and address validation. The project did not reach market launch, but platform, chain, state, permission, secret, and UI ownership had become explainable.