mytonwallet: a self-custodial multi-chain wallet built as a TypeScript monorepo

One codebase, five surfaces, eleven chains

My Wallet describes itself as a safe, self-custodial multichain wallet for 11 blockchains, and the chain list in the README is specific: Ethereum, Solana, Hyperliquid, TON, TRON, Base, BNB Chain, Polygon, Avalanche, Arbitrum and Monad. The promise is that you can send, receive and swap across chains without jumping between different apps. The surfaces are just as many. It works as a native mobile app for iOS and Android, a desktop app, a web app, a Telegram Mini App and a browser extension for all major browsers, under one account that works from any device. The desktop app is Electron, and the repository layout confirms the shape of the thing. There are separate Vite configurations for each target: vite.config.ts for the web app, vite-electron.config.ts, vite-air.config.ts for the native Air build, vite-mfa.config.ts for the Telegram Mini App, vite-multisend.config.ts and vite-portfolio.config.ts, plus a Playwright config for the Agent V2 tests. The primary language is Swift, which points at the native iOS side, but the front end is TypeScript and the desktop and web surfaces are built from it.

Custody is the design constraint, not a feature bullet

The README states that you keep full control and that the team does not have access to your funds, keys or data, and the security section repeats the same claim from a different angle. It says My Wallet is built for speed and reliability with a minimal dependency footprint for maximum safety. The self-custodial model shows up concretely in the feature list. The built-in Agent, which you talk to in natural language to send assets, swap, stake, open Explore and jump to token pages, is described as non-custodial by design because you always review and confirm every action. The on-ramp and off-ramp is where the boundary gets interesting: buying crypto with a bank card and withdrawing back to card where supported goes through third-party providers like MoonPay, which means fiat rails touch the flow even though keys do not. Portfolio tracking, staking of TON and assets including options like USDe, Ledger hardware wallet support, and multiple transfers in one go are the other headline features. Gasless transfers on TON and Solana take the fee from the transferred token where it is available, so you can send without holding the native gas token.

The build is npm and Vite, not a native toolchain

Getting a local build running is short, and the environment file is the part to look at first. The Local Setup section in the README is two commands:

cp .env.example .env

npm ci

Then npm run dev starts the development server, which the package.json defines as cross-env APP_ENV=development vite. The .env.example file that you copy shows how wide the configuration surface is. It points at a TON block explorer and a TON API service for both mainnet and testnet, each with a key field, and it lists the proxy hosts as PROXY_HOSTS="tonproxy.io:38080 tonproxy.io:38081 tonproxy.io:38082". The agent has its own entries: AGENT_API_URL=http://localhost:3000/api and AGENT_OVERRIDE=no_override, plus AGENT_V2_QUOTA_STATUS_ENABLED=0. Solana appears as Helius RPC endpoints for mainnet and devnet with an API key, and there is a WALLET_CONNECT_PROJECT_ID for the wallet connect integration. The credentials are not optional in practice, which is the first thing to understand before you try to run anything.

Agent V2 has a documented local test cycle

The README devotes more space to the Agent than to anything else, and the interesting part is the local test cycle rather than the feature description. Agent V2 is bundled in Classic, and the selection logic is spelled out. The environment variable AGENT_OVERRIDE=v1 or AGENT_OVERRIDE=v2 selects a build protocol, while the default AGENT_OVERRIDE=no_override follows the backend config and falls back to V1 when it is absent. On the regular web app, a query parameter enables V2 for the browser profile with ?agent=v2 and ?agent=v1 switches it back, and the saved browser choice takes priority over both the build and the backend selection, with both parameters removed from the URL once the choice is saved. To validate the SDK and the Classic integration against two local Agent replicas, you keep the agent repository next to this one and run:

npm run test:agent:v2
npm run smoke:agent:v2:local

The smoke test uses PostgreSQL, the Agent scripted provider and synthetic wallet data, and it explicitly does not call an external LLM, wallet backend, Portfolio API or Market API. That constraint is what makes it a repeatable test rather than a demo.

The frontend command deliberately owns almost nothing

The separation of responsibilities between the frontend and the backend is stated with unusual precision, and it is worth reading because it is a design decision rather than an accident. The backend, started from the sibling agent repository with npm run dev:v2:codex, owns its PostgreSQL lifecycle, its migrations, provider selection, credentials and the .env.agent-v2.local file. The frontend command only checks that http://127.0.0.1:3001/ready reports a compatible ready Agent V2 runtime, then points the frontend at its /api endpoint. It never reads sibling env files, starts PostgreSQL, applies backend migrations, selects a provider, or starts and stops backend processes. The same split applies on native iOS, where the SDK is shared through the WalletCore bridge, while Android Air continues to use Agent V1. There are dedicated launchers for the simulator as well, npm run dev:agent:v2:ios and npm run dev:agent:v2:ios:codex, which rebuild the embedded Air SDK and the MyTonWallet_AirOnly application, install it into an iPhone Simulator and launch it, with AGENT_V2_IOS_SIMULATOR_UDID to pick a specific device.

A Gram wallet variant runs the same code under an environment flag

The package.json shows how many build permutations this project supports, and the pattern is consistent: a cross-env flag around the same script. The gram variants, for the wallet integrated with Telegram, all set IS_GRAM_WALLET=1, which covers gram:dev, gram:build, gram:build:dev, gram:build:staging and gram:build:production. The extension variants use their own flags, IS_EXTENSION=1 for the Chrome extension and IS_FIREFOX_EXTENSION=1 for Firefox, and the Firefox package is a separate target from the Chrome one. The environment tiers are APP_ENV=development, staging and production, so a staging build is npm run build:staging, which chains into build:production. Every build script ends with bash ./deploy/copy_to_dist.sh or the extension packaging script, so the deploy directory is part of the build contract rather than an afterthought. The presence of .release, changelogs/ and a .swiftlint.yml alongside .prettierrc and .stylelintrc.json tells you that native and web code coexist under one release process, and that Swift code in the repository is linted separately from the TypeScript.

Security claims that are auditable rather than asserted

The security section makes three claims that a reader can check. First, that the practices are audited by CertiK. Second, that there is a bug bounty on CertiK SkyShield with $100K in reserved funds and rewards of up to $5,000. Third, that the program has been live since March 23, 2024 and that no vulnerabilities have been found to date. Those are the sort of claims worth having because they point at a place where you can check. The rest of the security story is architectural: the self-custodial model, the confirmation step on every Agent action, and a minimal dependency footprint. The repository supports this with a document of its own, docs/gpg-check.md for verifying GPG signatures of releases, and a separate docs/electron.md for the desktop build. The wallet connects to Ledger hardware wallets, hides balances, can view other wallets, and supports AI plugins for OpenClaw, ChatGPT and Claude, which is a large attack surface that the bounty and the confirmation model are the answer to. The README also claims a 4.8 rating on Trustpilot and 9M+ users worldwide.

Editorial conclusion

Adopt mytonwallet as a reference implementation if you are building a multi-chain self-custodial wallet and want to see how one TypeScript codebase targets mobile, desktop, web, extension and Telegram surfaces at once. Do not adopt it as a dependency, because it is an application repository rather than a published library, and the licence is a custom one that GitHub cannot classify. Before you commit, read the LICENSE file, decide which of the many build targets you actually need, and set up the local environment with cp .env.example .env followed by npm ci, since the .env file names the block explorer, RPC and agent endpoints your build will call.

Frequently asked questions

Official sources

1. Issues
2. mytonwallet-org/mytonwallet on GitHub
3. Project website
4. README
5. Releases