> For the complete documentation index, see [llms.txt](https://docs.qr.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.qr.xyz/qr-fr/sous-le-capot/architecture.md).

# Architecture

> Comment \[QR] wallet est construit de l'intérieur — pour les curieux et les développeurs.

***

## Pile technologique

| Composant              | Technologie                                                |
| ---------------------- | ---------------------------------------------------------- |
| **Application mobile** | React Native + Expo                                        |
| **Gestion d'état**     | Zustand                                                    |
| **Web3**               | viem, permissionless.js                                    |
| **Navigation**         | expo-router                                                |
| **Blockchain**         | Abstraction de compte ERC-4337 (réseaux EVM Smart Account) |
| **Infrastructure**     | Bundler, Paymaster, RPC multichaîne                        |
| **Sécurité**           | Biométrie + Secure Enclave                                 |
| **Réseaux**            | EVM + Solana + Tron + Bitcoin + Dash                       |

***

## Architecture modulaire

\[QR] wallet est construit sur une **architecture modulaire** — chaque fonctionnalité est isolée dans son propre module avec des couches claires :

```
modules/{feature}/
├── domain/          ← Logique métier pure et types
├── infrastructure/  ← API, stockage, services externes
├── application/     ← Gestion d'état et façades
└── ui/              ← Composants React (UI)
```

### Couches

| Couche             | Responsabilité                   | Exemple                                |
| ------------------ | -------------------------------- | -------------------------------------- |
| **Domaine**        | Types, interfaces, règles métier | `Swap.entity.ts`, `StakingPool`        |
| **Infrastructure** | Appels API et services externes  | `SwapApi.ts`, `AlchemyPaymaster`       |
| **Application**    | État, logique UI, façades        | `useSwapFacade.ts`, `SponsoredTxStore` |
| **UI**             | Composants visuels               | `SwapScreen.tsx`, boutons, cartes      |

### Règle d'import

```
UI → Application → Domaine & Infrastructure → Domaine
```

UI ne parle jamais directement à l'Infrastructure — seulement via la couche Application. Le Domaine est pur, sans aucune dépendance.

***

## Abstraction de chaîne

Travailler avec différentes blockchains est unifié via une couche d'abstraction :

```
┌──────────────────────────────────────────────────┐
│                   Noyau de chaîne                │
│                                                   │
│  ┌─────┐ ┌──────┐ ┌────┐ ┌───────┐ ┌────┐       │
│  │ EVM │ │Solana│ │Tron│ │Bitcoin│ │Dash│       │
│  └─────┘ └──────┘ └────┘ └───────┘ └────┘       │
│                                                   │
│  ChainRegistry → ChainConfigProvider              │
│  Interface unifiée + capacités par chaîne         │
└──────────────────────────────────────────────────┘
```

* **ChainRegistry** — registre de tous les réseaux pris en charge (la visibilité peut être activée/désactivée à distance)
* **ChainConfigProvider** — configuration et capacités par chaîne
* **TransactionService** — envoi unifié par famille (EVM Smart Account, EOA, Solana, Tron, Bitcoin, Dash)
* **Réseaux EVM personnalisés** — RPC ajoutés par l'utilisateur, sans Smart Account

Smart Account (ERC-4337 LightAccount) est utilisé uniquement sur les réseaux EVM pris en charge. Bitcoin, Dash, Avalanche et Taiko utilisent des comptes classiques.

***

## Pile d'abstraction de compte

```
┌──────────────────────────────────────────────┐
│                Utilisateur                   │
│          (biométrie → signature)             │
└──────────────────┬───────────────────────────┘
                   ↓
┌──────────────────┴───────────────────────────┐
│          IAccountProvider                     │
│    Construire UserOperation                   │
│    (sender, nonce, callData, initCode)        │
└──────────────────┬───────────────────────────┘
                   ↓
┌──────────────────┴───────────────────────────┐
│          IPaymaster                           │
│    Sponsoring du gas                           │
│    (paymasterAndData, estimations de gas)     │
└──────────────────┬───────────────────────────┘
                   ↓
┌──────────────────┴───────────────────────────┐
│          IBundler                             │
│    Soumettre à la blockchain                  │
│    (sendUserOperation → waitForReceipt)       │
└──────────────────┬───────────────────────────┘
                   ↓
┌──────────────────┴───────────────────────────┐
│          EntryPoint (sur chaîne)             │
│    Valider → Exécuter → Payer le gas         │
└──────────────────────────────────────────────┘
```

Trois interfaces (`IAccountProvider`, `IPaymaster`, `IBundler`) masquent le fournisseur spécifique. Nous utilisons actuellement Alchemy, mais l'architecture permet de changer de fournisseur sans modifier la logique métier.

***

## Registre des tokens

Un registre unique pour tous les tokens du système :

```typescript
// Chaque token est décrit une seule fois
{
  symbol: 'USDC',
  name: 'USD Coin',
  addresses: { base: '0x...', arbitrum: '0x...', polygon: '0x...' },
  decimals: { default: 6 },
  flags: { swappable: true, collateral: true, borrowable: true, stakable: true }
}
```

Les modules obtiennent les tokens dont ils ont besoin via **indicateurs**:

* `swappable: true` → Échanger des tokens
* `collateral: true` → Tokens de collatéral pour emprunt
* `borrowable: true` → Tokens empruntables
* `stakable: true` → Tokens de staking

Cela élimine la duplication — les données des tokens sont décrites **une seule fois** et utilisées partout.

***

## 18 langues

L'application est localisée en 18 langues :

EN, RU, ES, FR, HI, ID, JA, KO, MS, PT, TH, TL, TR, UR, VI, ZH, AR, BN