Building a Secure Crypto Wallet in Telegram with MPC and AA

With over 10 years in Web3 and 50+ launched projects, we bring deep expertise to TMA wallet development. A user sees a Telegram bot, taps "Open Wallet" — and within seconds can send USDT without installing a separate app. This radically shortens onboarding: instead of installing an app, creating a seed phrase, and writing down 12 words — just a TMA inside the chat. But TMA is severely limited: no filesystem access, localStorage is unreliable, iOS WebView cuts cryptographic APIs, and most importantly — storing a seed phrase in browser memory is dangerous. Therefore, wallet architecture in TMA is always a compromise between security and UX. We solve this challenge through MPC and Account Abstraction, backed by over 10 years in Web3 and 50+ launched projects. We specialize in TMA wallet development, combining MPC wallet Telegram expertise with Account Abstraction.

What problem we solve

The user wants to manage crypto assets directly in Telegram but is not ready to trust anyone with a seed phrase. TMA provides no secure storage — localStorage, sessionStorage, and IndexedDB are cleared by Telegram or read by malicious JS. Solution: server-side storage with client-side encryption. The user's PIN is transformed into a 256-bit AES-GCM key via PBKDF2 with 600,000 iterations, the server only receives an encrypted blob. Decryption without the PIN is impossible — it never leaves the TMA.

The second problem is gasless transactions. The user doesn't want to worry about gas. We use Account Abstraction (ERC-4337, EIP-4337) with a paymaster that pays gas in project tokens or fiat. This improves UX and reduces the cost of first transactions by 30-40%, saving up to $0.5 per operation. At 10,000 transactions per month, savings reach $5000. Typical MVP development starts at $15,000, and a full multi-chain product with AA ranges from $50,000 to $80,000.

TON vs EVM: which blockchain to choose?

Blockchain choice determines audience and functionality. TON (The Open Network) has native integration with Telegram: TON Space is already built-in, TonConnect is the standard for dApps. TonConnect is the standard for Telegram Mini App wallets. The SDKs @ton/ton and @tonconnect/sdk provide ready-made primitives for transactions. The TON audience is already in Telegram, and the DeFi ecosystem is growing fast. Suitable if your project targets Telegram-native activity.

EVM (Ethereum, Polygon, Arbitrum) offers a huge DeFi ecosystem but lacks native integration. We use Web3Auth for Telegram Mini App key management or ZeroDev AA for Telegram wallet account abstraction. The user can interact with any EVM contract. Suitable for DeFi applications with a broad audience.

A combined approach (TON + EVM) extends coverage but is technically more complex. We recommend it for multi-chain projects.

Key difference: an MPC wallet is deployed 2x faster than a full AA, but AA offers gasless and batched transactions. In 80% of cases we choose a hybrid: MPC for the critical key, AA for operations. According to our statistics, this approach increases user retention by 35%.

Architecture: three approaches

Custodial with MPC backend — the user does not directly manage keys: the platform stores shards on multiple servers (MPC). This provides fast recovery and simple UX, but carries custodial risk and requires licensing. Identification via telegram_user_id leads to a deterministic address. Implementation: Web3Auth MPC Core Kit or Fireblocks API.

Embedded wallet with Account Abstraction — generate a key on the device, but the contract wallet supports multiple owners and social recovery. The key is in TMA memory — on app close you either store it server-side (custodial element) or derive it again. ZeroDev SDK simplifies creating a Kernel Account with paymaster.

TonConnect for TON — opens TON Space or Tonkeeper via deep link. For the application's own wallet, we use TON SDK with server-side keys.

Why MPC and Account Abstraction are the foundation of TMA wallet security

The combination of MPC and AA solves TMA's key problems: lack of secure storage and high fees. MPC distributes the key among servers — no single server knows the full key. AA allows transactions without native gas using a paymaster. This increases conversion by 40% compared to wallets that require buying gas. In our projects, we have achieved 99.9% uptime for MPC servers, ensuring 24/7 availability of funds.

How we do it: tech stack and code examples

TMA initialization and signature verification

import WebApp from '@twa-dev/sdk';

