ChangeNOW x Guarda : la preuve par l'exemple – un portefeuille n'a pas besoin de se transformer en plateforme d'échange

• Lancé en 2017, Guarda Wallet est un portefeuille Android autofinancé et sans dépôt, entièrement développé à partir de zéro pour une seule chaîne. Pour aller au-delà du simple stockage, ses utilisateurs avaient besoin de pouvoir échanger, acheter et staker depuis l’application — sans que Guarda ne devienne une plateforme d’échange ni ne mette en place l’infrastructure que cela implique.
• L’équipe a intégré l’API de ChangeNOW comme couche d’échange, ChangeNOW agissant comme principal fournisseur derrière la couverture d’échange de Guarda : la liquidité, le routage et la tarification relevaient de ChangeNOW, tandis que la garde restait entre les mains de l’utilisateur et que l’échange lui-même ne quittait jamais le portefeuille.
• Guarda prend désormais en charge 70 blockchains majeures — cette couverture réseau étant en grande partie rendue possible grâce à l’intégration de ChangeNOW —, opère dans plus de 100 pays et est disponible sur le Web, sur ordinateur, sur mobile et via une extension de navigateur. ChangeNOW s’est chargé de l’aspect « échange » ; la trajectoire globale du produit relevait quant à elle de la responsabilité de Guarda.

Le stockage a cessé d’être un produit

Pendant la majeure partie de la dernière décennie, le rôle d’un portefeuille était de conserver. On y déposait ses clés, on les gardait en sécurité, puis on les récupérait en cas de besoin. Ce cadre ne résiste plus à la réalité de l’utilisation de ces produits par les utilisateurs. Ces derniers jugent un portefeuille en fonction de ce qu’ils peuvent faire dès qu’ils l’ouvrent, et non en fonction de l’endroit où leurs actifs sont stockés lorsqu’ils sont inactifs.

Lorsque la seule fonctionnalité prise en charge par un portefeuille est le stockage, chaque échange, achat ou mise devient une raison de le quitter. Un portefeuille conçu ainsi sert de point de passage entre les transactions plutôt que de lieu où celles-ci se déroulent. Une fonctionnalité d’échange intégrée au portefeuille est passée du statut de fonctionnalité haut de gamme à celui d’attente de base, et la question intéressante n’est plus de savoir s’il faut en ajouter une, mais où cette fonctionnalité doit être hébergée une fois qu’elle est en place.

L’auto-custode s’est généralisée, et elle a relevé la barre

Ce changement a un point de départ clair. En 2017, les plateformes d’échange centralisées perdaient la confiance des utilisateurs après une série de piratages majeurs, la réglementation autour des plateformes de conservation se durcissait, et l’auto-custode a cessé d’être l’apanage des utilisateurs avertis. Pour une part croissante d’utilisateurs, elle est devenue le moyen le plus sûr de détenir des actifs, tout simplement.

Ce changement de comportement s’est heurté à une évolution de la structure du marché. Les actifs se sont fragmentés entre différentes chaînes, et la navigation manuelle entre celles-ci ralentissait les utilisateurs et augmentait les taux d’échec au moment même où ils tentaient d’agir. La liquidité s’est dispersée entre les carnets d’ordres, les pools AMM et les systèmes de routage concurrents. L’agrégation et le routage intelligent sont passés du statut d’outils avancés à celui de conditions indispensables, car aucune source unique ne pouvait à elle seule fixer correctement le prix d’une transaction sérieuse. La barre s’est donc doublement relevée : les utilisateurs voulaient garder la garde de leurs actifs entre leurs mains, et ils voulaient opérer sur une douzaine de réseaux sans avoir à quitter l’application pour le faire.

Guarda a refusé trois raccourcis

Guarda a vu le jour cette année-là sous la forme d’un portefeuille Android pour Ethereum, développé de toutes pièces comme produit non dépositaire par une équipe ne disposant ni d’infrastructure existante, ni de base de produits, ni de financement extérieur. La difficulté n’a jamais résidé dans la fonctionnalité de base, mais dans la confiance. Une architecture non dépositaire ne peut pas conserver de clés privées, de fichiers de sauvegarde ou de données personnelles sur ses propres serveurs, ce qui rend l’ingénierie plus exigeante que pour un portefeuille côté serveur — et encore plus exigeante pour une équipe autofinancée travaillant avec des ressources limitées. Ces premiers travaux ont tout de même été remarqués : la communauté Ethereum Classic a adopté le portefeuille Android, et une subvention de la Fondation Zcash a permis de financer un client ZEC léger.

Le problème de scalabilité s’est rapidement posé. Une application distincte pour chaque chaîne aurait transformé le produit en un ensemble de portefeuilles déconnectés ; l’équipe avait donc besoin d’une architecture unique capable d’intégrer de nouveaux actifs et de nouvelles actions sans se fragmenter. Pour y parvenir, il a fallu écarter trois voies plus faciles, chacune ayant un coût réel. Un modèle de garde ou côté serveur aurait simplifié l’ingénierie, mais aurait impliqué de renoncer à l’autogestion. Se limiter au mobile aurait permis de maintenir la spécialisation du produit, mais aurait ignoré tous les autres environnements dans lesquels les utilisateurs gèrent leurs cryptomonnaies. Recourir à des capitaux extérieurs aurait accéléré le recrutement et ajouté une série de pressions que l’équipe souhaitait éviter. Guarda a choisi la voie la plus difficile sur ces trois points : autofinancement, multiplateforme et modèle de confiance intact.

