Nous utilisons Google Analytics pour nos statistiques de fréquentation. Les cookies d'analyse ne sont déposés que si vous acceptez. Sans consentement, les statistiques sont estimées à partir de signaux sans cookie. Politique de cookies.
Wallets · WaaS
Vos utilisateurs ont besoin de wallets ; vous n'avez pas besoin de devenir une entreprise de wallets. Un appel d'API crée le wallet, le SDK l'affiche dans votre app, et les clés ne quittent jamais l'appareil.
POST /v1/wallets renvoie un wallet. Soldes, transferts et historique sont des endpoints, pas une infrastructure à monter. La console développeur montre toute la surface — assez petite pour se lire d'une traite.
La console développeur — les wallets comme surface d'API.
La feuille wallet s'intègre dans l'app hôte sur iOS, Android, React Native et Web — votre navigation, votre marque, notre feuille. La génération des clés et la signature se font sur l'appareil : la conservation reste à l'utilisateur, là où elle doit être.
Recevoir sur Base — QR, adresse et un avertissement qui évite les envois sur la mauvaise chaîne. · Douze mots, une seule fois — notés hors ligne, jamais redemandés.
Fonctionnalités
La console montre toute la surface : un quickstart qui crée un wallet en un seul curl — HTTP 201 en 84 ms —, des clés API live et test, l'état de livraison des webhooks et les chiffres de production. Le programme de démo fait tourner 84 120 wallets avec 99,99 % de disponibilité.
Dans la démo, une application de billetterie vend une entrée à 49,00 € et la feuille Protocore glisse par-dessus : solde de 124,00 USDC sur Base, payer et recevoir, sauvegarder, exporter les clés. L'application hôte reste le produit ; le wallet n'est qu'une feuille à l'intérieur.
L'onboarding se termine sur un seul écran : votre wallet est prêt. Fonds et activité se synchronisent ensuite automatiquement — l'utilisateur le renomme, l'alimente, ou poursuit simplement dans l'application hôte. L'appel API a eu lieu plus tôt ; l'utilisateur ne l'a jamais vu.
Le sélecteur de la démo contient trois types à la fois : un wallet principal multi-chain à 1 148,20 €, un wallet Solana mono-chain encore signalé à sauvegarder, et une adresse de cold storage en lecture seule, présente pour la visibilité. Les utilisateurs organisent leurs fonds comme ils les conçoivent.
Un écran de réception qui anticipe les erreurs : la bannière indique actifs Base uniquement sous peine de perte des fonds, le QR et l'adresse copiable se trouvent en dessous, et la feuille liste précisément les actifs pris en charge par cette adresse. Copiez l'adresse, ou partagez-la telle quelle.
Douze mots numérotés, affichés une seule fois, à noter hors ligne. L'écran porte sa propre posture de sécurité : les captures d'écran sont désactivées, et Protocore indique en clair qu'il ne demandera jamais ces mots. La garde reste à l'utilisateur parce que la sauvegarde l'est aussi.
La console opérateur tient un registre en lecture de chaque wallet du tenant — 2 418 dans la démo — avec recherche d'adresse exacte et vue par utilisateur. Le panneau dit ce que l'architecture impose : la console ne détient jamais de clés et ne déplace jamais de fonds. Les adresses sont exposées pour le support et le traçage, jamais balayées.
142 actifs référencés — symbole, nom, chaîne, contrat, décimales et indicateurs de listing dans un seul tableau en lecture seule. USDC et ETH portent l'indicateur Core ; USDT est marqué Unsafe. Votre application n'expose que les tokens dont le registre se porte garant, et rien d'autre.
Envoyer, recevoir, swapper et acheter ont chacun leur interrupteur, leur propre mode de désactivation — désactiver avec un message, ou masquer complètement — et un flag principal au-dessus. Un changement est persisté côté serveur et atteint les applications en 30 secondes environ. Quand un rail dysfonctionne, vous coupez exactement ce rail.
Un appel authentifié renvoie un wallet — id, adresse, chaînes — en 84 ms dans la démo. Aucune étape d'infrastructure avant le premier wallet ; l'endpoint est l'infrastructure.
iOS, Android, React Native et Web sont livrés sous forme de SDK versionnés — 1.4.2, 1.4.0, 0.9.1 et 2.1.0 dans la console de démo. Un seul schéma d'intégration, quatre plateformes, la même feuille partout.
Les clés sont générées et conservées sur l'appareil de l'utilisateur — vous proposez des wallets sans devenir dépositaire. La feuille le dit clairement en bas : sécurisé par Protocore, clés sur l'appareil.
Les wallets parlent BTC, ETH, Base et Solana dès le premier jour. L'appel de création prend un tableau chains — le quickstart passe base et ethereum et reçoit un wallet en retour.
Tout ce qui suit la création est aussi un endpoint : soldes, transferts et historique sont des appels API, pas des systèmes à monter. La vue des transactions de la console lit la même surface que votre application.
Les événements wallet sont postés vers votre endpoint avec un statut par livraison — la démo affiche wallet.created à 100 % de succès sur 24 heures, dernière livraison il y a deux minutes. Votre backend connaît les wallets à l'instant où ils existent.
Les clés vont par paires — sk_live et sk_test — gérées dans la console. Le mode test exerce toute la surface avant qu'un vrai wallet n'existe.
Une adresse peut rejoindre le sélecteur sans ses clés — soldes visibles, rien de dépensable. Les utilisateurs surveillent leur cold storage depuis l'écran même où ils dépensent.
Un wallet sans phrase notée affiche un indicateur de sauvegarde visible jusqu'à ce que l'utilisateur régularise. Le rappel vit là où est l'argent, pas dans un e-mail que personne n'ouvre.
Définissez un montant sur l'écran de réception et partagez le résultat — le correspondant reçoit une adresse et un montant plutôt qu'une capture d'écran et une approximation. Le partage d'adresse simple reste à un tap.
Les adresses sont propres à un réseau et l'interface le dit avant tout envoi : actifs Base uniquement, sinon ils pourraient être perdus. La liste des actifs pris en charge figure sur le même écran que le QR.
Les utilisateurs peuvent exporter leurs clés depuis la feuille — la garde reste à l'utilisateur, pas seulement sur la page marketing. Le wallet survit à la relation avec l'application si l'utilisateur le souhaite.
Fonds et activité se synchronisent sans bouton d'actualisation — la feuille et l'API voient le même état. Ce que la chaîne sait, le wallet l'affiche.
La console opérateur est en lecture seule : elle peut rechercher des adresses, les relier à des utilisateurs et tracer des flux — elle ne peut pas déplacer de fonds, car elle n'a jamais les clés. La meilleure réponse en conformité est une capacité qui n'existe pas.
Chaque wallet enregistré renvoie au User 360 de son propriétaire dans la console opérateur — soldes, appareils, niveau KYC et historique à un clic de l'adresse dont parle un client.
Les actions opérateur dans la console exigent un motif et sont auditées — la bannière de production le rappelle sur chaque écran. Le support agit vite sans agir en silence.
La feuille s'affiche dans votre application — votre navigation, votre marque, notre feuille. Les utilisateurs ne quittent jamais le parcours pour trouver un wallet ; il apparaît là où se fait le paiement.
Les wallets reçoivent un nom — Wallet principal, Épargne Solana, Cold storage — dès leur création. Un wallet que l'utilisateur peut nommer est un wallet qu'il comprend.
Le programme de démo fait tourner 84 120 wallets avec 99,99 % de disponibilité, sur les mêmes rails que chaque nouvelle intégration. Les chiffres sont en page d'accueil de la console, pas dans une présentation commerciale.
Écrans
Interface réelle du produit, avec des données de démo.
FAQ
Non. La génération des clés et la signature se font sur l'appareil de l'utilisateur — les clés n'atteignent jamais nos serveurs. Vous proposez des wallets dans votre app sans devenir dépositaire, et nous ne pourrions pas déplacer les fonds d'un utilisateur même en essayant.
Un appel — POST /v1/wallets — renvoie un wallet. Soldes, transferts et historique sont des endpoints, pas une infrastructure à monter, et le SDK affiche la feuille wallet dans votre app. Toute la surface est assez petite pour se lire d'une traite.
Non. La feuille du SDK s'intègre dans l'app hôte — votre navigation, votre marque, notre feuille. L'app hôte reste le produit ; le wallet est une fonctionnalité à l'intérieur, pas une prise de contrôle.
Des SDK pour iOS, Android, React Native et Web, et du multi-chain dès le premier jour sur toutes les grandes blockchains. L'écran de réception avertit même d'un envoi sur le mauvais réseau avant qu'il n'ait lieu.
Une phrase de récupération de douze mots, affichée une seule fois à la configuration pour être notée hors ligne, puis jamais redemandée. Les clés étant sur l'appareil, la récupération passe par la phrase de l'utilisateur — pas par un ticket au support.
Le support dispose d'une console en lecture seule avec recherche d'adresse par correspondance exacte — de quoi aider, jamais de quoi conserver. Des kill switches par action peuvent suspendre l'envoi, la réception, le swap ou l'achat dans toutes les apps, mais aucun opérateur ne peut déplacer les fonds d'un utilisateur.
Évaluer
Nous exécutons POST /v1/wallets avec vous et montrons la feuille du SDK intégrée dans une app hôte sur iOS, Android, React Native et Web.
Des clés d'API sur un environnement de test, pour que votre équipe crée des wallets, consulte les soldes et déplace des fonds de test de bout en bout.
Les quatre SDK de plateforme, les webhooks d'événements et la documentation d'intégration — de quoi embarquer un wallet dans votre propre app.
Constatez par vous-même que les clés sont générées et conservées sur l'appareil — vous proposez des wallets sans devenir dépositaire.
Whitelabel par conception — les wallets sont livrés dans votre app, sous votre marque.
Wallets conserve ce que Ramp achète et que Chain règle — et Safe est l'étape suivante quand les soldes cessent de bouger.
Tout ce qui précède tourne dans des démos en production que nous pouvons vous présenter — en standalone, en whitelabel ou en plateforme unique. Dites-nous ce que vous construisez et nous vous montrerons le chemin le plus court.