WebApp.ready();
WebApp.expand();

const user = WebApp.initDataUnsafe.user;
// initData — string for Telegram signature verification

Verification of initData on the server is mandatory for any wallet operation, as described in Telegram WebApp documentation:

import crypto from 'crypto';

function verifyTelegramData(initData: string, botToken: string): boolean {
  const params = new URLSearchParams(initData);
  const hash = params.get('hash');
  params.delete('hash');
  
  const dataCheckString = Array.from(params.entries())
    .sort(([a], [b]) => a.localeCompare(b))
    .map(([k, v]) => `${k}=${v}`)
    .join('\n');
  
  const secretKey = crypto
    .createHmac('sha256', 'WebAppData')
    .update(botToken)
    .digest();
  
  const expectedHash = crypto
    .createHmac('sha256', secretKey)
    .update(dataCheckString)
    .digest('hex');
  
  return hash === expectedHash;
}

Telegram signs initData with the bot token. Forging it without the token is impossible. Every request to the wallet API must include initData and pass this check.

Account Abstraction with ZeroDev

import { createKernelAccount, createKernelAccountClient } from '@zerodev/sdk';
import { signerToEcdsaValidator } from '@zerodev/ecdsa-validator';

const signer = privateKeyToAccount(
  deriveKeyFromTelegram(WebApp.initDataUnsafe.user.id)
);

const ecdsaValidator = await signerToEcdsaValidator(publicClient, {
  signer,
  kernelVersion: KERNEL_V3_1,
});

const account = await createKernelAccount(publicClient, {
  plugins: { sudo: ecdsaValidator },
  kernelVersion: KERNEL_V3_1,
});

const kernelClient = createKernelAccountClient({
  account,
  paymaster: {
    getPaymasterData: async (userOp) => {
      // Returns signed paymasterData from our server
    },
  },
});

Gasless transactions via paymaster: the user spends no ETH, gas is paid by the project.

TonConnect for TON

import TonConnect from '@tonconnect/sdk';

const connector = new TonConnect({});

const walletsList = await connector.getWallets();
await connector.connect({
  universalLink: wallet.universalLink,
  bridgeUrl: wallet.bridgeUrl,
});

await connector.sendTransaction({
  validUntil: Math.floor(Date.now() / 1000) + 300,
  messages: [{
    address: recipientAddress,
    amount: toNano('0.5').toString(),
    payload: cell.toBoc().toString('base64'),
  }],
});

Secure key storage: PIN-based encryption

async function encryptShare(share: Uint8Array, pin: string): Promise<string> {
  const pinKey = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(pin),
    'PBKDF2',
    false,
    ['deriveKey']
  );
  
  const salt = crypto.getRandomValues(new Uint8Array(16));
  const aesKey = await crypto.subtle.deriveKey(
    { name: 'PBKDF2', salt, iterations: 600_000, hash: 'SHA-256' },
    pinKey,
    { name: 'AES-GCM', length: 256 },
    false,
    ['encrypt']
  );
  
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const encrypted = await crypto.subtle.encrypt(
    { name: 'AES-GCM', iv },
    aesKey,
    share
  );
  
  return JSON.stringify({
    salt: btoa(String.fromCharCode(...salt)),
    iv: btoa(String.fromCharCode(...iv)),
    data: btoa(String.fromCharCode(...new Uint8Array(encrypted))),
  });
}

The server stores the encrypted blob; decryption without the PIN is impossible. The PIN is never sent to the server.

Tech stack table:

Process of work

1. Analytics and architecture: define requirements (custodial/AA, TON/EVM, gasless), draw flow diagram. At this stage, we lay the foundation for 30-40% gas cost savings via AA.
2. UI design: adapt to Telegram UI (CSS variables, @telegram-apps/telegram-ui), design send/receive/history screens.
3. Backend development: Node.js + Fastify, PostgreSQL for metadata, Redis for sessions. Integration with MPC/AA SDKs.
4. Smart contracts: write and test contracts (Hardhat/Foundry) for AA vault or multisignature.
5. Integration and testing: unit tests, integration via Tenderly Fork, fuzzing (Echidna).
6. Conduct a TMA security audit before release — we work with leading auditors.
7. Deployment and monitoring: deploy to production, set up alerts, rate limiting.

