OneKey app-monorepo: a multi-platform crypto wallet in one Yarn workspace tree

What the OneKey monorepo actually contains

Most wallet repositories are one app. This one is five: an Electron desktop build, a Chrome extension, a React Native mobile app, a web application, and a web-embed component that can be dropped into another page. The README's download table lists iOS on the App Store, Android on Google Play, desktop for macOS, Windows and Linux, a browser extension, and a separate Bridge download.

The stated audience is anyone who wants to inspect or rebuild a wallet rather than trust a binary. The README calls it an anti-scam, open-source wallet supporting Bitcoin, Ethereum, Solana, Tron and BNB Smart Chain. That framing matters: the value here is verifiability, not novelty of features. If you are an engineer evaluating whether to fork a wallet, this repository is the reference implementation to read. If you are a user, the download links are the product and the repository is the receipt.

How the workspaces split shared logic from five app shells

The repository is a Yarn workspaces monorepo, and the layout is the interesting part. Everything user-facing sits under apps/, and everything reusable sits under packages/. The packages are where the design decision lives: components holds shared UI, core holds business logic and crypto utilities, kit is the main UI kit, kit-bg is a background service kit, qr-wallet-sdk is a QR-code hardware wallet SDK, and shared holds utilities, constants and types.

That split is what makes five targets tractable. A derivation path, an RPC call or a chain constant changes once in packages/core and every app picks it up. The background service kit is the piece that differs most per platform, because an extension has a service worker, a desktop app has an Electron main process, and mobile has neither. Keeping that behind kit-bg rather than inside each app is the reason the same business logic can run in a browser tab and a native binary.

The cost is coupling. There is no published API contract between packages here, just workspace resolution. A change in packages/core propagates to every app in the same commit, and the repository's own release history shows the consequence: tags like v6.6.0, v6.5.2 and v6.5.0 arrive as whole-product releases, not per-package versions. You cannot upgrade one app's copy of core independently.

Building it: prerequisites, install and the web target

The README lists three prerequisites before anything else: Node.js >= 22, Yarn 4.x bundled via Corepack, and Git LFS. The root package.json is stricter, pinning packageManager to [email protected] and engines.node to >=22.12.0. Git LFS is easy to miss and the repository has a .gitattributes file, so a plain clone without LFS will leave you with pointer files instead of assets.

Start by cloning and installing dependencies from the root:

git clone https://github.com/OneKeyHQ/app-monorepo.git
cd app-monorepo
yarn

The install is not a plain dependency resolution. The root package.json defines a postinstall script that runs node development/scripts/postinstall.js, so expect repository-specific setup work during yarn. There is also a setup:env script that copies .env.example to .env if .env does not exist.

The fastest way to see the product running is the web target, which the README says serves on port 3000:

yarn app:web

If port 3000 is taken, the root scripts include app:web:3030, which sets WEB_PORT=3030 before starting. The same script table maps yarn app:desktop to Electron, yarn app:ext to the extension, yarn app:ios to a USB-connected device and yarn app:android to Android. Platform requirements are stated separately: Xcode >= 13.3 for iOS and JDK >= 11 for Android.

Configuration is environment-driven. The .env.example file enumerates the keys you may need, including LOKALISE_TOKEN and LOKALISE_PROJECT_ID for translations, GH_TOKEN, APPLEID, APPLEIDPASS and ASC_PROVIDER for desktop signing and notarization, the four Sentry DSN keys (WEB_SENTRY_DSN, DESKTOP_SENTRY_DSN, SENTRY_DSN_REACT_NATIVE, EXT_SENTRY_DSN), COVALENT_KEY, JPUSH_KEY and JPUSH_CHANNEL, API_FOX_ACCESS_TOKEN, and ENABLE_ANALYZER with ENABLE_ANALYZER_HTML_REPORT for bundle analysis. The file's own comment notes that variables are auto-added and injected at the CI job, and asks for a trailing empty line.

Where the monorepo approach gets in your way

