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.
Lightning · Bitcoin · Micropaiements
$ exact-output
Le marchand encaisse dans une crypto, 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, y compris en multi-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 : 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.
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.
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. 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.
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), Symbiosis vers TRON, Omniston/STON.fi pour TON avec escrow HTLC, NEAR Intents vers Cardano, Sui et Stellar. Quand aucune route directe n'existe, le swap se compose en plusieurs sauts — par exemple un échange intra-chaîne puis un pont cross-chain — orchestrés comme une seule opération, avec les pièges de chaque rail documentés : fees natifs fixes, IDs de chaînes internes, sauts intermédiaires.
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é.
# flux d'un retrait marchand
jupiter Solana · livraison SPL directe
evm v3/v4 best-exec DEX · Permit2
thorchain LTC · DOGE · XRP · BCH · ATOM natifs
debridge EVM ↔ EVM/SOL · ordre livré ~15 s
symbiosis → TRON
omniston TON → EVM · escrow HTLC · multi-sauts
near-intents → ADA / SUI / XLM
flux et providers réels — extraits de la documentation du repo
~/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.
