# Rabby Wallet: Architecture, Install, and Dapp Integration > Rabby is an open-source TypeScript browser wallet for Ethereum and other EVM chains, with a multi-context extension architecture and simple dapp connection guidance. Its shared provider approach lowers integration work but can leave wallet selection ambiguous. **RabbyHub/Rabby** — The game-changing wallet for Ethereum and all EVM chains - Repository: https://github.com/RabbyHub/Rabby - Website: https://rabby.io - Stars: 1,929 · Forks: 619 - Language: TypeScript - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/rabbyhub-rabby ## Rabby Wallet's Multi-Chain Browser Wallet Scope Rabby Wallet addresses Ethereum and other EVM-chain activity through a browser extension aimed at DeFi users. Its repository is primarily TypeScript, with source under `src`, webpack configuration, Jest tests, patch files, and build utilities. The project is not documented as a command-line wallet or a hosted web account. It is a browser-side interface that injects an `ethereum` object into dapp pages and routes dapp requests through several extension execution contexts. Rabby serves two groups with different needs. End users need a wallet capable of handling multiple EVM networks and requests from decentralized applications. Dapp developers need a predictable way to recognize and connect to an injected wallet. The README focuses particularly on the second problem: many dapps detect the shared `ethereum` provider but present every detected extension as MetaMask. That makes the connection interface misleading even when Rabby is the wallet that will handle the request. The repository topics, including `blockchain`, `chrome-extension`, `dapp`, `defi`, `ethereum`, and `ethereum-wallet`, match that extension and dapp focus. The homepage is `https://rabby.io`, while the README directs users to the repository's latest GitHub release for installation. The README does not document hardware wallet support, transaction simulation details, account recovery procedures, fee selection, or a complete supported-chain list, so those capabilities cannot be inferred from the repository summary. ## Rabby's Injected Provider Request Path Rabby separates wallet responsibilities across four extension contexts, and this boundary explains most of its integration behavior. `background.js` handles asynchronous requests and encryption tasks. It exposes wallet operations through `walletController` to the background window and receives page requests through `providerController`. The README also states that keyrings, passwords, and wallet preference data are stored in Chrome local storage. That is an architectural statement, not a security audit, and the README does not explain encryption boundaries, recovery behavior, or backup procedures. The `content-script` runs at `document_start`, shares the DOM with the dapp, and uses `broadcastChannel` to tap `pageProvider`. It injects `pageProvider.js` and relays messages between that script and `background.js`. This early injection matters because a dapp can discover `window.ethereum` before its own initialization finishes. When `pageProvider.js` mounts `ethereum` on `window`, a dapp request follows a defined sequence. The page sends a message to `content-script` over `broadcastChannel` and waits for a response. The content script forwards the request to `background.js` with `runtime.connect`. The background script invokes `providerController`, and `sessionService` retains the message channel for later communication. The architecture therefore separates the object visible to a website from the code that handles wallet requests while preserving a session channel for ongoing communication. Rabby also uses three UI pages built from shared JavaScript but different HTML templates. `notification.html` handles permission requests, `index.html` provides a full-tab interaction surface, and `popup.html` opens when a user selects the extension icon. The README does not document which dapp actions always require a notification, so applications should not infer that behavior from the page names alone. ## Installing Rabby and Building the Extension The shortest documented installation path is the latest GitHub release, which is appropriate for trying the packaged extension. A release download is separate from installing the repository. For contributors, the README requires Node.js 22 or later and Corepack before installing dependencies. Enable Corepack before Yarn processes the repository's dependency configuration: ```bash corepack enable ``` The next documented step installs dependencies using the repository's Yarn configuration and `yarn.lock`: ```bash yarn install ``` A developer build enables file watching and development logging. In this mode, the README says requests sent by the dapp appear in the website console, and notifications remain open when the page loses focus. That behavior is useful while inspecting a connection flow, although it changes notification behavior and should not be treated as the packaged experience. ```bash yarn build:dev ``` The `package.json` shows that `build:dev` selects `MANIFEST_TYPE=chrome-mv3` and delegates to the development build. A production package can be created with the command documented in the README. The production output is placed in the `dist` folder. ```bash yarn build:pro ``` The `package.json` entry is truncated, so its complete definition cannot be confirmed from the repository file shown here. The README nevertheless explicitly documents `yarn build:pro` and identifies `dist` as the production output location. The README does not give browser installation steps for loading `dist`, nor does it document signing, store publication, supported browser versions, or upgrade migration. Those checks must come from the release package and the generated extension output. ## Connecting a Dapp Through the Shared Ethereum Provider Rabby's integration guidance avoids special Rabby-only connection code. A conventional extension wallet injects an `ethereum` object into the dapp page. The dapp detects that object and sends requests through it. Rabby's concern is the label shown beside the object, not a separate transport protocol. When `window.ethereum` exists, the README recommends displaying connection buttons for both MetaMask and Rabby Wallet. Both buttons can initiate a connection through the same injected object. Their primary visible difference is the brand logo, which gives users familiar paths without changing business logic. When no `ethereum` object is detected, the README recommends suggesting an extension-wallet download and providing links for MetaMask and Rabby Wallet. The approach has low implementation cost because a dapp can retain its existing provider request logic and adjust only the connection UI. However, it does not positively identify the installed wallet. A user can click “connect to MetaMask” while Rabby receives the request, or click “connect to Rabby Wallet” while another injected provider handles it. The README explicitly identifies this potential issue, although it describes it as rare. For dapps that require exact wallet attribution, the README provides no `isRabby` detection method, provider-selection rule, or routing API. The recommendation should therefore be understood as compatibility UI, not as a guarantee that the wallet selected by the user matches the logo shown on the clicked button. This limitation matters for dapps that maintain wallet-specific instructions, analytics, or transaction policies. ## Rabby License and Maintenance Boundaries The repository is not archived, and its last push was on 2026-10-15. Recent releases include `v0.94.12` on 2026-10-15, `v0.94.11` on 2026-09-30, and `v0.94.10` on 2026-09-23. These records show recent repository activity, but the README does not define a long-term support policy or promise a release cadence. The repository identifies its license as a custom license that GitHub cannot classify. The README does not reproduce the terms in `LICENSE`, so it does not establish whether modification, redistribution, commercial use, sublicensing, or contribution rights match a standard open-source license. Calling the project open-source follows the repository description, but adopters must read `LICENSE` before redistributing or incorporating code. This is a licensing boundary, not legal advice. Upgrade cost depends on what a team maintains. The source uses Node.js 22 or later, Yarn, Corepack, webpack, TypeScript, patches, and generated build output. The repository includes tests and audit directories, but the README does not explain release verification, browser compatibility policy, migration handling for stored user data, or whether a rebuild from `develop` is suitable for production. Contributors should distinguish building the current source from obtaining an official packaged release. ## When Rabby Is the Wrong Integration Choice Rabby is a poor fit for a dapp that must know which wallet the user selected before sending requests. Its integration proposal accepts that the same `ethereum` object can satisfy either branded button. No documented mechanism resolves the ambiguity, and the README warns that a click on one brand can still reach another wallet. It is also not the documented choice for teams seeking a minimal provider layer with no extension UI. Rabby includes wallet data management, permission notification pages, a popup, and a full-tab interface. A dapp with a tightly controlled account environment may need a direct provider abstraction, mobile wallet protocol, or account abstraction stack, although those alternatives are not documented by Rabby's README. For contributors, the build is not lightweight. Node.js 22 or later, Corepack, Yarn, webpack, a large build, and generated output in `dist` are part of the documented path. Development mode also alters logging and notification persistence. A team that only needs the released extension should use the GitHub release download instead of taking on source-build maintenance. Finally, the README does not establish audited smart-contract protection, custody terms, recovery guarantees, or hardware-key support. The repository includes an `audits/` directory, but its contents are not described in the README, so no audit scope or current-version coverage can be claimed. ## Conclusion DeFi users who want a source-available browser wallet and dapp teams that need a straightforward connection path can adopt Rabby after checking the custom LICENSE and testing the generated extension in supported browsers. Teams requiring exact provider identification, or organizations unwilling to work under a custom license, should not adopt it without additional technical and legal review. ## FAQ ### How do I install Rabby Wallet? The README directs users to the latest GitHub release for the packaged browser extension. Repository contributors instead need Node.js 22 or later, Corepack, and `yarn install`. ### How does a dapp connect to Rabby Wallet? Rabby injects an `ethereum` object through `pageProvider.js`. A dapp can use its existing provider connection logic and present a Rabby connection button when that object is detected, although the button does not uniquely identify Rabby. ### Can a dapp reliably detect whether Rabby is installed? The README does not document a dedicated Rabby detection property. Its recommended UI displays both Rabby and MetaMask buttons when `ethereum` is present, so provider attribution is not guaranteed. ## Sources - [Issues](https://github.com/RabbyHub/Rabby/issues) - [Project website](https://rabby.io) - [RabbyHub/Rabby on GitHub](https://github.com/RabbyHub/Rabby) - [README](https://github.com/RabbyHub/Rabby/blob/develop/README.md) - [Releases](https://github.com/RabbyHub/Rabby/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rabbyhub-rabby