The single-tree design has a real failure mode: you cannot build one platform cheaply. There is no documented per-app install path. Even the extension has a proxy variant (app:ext:proxy) and a full multi-target build (app:ext:build:all), which tells you the build graph assumes the whole workspace is present.

Environment variables are the second sharp edge. The .env.example header states that variables are auto added and injected at the CI job. That means a local build with an empty .env may not reproduce what ships, particularly for signing and Sentry reporting. Nothing in the README explains which keys are optional versus which will break a build.

This is also the wrong tool for a narrow job. If you want to add wallet connectivity to an existing React app, pulling in this repository means pulling in a five-target application with its own UI kit and state layer. The qr-wallet-sdk package is the closest thing to a standalone artifact the layout suggests, but the README does not document it as independently installable, so treat that as unverified until you read the package.

Finally, the branch you land on by default is hotfix/v6.6.1, not a main branch. That is a release line, and it is worth checking what the default branch means for the code you actually get.

OneKey versus a general-purpose monorepo toolchain

The related searches around this repository are mostly about monorepos in general, and the honest answer is that OneKey is not a monorepo tool. It is a product built with Yarn workspaces. If your question is whether to use Nx, Turborepo or plain Yarn workspaces, this repository is evidence for one answer rather than a comparison.

The difference in approach is scope. A general toolchain gives you task graphs, caching and affected-project detection across whatever packages you define. OneKey's root package.json exposes hand-written scripts per target: app:web, app:desktop, app:ext, app:ios, app:android, each with build and stats variants. There is no visible task orchestrator beyond Yarn workspaces and the postinstall hook. For five apps maintained by one team on one release cadence, that is sufficient and simpler to reason about. For a repository where twenty teams need independent deploy pipelines, it is not, and you would be adding a layer this project deliberately does not have.

The other comparison worth drawing is against a plain single-app repository. A polyrepo would let each platform version independently and would let the extension ship without waiting on mobile. OneKey gives that up in exchange for one place to change chain support. Given that Bitcoin, Ethereum, Solana, Tron and BNB Smart Chain all need to behave identically across five surfaces, the trade favours the monorepo.

Licence, maintenance and what upgrading costs

The README states the project is licensed under the OneKey Standard Source License (O-SSL), and the repository metadata reports the licence as NOASSERTION, meaning GitHub could not classify it automatically. That combination is the single most important thing to check before you build on this code. Source-available is not the same as open source in the OSI sense, and the repository description's phrase community driven should not be read as a permissive grant. Read LICENSE.md yourself; this is a description of what the files say, not legal advice.

Maintenance is active by the evidence available: the last push was on 2026-09-28 and the repository is not archived. Releases arrive on a monthly-ish cadence, with v6.6.0 on 2026-09-22, v6.5.2 on 2026-08-21 and v6.5.0 on 2026-07-13.

Upgrade cost is where the monorepo bites. Because packages are consumed through workspace resolution and the product ships as whole-version tags, following upstream means rebasing your changes across all five apps at once. If you fork and modify packages/core, every upstream release is a merge across that boundary. The repository carries a patches/ directory for dependency patches, which is a signal that upstream dependencies sometimes need local fixes; those patches are another thing to re-verify on each upgrade. There is no documented rollback procedure in the README, so plan your own before you ship a fork.

Editorial conclusion

Adopt it if you want to read or build a production multi-platform wallet rather than write one from scratch, and you accept the OneKey Standard Source License. Do not adopt it if you need an OSI-approved licence for a competing product, or if you want a library you can drop into an existing app instead of a full application shell. Before committing, read LICENSE.md in full, check whether the packages you intend to import are covered by it, and confirm that your machine meets Node.js >= 22.12.0, Yarn 4.12.0 via Corepack and Git LFS, since the postinstall step will fail without them.

Frequently asked questions

Official sources

1. Issues
2. OneKeyHQ/app-monorepo on GitHub
3. Project website
4. README
5. Releases