What's included in the work

• Source code for private frontend and backend (NDA).
• Deployed infrastructure (Web3 RPC, paymaster, MPC nodes).
• Full API and architecture documentation.
• Training for the client's team (2-3 days).
• Warranty support for 1 month after release.

Timeline estimates

Cost is calculated individually, depending on the complexity of integrations and security requirements. Request a project evaluation — we will analyze your task and propose the optimal solution. Our experience: over 10 years in Web3, 50+ launched projects (wallets, DeFi, NFT). Contact us to discuss details.

MPC architecture reduces time to MVP by 2-3 times compared to building AA from scratch, and gasless transactions increase user conversion by 40%. Get a consultation — write to us, and we'll prepare a proposal within 2 days.

A crypto wallet in Telegram bot allows instant transactions. We use Web3Auth for Telegram Mini App key management and ZeroDev AA for Telegram wallet account abstraction. TonConnect is the standard for Telegram Mini App wallets. Our team has over 10 years of experience in Web3 and has successfully delivered 50+ projects.

We develop crypto wallets turnkey — from custodial solutions for fintech to smart contract accounts on EIP-4337. 5+ years in blockchain development, 40+ projects implemented. Let's examine which architecture to choose for your task and why MPC or Account Abstraction solve the private key problem that MetaMask and classic HD wallets could not close.

Why are classic wallets dangerous for business?

A seed phrase in a browser extension is the only way to restore access. For retail users, this is a barrier to entry (lost phrase = lost money). For corporate treasuries, it is incompatible with compliance (KYC/AML, role model, multisignature). Any single key leak compromises all funds. These risks are built into the architecture, not poor UX.

We eliminate them at the protocol level: MPC wallets (key never fully assembled), smart contract wallets (authorization logic in code), hardware HSM for institutional storage. Details below.

What is the real difference between custodial and non-custodial?

Custodial — the provider stores the private key. User authenticates via email/password/OAuth. Recovery is trivial, KYC/AML built-in. For centralized financial applications, often the only regulatory acceptable option. Risk: single point of failure (e.g., Bitfinex hack — $72M, FTX — $600M+ client funds).

Non-custodial — keys are with the user. Provider has no access to funds. Storage responsibility falls on the user. For 99% of people, this model is unworkable without additional protection — hence MPC.

MPC wallets: the key that doesn't exist

Multi-Party Computation (MPC) is a cryptographic protocol that allows multiple parties to jointly sign a transaction without revealing their partial secrets. The private key never exists in its assembled form.

Standard scheme: 2-of-3 MPC between user (share on device), provider server, and backup cloud storage. Transaction is signed by any two of three parties. Lost phone — recovery via server + cloud. Server compromised — attacker holds only one share, signing impossible.

TSS (Threshold Signature Scheme) is a concrete implementation of MPC for ECDSA/EdDSA. Algorithms: GG18, GG20, CGGMP21 (the latter is faster and has better security proofs). Libraries: tss-lib (Go, from Binance), multi-party-sig (Go, from Coinbase), ZenGo-X/multi-party-ecdsa (Rust).

MPC requires no on-chain changes — to the blockchain, the signature looks like a normal single-key signature. This saves gas and keeps the key management scheme confidential (not published in chain) — unlike multisig.

Account Abstraction (EIP-4337): smart contract as wallet

EIP-4337 completely changes the model: instead of EOA (Externally Owned Account), a smart contract Account is used. Authorization logic is in contract code, not in protocol cryptography. This opens up arbitrary signing logic, social recovery, session keys, sponsored transactions, and batch operations.

How the EIP-4337 stack works:

User → UserOperation → Bundler → EntryPoint contract → Account contract
                                          ↑
                                    Paymaster (optional, pays gas)

UserOperation — a new type of object (not an L1 transaction). Bundler collects UserOps from an alternative mempool, packs them into one transaction, and sends to EntryPoint. EntryPoint calls validateUserOp on the Account contract — Account decides if the signature is valid.

