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. On the way out, the balance is withdrawn as on-chain BTC with no swap, or to EVM through an atomic swap.
Lightning · Bitcoin · Micropayments · HTLC
$ exact-output
Merchants get paid in one crypto, Monero and Lightning included, 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; another gets paid in Monero or over Lightning and wants USDC: 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 one exception is the gas floats, Tron's first — energy there is burnt in TRX by the wallet itself, so that float only ever goes down. Below a threshold, the executor buys it back up, exact-output: the only spend it ever initiates on its own, allowed because the recipient is its own wallet, never a payload value — a duplicate costs a spread, not funds. And the chain that pays is picked on the gas reserve it keeps afterwards, not on price: all six candidates quoted within 0.3 % of each other.
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. Every new chain brings its own trap: on Sui, gas is always paid with the wallet's own coin objects — paid from an address balance, a ghost transaction and its rebuild would share no object version, and could both execute.
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. Anything that exists only once — an HTLC secret, a rail's one-shot deposit address, an order in flight — is written to disk before anything depends on it. 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. On less-served chains, liquidity is read on-chain rather than taken on an aggregator's word: VVS V2 on Cronos (the first V2 router it drives), DragonSwap on Sei — a SwapRouter02 fork whose renamed native helpers were found in the bytecode.
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, Across for HYPE (a relayer pays the merchant in 2 to 6 s out of its own inventory), Circle CCTP V2 for SEI (burn, attestation, and a mint the executor relays itself), Changelly for Monero, Satora for Lightning — and NEAR Intents as a general-purpose rail: it signs on five chain families (EVM, Tron, Solana, UTXO, Sui) 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: withdrawing a SEI balance chains DragonSwap, the CCTP bridge and, when needed, a last swap on the destination chain; a CRO balance, VVS then deBridge. Legs are verified before the route is offered, never after the funds have moved. And a leg that is already funded is never rejected: its input is the previous leg's output, the merchant's coins are already sold — any failure stalls it and pages, and its input is reserved so that no sweep and no other withdrawal can spend it.
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. Same logic when the source is Bitcoin: THORChain charges a flat outbound fee, NEAR Intents a roughly proportional cost — the latter costs about half as much between 25 and 150 $, where merchant withdrawals actually live; above that the gap closes, and THORChain wins back the large orders.
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 destination address counts too: a USDT transfer to a fresh address pays for allocating a storage slot, twice the energy of a send to an address that already holds some. And on Bitcoin, on the first live 21 $ payout, mining fees weighed three times as much as the rail.
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.
Anything that can make a payout impossible is checked before funding, not after: the executor asks the rail for a dry quote of the exact order, which creates nothing. A computed refusal — order too small, promise out of reach — rejects cleanly, wallet untouched. A temporary one, like a 100 $ minimum that appeared overnight on an origin chain, holds the withdrawal unfunded and re-probes it every 5 minutes. And a silent rail never gets a withdrawal rejected.
The first BTC payout through NEAR Intents was reported paid four minutes before the merchant was: the rail waits for confirmations before crediting a deposit, and the network went 22 minutes without a block. “Our transaction is confirmed” and “the rail has the money” are two different events. Since then, a rail that has not seen the delivery leaves the withdrawal in flight, and the order is recorded before broadcast so the question can be asked again after a restart. On the rails the gateway pays, the rail’s own status is never the proof: only an on-chain transfer of the right token to the merchant, for at least the promise, closes the withdrawal — on Monero it must even be mined after the withdrawal was created, so an older transfer to the same merchant cannot pass for it.
To take a Lightning balance out to EVM, the gateway pays a hold invoice locked to the hash of a secret only the executor holds, written to disk before the swap even exists. On the other side, Satora locks tBTC in an HTLC on Arbitrum (WBTC on Polygon). The claim swaps it on a DEX and pays the merchant in a single transaction — and it is that claim which, by revealing the secret, settles the Lightning payment. The secret is only revealed to a lock proven on-chain: emitted by the pinned contract, for our hash, still active, with time left. What the merchant receives is bound by the signed claim: at least the promise, or the transaction reverts — which costs nothing, the HTLC stays claimable. With no claim, the invoice expires and the sats return to the gateway on their own.
No decentralised rail carries XMR to date — THORChain shipped its Monero client without enabling the chain. So the way out is Changelly, and the gateway itself pays: at funding, the backoffice opens a fixed-rate order sized to deliver exactly the promise, decodes the deposit address (Monero base58, Keccak checksum) and records it before the gateway pays it. No hot wallet touches it and the executor signs nothing: it tracks the order. Once the money may have left, nothing rejects any more — a KYC freeze, a refund or an expired order pages at once and leaves the withdrawal to a human.
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. Every new rail ships with an offline selftest that runs the real code — the real loop, the real tronweb — against simulated nodes and APIs; the most sensitive ones also go through an independent review.
# merchant withdrawal flow
jupiter Solana · direct SPL delivery
evm v2/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 · SOL · UTXO · SUI sources
across HYPE → EVM · relayer fills in 2–6 s
cctp SEI → EVM · Circle burn/mint, self-relayed
changelly XMR → EVM · paid by the gateway
satora Lightning → EVM · atomic HTLC swap
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.
