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. Bridges are shopped against each other on every quote — the cheapest one depends on the amount, not just the pair — and the swap is composed of several hops 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. The same invariant holds one layer up, on funding: the attempt is anchored in the database before the call, and if the response is lost its status is looked up rather than the call replayed.
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), Omniston/STON.fi for TON with HTLC escrow, Symbiosis for the chains the others serve poorly, NEAR Intents as a general-purpose rail — it signs on three chain families (EVM, Tron, Solana) and delivers Cardano, Sui or Stellar just as readily as an ordinary EVM pair, whenever it comes out cheapest. When no direct route exists — a chain a rail has no liquidity on, or an asset it lacks on a chain it does cover — the swap is composed of several hops, orchestrated as a single operation: both legs are verified before the route is offered, never after the funds have moved.
Which bridge to use is a property of the amount, not of the pair. On every quote, the cross-chain rails are priced on the same sum and compared on the net rate: what the merchant receives, per unit of source actually spent, fixed fees included. That inclusion is what makes the comparison honest — a flat fee never shows up in the quote (it comes out of the executor's native float) and its weight is purely a function of order size. The rail with live on-chain history keeps the route on every tie and every uncertainty: it gets displaced by a measurement, never by a missing number.
On Tron, the dominant cost of a payout is not the rail spread but the energy the wallet burns — and energy is a property of the transaction shape, not of its amount. A deposit that reduces to a transfer touches no contract; going through a router triggers the USDT contract's dynamic energy penalty. Hence a deliberate routing rule: on that chain, shape decides, not order size. Same reasoning on Solana, where the default bridge misprices the native coin and adds a flat fee its quote does not show.
The custody gateway records a failed payout under the withdrawal id, then refuses every later payout carrying that id: asking too early does not cost the attempt, it costs the withdrawal. So the balance is read before every send, and an unreadable balance counts as insufficient — an unreachable gateway answers "0", which must never read as an empty wallet. Short, the withdrawal is parked rather than failed: nothing is sent, the ops inbox is paged (only a human can top up a hot wallet), and a scheduled task re-offers it every minute, oldest first, until the funds land.
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 · chains others serve poorly
omniston TON → EVM · HTLC escrow · multi-hop
near-intents EVM · Tron · Solana sources · ADA/SUI/XLM
real flow and providers — taken from the repo documentation
# what a bridge really costs — measured under real conditions
~/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.
