corentin@feelb:~$ cd ~/blockchain
EnglishJ'ai construit et j'opère l'infrastructure complète d'Abyxo, passerelle de paiement multi-chain : nœuds, RPC/gRPC, encaissement, Lightning, swap & bridge, payouts. Cette page détaille chaque brique — le même socle peut porter votre produit.
~/blockchain/capacites
$ payment.confirmed
Passerelle de paiement complète : un processeur dédié par chaîne (13 en production, socle EVM générique pour les suivantes), détection des confirmations adaptée à chaque réseau, réconciliation automatique, stablecoins USDC / USDT / PYUSD. Du checkout au webhook marchand.
Shkeeper · Stablecoins · Webhooks
$ getblockchaininfo
Bitcoin, Ethereum, Litecoin, Dogecoin, Bitcoin Cash, Sui, Sei, Cronos, Hyperliquid… hébergés sur infrastructure propre — pas de dépendance à un fournisseur RPC tiers pour le cœur du système. Solana fait exception : les endpoints viennent d'un fournisseur tiers, appelé en direct. Monitoring de synchronisation et alerting sur le retard de blocs.
Bitcoin Core · Geth · Sui · Sei · Hyperliquid
$ erpc.yaml
Proxy eRPC devant les nœuds EVM : cache, failover automatique entre upstreams redondants — plusieurs nœuds maison par chaîne, fallbacks publics en dernier recours. Côté UTXO (Bitcoin, Litecoin, Dogecoin, Bitcoin Cash), c'est un load balancer HAProxy qui répartit sur les nœuds et sort ceux qui décrochent. Solana et les flux gRPC sont appelés en direct.
eRPC · HAProxy · Failover · Cache
$ HyperliquidL1Gateway
Gateway gRPC maison qui streame la L1 Hyperliquid depuis un nœud local : blocs, fills, diffs d'orderbook, events. Schéma compatible avec l'API commerciale équivalente, plus des RPC supplémentaires. Index Redis pour l'historique : de ~22 s à ~0,4 s sur un fichier horaire de 3,7 Go.
gRPC · Hyperliquid · Redis
$ lightning · 1 conf
Encaissement Bitcoin instantané via Lightning, en complément de l'on-chain : paiements à faible montant, confirmation immédiate, coûts réduits — le checkout choisit le rail selon le montant. À la sortie, le solde se retire en BTC on-chain sans swap, ou vers l'EVM par swap atomique.
Lightning · Bitcoin · Micropaiements · HTLC
$ exact-output
Le marchand encaisse dans une crypto, Monero et Lightning compris, et retire dans une autre : swaps exact-output (le montant promis est livré, au centime), routés au meilleur prix entre DEX on-chain et rails cross-chain. Les ponts sont mis en concurrence à chaque devis — le moins cher dépend du montant, pas seulement de la paire — et le swap se compose en plusieurs sauts quand aucune route directe n'existe. Détail complet ci-dessous — c'est la brique la plus sensible, elle mérite sa section.
Swap · Bridge · Multi-sauts · Best execution
~/blockchain/payout-executor
Un marchand encaisse en USDC et veut être payé en EUR-stable, en SOL ou sur TRON ; un autre encaisse en Monero ou sur Lightning et veut de l'USDC : entre les deux, il y a un système qui détient des clés et diffuse des transactions irréversibles. Voilà comment il est conçu.
Le backoffice (couche 1) décide : validation, routage, devis. L'exécuteur (couche 2) détient seul les hot wallets et signe. C'est un worker pull-based : aucune API entrante métier, un seul port ouvert pour les probes Kubernetes — il va chercher le travail via l'API interne authentifiée du backoffice. Les clés ne sont jamais exposées côté plan public.
Pour chaque retrait, l'exécuteur demande le montant source plus un buffer, attend l'arrivée des fonds, exécute le swap en exact-output, puis balaie le reliquat vers un wallet collecteur par chaîne. Le hot wallet ne porte jamais plus que le retrait en cours. Seule exception : les floats de gas, et celui de Tron en premier — l'énergie y est brûlée en TRX par le wallet lui-même, donc il ne fait que descendre. Sous un seuil, l'exécuteur rachète de quoi le remonter, en sortie exacte : c'est la seule dépense qu'il engage de lui-même, permise parce que le destinataire est son propre wallet, jamais une valeur du payload — un doublon coûte un spread, pas des fonds. Et la chaîne qui paie est choisie sur la réserve de gas qu'elle garde ensuite, pas sur le prix : les six candidates cotaient à 0,3 % l'une de l'autre.
Le txid est ancré avant la diffusion : sur Solana la signature est déterministe (fenêtre nulle), sur EVM la transaction est signée localement et son hash enregistré avant l'envoi, le nonce servant de second filet. Au redémarrage, le statut on-chain du dernier tx est revérifié avant toute reprise : confirmé → on clôture sans renvoyer ; en attente → on attend ; échoué → on reconstruit. Le même invariant vaut un cran plus haut, sur le funding : la tentative est ancrée en base avant l'appel, et si la réponse se perd on interroge son statut au lieu de la rejouer. Chaque nouvelle chaîne apporte son piège : sur Sui, le gas est toujours payé avec les objets du wallet — payé depuis un solde d'adresse, une transaction fantôme et sa reconstruction ne partageraient aucune version d'objet, et pourraient passer toutes les deux.
Les retraits orphelins (crash entre claim et complétion) sont repris automatiquement et de façon idempotente. Un échec avant diffusion balaie les fonds vers le collecteur et rejette proprement — rien ne reste bloqué sur le hot wallet. Tout ce qui n'existe qu'une fois — le secret d'un HTLC, l'adresse de dépôt à usage unique d'un rail, un ordre en vol — est écrit sur disque avant que quoi que ce soit n'en dépende. Chaque retrait a son propre fichier de log, qui raconte toute son histoire d'un seul tenant.
Sur EVM, chaque swap est quoté sur tous les DEX V3 (tous les fee tiers) et sur Uniswap V4 via l'Universal Router (Permit2, natif direct sans wrapping) — les quotes sont des eth_call gratuits — puis routé vers le moins cher. Testé en réel on-chain sur Arbitrum, Base et BNB Chain. Côté Solana : Jupiter, avec livraison SPL directe au marchand. Sur les chaînes moins servies, la liquidité est lue on-chain plutôt que prise au mot d'un agrégateur : VVS V2 sur Cronos (premier routeur V2 piloté), DragonSwap sur Sei — un fork de SwapRouter02 dont les helpers natifs renommés ont été retrouvés dans le bytecode.
THORChain pour la liquidité native LTC / DOGE / XRP / BCH / ATOM (TSS vaults, sans wrapping ni custody), deBridge DLN pour l'EVM↔EVM et Solana (un ordre livré par solver en ~15 s en conditions réelles), Omniston/STON.fi pour TON avec escrow HTLC, Symbiosis pour les chaînes que les autres desservent mal, Across pour HYPE (un relayer paie le marchand en 2 à 6 s sur son propre inventaire), Circle CCTP V2 pour SEI (burn, attestation, et un mint que l'exécuteur relaie lui-même), Changelly pour Monero, Satora pour Lightning — et NEAR Intents en rail généraliste : il signe sur cinq familles de chaînes (EVM, Tron, Solana, UTXO, Sui) et livre aussi bien Cardano, Sui ou Stellar qu'une paire EVM ordinaire, quand il est le moins cher.
Quand aucune route directe n'existe — une chaîne qu'un rail ne couvre pas, ou un actif qu'il ne couvre pas sur une chaîne qu'il couvre — le swap se compose en plusieurs sauts : sortir un solde SEI enchaîne DragonSwap, le pont CCTP et, si besoin, un dernier swap sur la chaîne d'arrivée ; un solde CRO, VVS puis deBridge. Les jambes sont vérifiées avant d'offrir la route, jamais après avoir déplacé les fonds. Et une jambe déjà financée n'est jamais rejetée : son entrée est la sortie de la précédente, les coins du marchand sont déjà vendus — tout échec la bloque et alerte, et son entrée est réservée pour qu'aucun balayage ni autre retrait ne la dépense.
Le choix du pont n'est pas une propriété de la paire mais du montant. À chaque devis, les rails cross-chain sont interrogés sur la même somme puis comparés sur le taux net : ce que le marchand reçoit, par unité de source réellement dépensée, frais fixes inclus. C'est cette inclusion qui rend la comparaison honnête — un frais plat n'apparaît pas dans le devis (il sort du float natif de l'exécuteur) et son poids ne dépend que de la taille de l'ordre. Le rail qui a de l'historique on-chain garde la main sur toute égalité et toute incertitude : il se fait déplacer par une mesure, jamais par un chiffre manquant. Même logique au départ du Bitcoin : THORChain facture une sortie plate, NEAR Intents un coût à peu près proportionnel — le second coûte environ moitié moins entre 25 et 150 $, là où vivent les retraits marchands ; au-delà l'écart se referme, et THORChain reprend les gros ordres.
Sur Tron, le coût dominant d'un paiement n'est pas le spread du rail mais l'énergie brûlée par le wallet — et l'énergie est une propriété de la forme de la transaction, pas de son montant. Un dépôt qui se réduit à un transfert ne touche aucun contrat ; passer par un routeur déclenche la pénalité d'énergie dynamique du contrat USDT. D'où une règle de routage assumée : sur cette chaîne, c'est la forme qui décide, pas la taille de l'ordre. Même raisonnement côté Solana, où le pont par défaut price mal le coin natif et ajoute un frais plat que son devis ne montre pas. L'adresse d'arrivée compte aussi : un transfert USDT vers une adresse neuve paie l'allocation d'un slot de stockage, deux fois l'énergie d'un envoi vers une adresse qui en détient déjà. Et sur Bitcoin, au premier paiement réel de 21 $, les frais de minage pesaient trois fois plus que le rail.
La passerelle de custody enregistre un paiement raté sous l'identifiant du retrait, puis refuse tout paiement ultérieur portant cet identifiant : demander trop tôt ne coûte pas la tentative, ça coûte le retrait. Le solde est donc lu avant chaque envoi, et un solde illisible compte comme insuffisant — une passerelle injoignable répond « 0 », ce qui ne doit jamais se lire comme un wallet vide. Trop court, le retrait est mis en attente plutôt qu'échoué : rien n'est envoyé, l'inbox ops est prévenue (seul un humain peut recharger un wallet chaud) et une tâche le repropose chaque minute, le plus ancien d'abord, jusqu'à ce que les fonds arrivent.
Tout ce qui peut rendre un paiement impossible se vérifie avant le funding, pas après : l'exécuteur demande au rail un devis à blanc de l'ordre exact, qui ne crée rien. Un refus calculé — ordre trop petit, promesse intenable — rejette proprement, wallet intact. Un refus temporaire, comme un plancher de 100 $ apparu du jour au lendemain sur une chaîne d'origine, met le retrait en attente sans le financer, re-sondé toutes les 5 minutes. Et un rail muet ne fait jamais rejeter un retrait.
Le premier paiement BTC via NEAR Intents a été rapporté payé quatre minutes avant que le marchand le soit : le rail attend des confirmations avant de créditer un dépôt, et le réseau a passé 22 minutes sans bloc. « Notre transaction est confirmée » et « le rail a l'argent » sont deux événements distincts. Depuis, un rail qui n'a pas vu la livraison laisse le retrait en cours, et l'ordre est enregistré avant la diffusion pour que la question puisse être reposée après un redémarrage. Sur les rails payés par la passerelle, le statut du rail n'est jamais la preuve : seul un transfert on-chain du bon token vers le marchand, d'au moins la promesse, clôt le retrait — côté Monero, il doit même avoir été miné après la création du retrait, pour qu'un ancien transfert au même marchand ne passe pas pour le sien.
Pour sortir un solde Lightning vers l'EVM, la passerelle paie une facture hold verrouillée sur le hash d'un secret que seul l'exécuteur détient, écrit sur disque avant que le swap n'existe. En face, Satora bloque du tBTC dans un HTLC sur Arbitrum (du WBTC sur Polygon). Le claim le swappe sur un DEX et paie le marchand en une seule transaction — et c'est lui qui, en révélant le secret, règle le paiement Lightning. Le secret n'est révélé qu'à un verrou prouvé on-chain : émis par le contrat épinglé, pour notre hash, encore actif, avec du temps devant lui. Ce que reçoit le marchand est borné par le claim signé : au moins la promesse, sinon la transaction revert — ce qui ne coûte rien, le HTLC reste claimable. Faute de claim, la facture expire et les sats reviennent seuls à la passerelle.
Aucun rail décentralisé ne porte XMR à ce jour — THORChain a livré son client Monero sans activer la chaîne. La sortie passe donc par Changelly, et c'est la passerelle elle-même qui paie : au funding, le backoffice ouvre un ordre à taux fixe dimensionné pour livrer exactement la promesse, décode l'adresse de dépôt (base58 Monero, checksum Keccak) et l'enregistre avant que la passerelle ne la paie. Aucun hot wallet n'y touche et l'exécuteur ne signe rien : il suit l'ordre. Dès que l'argent a pu partir, plus rien ne rejette — un gel pour KYC, un remboursement ou un ordre expiré alertent aussitôt et laissent le retrait à un humain.
DRY_RUN par défaut (l'exécuteur log la route complète sans rien signer), retry/backoff sur tout ce qui est transitoire mais jamais sur un envoi on-chain, Sentry pour les erreurs, et un état des providers qui distingue explicitement ce qui a été testé en réel on-chain de ce qui ne l'a pas été. Chaque nouveau rail arrive avec un selftest hors ligne qui fait tourner le vrai code — la vraie boucle, le vrai tronweb — contre des nœuds et des API simulés ; les plus sensibles passent en plus une relecture indépendante.
# flux d'un retrait marchand
jupiter Solana · livraison SPL directe
evm v2/v3/v4 best-exec DEX · Permit2
thorchain LTC · DOGE · XRP · BCH · ATOM natifs
debridge EVM ↔ EVM/SOL · ordre livré ~15 s
symbiosis TRON · chaînes mal desservies ailleurs
omniston TON → EVM · escrow HTLC · multi-sauts
near-intents sources EVM · Tron · SOL · UTXO · SUI
across HYPE → EVM · relayer en 2–6 s
cctp SEI → EVM · burn/mint Circle relayé
changelly XMR → EVM · payé par la passerelle
satora Lightning → EVM · swap atomique HTLC
flux et providers réels — extraits de la documentation du repo
# ce que coûte vraiment un pont — mesuré en conditions réelles
~/blockchain/chains
Un processeur d'encaissement dédié par chaîne, un socle EVM générique pour aller vite sur les suivantes — et les stablecoins USDC, USDT et PYUSD sur leurs réseaux respectifs.
Nœuds, endpoints RPC/gRPC, encaissement, payouts : je conçois, je déploie et j'opère — vous vous concentrez sur le produit.