C’est cette discipline qui mérite d’être étudiée. La contrainte n’était pas une simple note de bas de page de la stratégie — elle était la stratégie elle-même. Une équipe qui n’avait pas les moyens de créer une plateforme d’échange devait être très précise sur ce qu’elle développait et sur ce qu’elle intégrait.

Troisième option : externaliser l’infrastructure, garder le contrôle

C’est là que la décision se précise. Guarda a fait de l’échange intégré à l’application un objectif central. Mais mettre en place de toutes pièces la liquidité et les opérations d’échange était précisément ce que l’équipe avait écarté. Elle a donc tracé une ligne que la plupart des feuilles de route ne précisent pas : l’infrastructure est externalisée, l’action reste en interne.

La couche de la plateforme d’échange a été intégrée via une API — celle de ChangeNOW, en tant que fournisseur principal — de sorte que les échanges s’effectuaient à l’intérieur du portefeuille, tandis que l’acheminement, la tarification et la liquidité relevaient d’opérations externes à l’équipe. Guarda n’est pas devenue une plateforme d’échange, et n’a pas redirigé ses utilisateurs vers une telle plateforme.

Cette distinction est facile à brouiller, il est donc important d’être précis à ce sujet. Rediriger un utilisateur vers une plateforme d’échange implique une redirection hors de l’interface, un compte distinct, une deuxième série de vérifications d’identité et le transfert de la garde des actifs à la plateforme qui gère la transaction. Un swap intégré conserve tout cela au sein même du portefeuille : pas de redirection, pas de deuxième compte, pas de transfert de garde, et les frais ainsi que les données de transaction restent au niveau du portefeuille plutôt que de la plateforme. La transaction est toujours réglée sur des infrastructures externes — mais l’utilisateur, le moment de l’action et la relation ne quittent jamais le produit. Seule l’infrastructure est externalisée. Le routage étant non dépositaire, les clés ne quittent jamais le contrôle de l’utilisateur pour permettre l’échange, ce qui préserve la promesse initiale du portefeuille plutôt que de la sacrifier au profit de la commodité.

L’externalisation de cette couche a également permis d’éliminer un fardeau que l’équipe avait raison d’éviter : lorsque le fournisseur prend en charge le routage et une grande partie des obligations de conformité, un portefeuille intègre des fonctionnalités d’échange sans pour autant hériter de l’ensemble du profil réglementaire d’une plateforme d’échange.

La logique commerciale découle de ce même choix. Chaque action qu’un utilisateur peut effectuer au sein du produit renforce la relation et crée une opportunité de gains sans pousser le portefeuille vers la conservation — des échanges, puis du staking pouvant atteindre environ 20 % d’APY selon l’actif. Guarda ne s’est pas limité aux transactions : la société a ajouté un générateur de jetons, une branche éducative (la Guarda Academy) et le jeton $GRD, mais chacun de ces éléments a été intégré au même portefeuille plutôt que de donner naissance à une application distincte.

L’échelle comme récompense, et la règle à retenir

Le résultat s’apparente davantage à une portée qu’à une liste de victoires. Guarda prend désormais en charge 70 blockchains majeures, avec ChangeNOW comme principal fournisseur d’échange derrière cette couverture (mais pas le seul), et fonctionne dans plus de 100 pays via le Web, sur ordinateur (Windows, macOS et Linux), sur mobile (iOS et Android) et via une extension Chrome. Une application Android mono-devise est devenue un espace permettant de conserver, d’échanger, d’acheter et de staker depuis un seul et même environnement. L’intégration a pris en charge la couche d’échange ; elle n’a pas créé l’ensemble du parcours, et la version honnête de l’histoire distingue clairement ces deux aspects.

La leçon à retenir pour les équipes de portefeuilles va au-delà du simple « ajouter une plateforme d’échange ». Le portefeuille qui répond au moment de l’action construit une relation plus solide, même sans détenir les fonds de quiconque. La règle à laquelle Guarda est parvenue est très claire : ne devenez pas une plateforme d’échange, mais ne laissez pas non plus une autre plateforme s’approprier l’action d’échange. Gardez le modèle de conservation clair et maintenez l’action au sein du produit. Ce qui soulève une question pour tous ceux qui gèrent un portefeuille aujourd’hui. Parmi toutes les intentions de transaction générées par vos utilisateurs, quelle part envoyez-vous encore ailleurs pour en tirer profit ?

_________________________________________________________________________

Bitcoin.com décline toute responsabilité et ne saurait être tenu responsable, directement ou indirectement, de toute perte, tout dommage, toute réclamation, tout coût ou toute dépense de quelque nature que ce soit, qu’ils soient réels, allégués ou consécutifs, découlant de ou liés à l’utilisation de, ou à la confiance accordée à, tout contenu, bien ou service mentionné dans cet article. Toute confiance accordée à ces informations est strictement aux risques et périls du lecteur.