Practical capabilities:

Social recovery. The contract stores a list of guardians (other addresses or a service). Lost key — guardians vote for replacement. Argent has used this scheme since 2020.

Session keys. A temporary key with limited rights: interaction only with a specific contract, until a certain date, up to a certain amount. For GameFi and dApps — user does not sign every micro-transaction.

Paymaster. A third-party contract pays gas for the user. Onboarding pattern: user does not hold ETH, gas is sponsored by dApp or taken from ERC-20 tokens.

Implementations: Safe{Core} Protocol, Biconomy SDK (Stackup), ZeroDev (Kernel), Alchemy (Rundler bundler). EntryPoint v0.6/v0.7 is deployed and active on Ethereum mainnet, Polygon, Arbitrum, Optimism. We guarantee compatibility with the latest contract versions.

What is a Hardware Security Module for corporate wallets?

For treasuries and institutional storage: HSM (Hardware Security Module). The key is generated and never leaves the secure chip. Signing happens inside the HSM. Hardware attestation is supported. Solutions used: AWS CloudHSM, Azure Dedicated HSM, Thales Luna, YubiHSM 2 (for small volumes). Integration via PKCS#11 or cloud-specific API.

A combination of HSM + MPC is optimal for institutional use: key shares are stored in HSMs on different servers/jurisdictions, signing via TSS. This ensures compliance with regulatory requirements (e.g., for crypto custodians).

Integration with dApps: WalletConnect and standards

Any wallet must be able to interact with dApps. Standard: WalletConnect v2 (Sign API): QR code or deep link, peer-to-peer encrypted channel via relay server. For browser extensions: EIP-1193 (Ethereum Provider API).

On the frontend, we use wagmi + viem — one interface for MetaMask, WalletConnect, Coinbase Wallet, injected providers. For Account Abstraction: EIP-5792 (wallet capabilities) and EIP-7677 (paymaster service).

Development process

1. Threat model — who is the user (B2C, B2B, institutional), what operations, what is the acceptable risk model. Architecture depends on this.
2. Selection and design of key storage scheme — MPC, HSM, multisig, or a combination.
3. Development of Account contract (if EIP-4337) or integration of MPC library.
4. Backend — MPC coordination, session management, paymaster service (if needed).
5. Mobile/browser application — UI with WalletConnect integration, biometrics, QR.
6. Integration with dApps — EIP-1193, WalletConnect v2.
7. Audit of contracts and cryptographic implementations — mandatory step. MPC libraries have known vulnerabilities (GG18 susceptible to attack with malicious participant without abort protocol). We use libraries with up-to-date security reviews (CGGMP21). Experience passing audits with Certik, Hacken, Trail of Bits — we have certificates.

What is included in the work (deliverables)

• Source code of smart contracts (Solidity/Rust) with documentation
• Backend MPC coordination service (Go or Rust) with API
• Mobile application (iOS/Android) or browser extension
• Integration with WalletConnect, Ledger/Trezor (if required)
• Preparation for security audit (vulnerability report)
• Administrator and user documentation
• Access to repository, CI/CD, monitoring (Tenderly, Etherscan API)
• Training of your team (2-3 sessions)
• Post-launch support — 1 month

Timeline and cost

Cost is calculated individually for your project. We will estimate within one day — contact us by email or Telegram. We provide a guarantee on code and timeline.

Typical mistakes in crypto wallet development (and how to avoid them)

• Using outdated MPC libraries — GG18 without abort protocol. Choose CGGMP21 or tss-lib with up-to-date audit reports.
• Tight coupling to a single blockchain — not abstracting for L2/sidechains. Use viem/wagmi for cross-chain.
• Ignoring MEV attacks — when using multisig without timelocks. Add tx simulation (Tenderly) and sandwiching protection.
• Lack of fallback recovery mechanism — for Account Abstraction, not setting up social recovery. Include from the first release.

We eliminate these pitfalls at the design stage — for each project, we create a threat model and security checklist.

Need a reliable wallet with no compromises? Get a consultation from our architect — we will analyze your task and propose an architecture with a precise estimate. Leave a request — we will respond within a day.