corentin@feelb:~$ cd ~/blockchain
FrançaisI built and operate the full infrastructure behind Abyxo, a multi-chain payment gateway: nodes, RPC/gRPC, acceptance, Lightning, swap & bridge, payouts. This page details every building block — the same foundation can power your product.
~/blockchain/capabilities
$ payment.confirmed
A complete payment gateway: one dedicated processor per chain (13 in production, plus a generic EVM base to onboard the next ones fast), per-network confirmation tracking, automatic reconciliation, USDC / USDT / PYUSD stablecoins. From checkout to merchant webhook.
Shkeeper · Stablecoins · Webhooks
$ getblockchaininfo
Bitcoin, Ethereum, Litecoin, Dogecoin, Bitcoin Cash, Sui, Sei, Cronos, Hyperliquid… running on our own infrastructure — no third-party RPC provider in the critical path. Solana is the exception: its endpoints come from a third-party provider, called directly. Sync monitoring with block-lag alerting.
Bitcoin Core · Geth · Sui · Sei · Hyperliquid
$ erpc.yaml
An eRPC proxy in front of the EVM nodes: caching, automatic failover across redundant upstreams — several in-house nodes per chain, public fallbacks as a last resort. On the UTXO side (Bitcoin, Litecoin, Dogecoin, Bitcoin Cash), an HAProxy load balancer spreads traffic across the nodes and pulls out any that fall behind. Solana and the gRPC streams are called directly.
eRPC · HAProxy · Failover · Cache
$ HyperliquidL1Gateway
An in-house gRPC gateway streaming the Hyperliquid L1 from a local node: blocks, fills, orderbook diffs, events. Wire-compatible with the equivalent commercial API, plus extra RPCs. Redis index for history lookups: from ~22 s down to ~0.4 s on a 3.7 GB hourly file.
gRPC · Hyperliquid · Redis
$ lightning · 1 conf
Instant Bitcoin acceptance over Lightning, alongside on-chain: low-value payments, immediate confirmation, lower costs — the checkout picks the rail based on amount.
Lightning · Bitcoin · Micropayments
$ exact-output
Merchants get paid in one crypto and withdraw in another: exact-output swaps (the promised amount is delivered, to the cent), routed at the best price across on-chain DEXs and cross-chain rails — including multi-hop when no direct route exists. Full detail below: it's the most sensitive part, it deserves its own section.
Swap · Bridge · Multi-hop · Best execution
~/blockchain/payout-executor
A merchant gets paid in USDC and wants to withdraw in a EUR-stable, in SOL, or on TRON: in between sits a system that holds keys and broadcasts irreversible transactions. Here is how it is designed.
The backoffice (layer 1) decides: validation, routing, quotes. The executor (layer 2) alone holds the hot wallets and signs. It's a pull-based worker: no inbound business API, a single open port for Kubernetes probes — it fetches work through the backoffice's authenticated internal API. Keys are never exposed on the public plane.
For each withdrawal, the executor requests the source amount plus a buffer, waits for the funds to arrive, executes the swap exact-output, then sweeps the remainder to a per-chain collector wallet. The hot wallet never carries more than the withdrawal in flight.
The txid is anchored before broadcast: on Solana the signature is deterministic (zero window), on EVM the transaction is signed locally and its hash recorded before sending, with the nonce as a second safety net. On restart, the last on-chain tx status is re-checked before resuming: confirmed → close without resending; pending → wait; failed → rebuild.
Orphaned withdrawals (a crash between claim and completion) are resumed automatically and idempotently. A failure before broadcast sweeps the funds to the collector and rejects cleanly — nothing stays stuck on the hot wallet. Every withdrawal gets its own log file telling its full story in one place.
On EVM, every swap is quoted on all V3 DEXs (all fee tiers) and on Uniswap V4 through the Universal Router (Permit2, native assets without wrapping) — quotes are free eth_calls — then routed to the cheapest venue. Tested live on-chain on Arbitrum, Base and BNB Chain. On Solana: Jupiter, with direct SPL delivery to the merchant.
THORChain for native LTC / DOGE / XRP / BCH / ATOM liquidity (TSS vaults, no wrapping, no custody), deBridge DLN for EVM↔EVM and Solana (an order settled by a solver in ~15 s under real conditions), Symbiosis to TRON, Omniston/STON.fi for TON with HTLC escrow, NEAR Intents to Cardano, Sui and Stellar. When no direct route exists, the swap is composed of several hops — say an intra-chain exchange followed by a cross-chain bridge — orchestrated as a single operation, with each rail's pitfalls documented: fixed native fees, internal chain IDs, intermediate hops.
DRY_RUN by default (the executor logs the full route without signing anything), retry/backoff on everything transient but never on an on-chain send, Sentry for errors, and a provider status list that explicitly separates what has been tested live on-chain from what has not.
# merchant withdrawal flow
jupiter Solana · direct SPL delivery
evm v3/v4 best-exec DEX · Permit2
thorchain native LTC · DOGE · XRP · BCH · ATOM
debridge EVM ↔ EVM/SOL · settled in ~15 s
symbiosis → TRON
omniston TON → EVM · HTLC escrow · multi-hop
near-intents → ADA / SUI / XLM
real flow and providers — taken from the repo documentation
~/blockchain/chains
One dedicated acceptance processor per chain, a generic EVM base to move fast on the next ones — and USDC, USDT and PYUSD stablecoins on their respective networks.
Nodes, RPC/gRPC endpoints, payment acceptance, payouts: I design, deploy and operate — you focus on the product.
