INSERT COIN — PITCH AN IDEA

Got something worth a cabinet? One coin, one pitch. I read every one.

PROCESSING CREDIT…
CREDIT ACCEPTED
idea launched — I'll ping you soon
+1 CREDIT · PLAYER TWO JOINED
← BACK TO THE FLOOR
SYSTEM 01 · MISSION BRIEFING

Payment Rail

A stablecoin payment orchestration rail in Go — payments-grade correctness over crypto rails.

ROLESOLO — EVERYTHING
TIMELINE2026 — PRESENT
STACKGO · POSTGRES · KAFKA · EVM · gRPC

LEVEL 1THE PROBLEM

Sending an ERC-20 transfer is trivial; running stablecoin payouts as a business function is not. You need idempotent initiation, a ledger that survives crashes and retries without double-spends, and confirmation tracking that stays correct when the chain reorgs. Payment Rail is that missing layer — a self-hostable service that treats blockchains as unreliable settlement rails behind a boring, correct, auditable payments API. Traditional business in the front, crypto rails in the back.

LEVEL 2THE BUILD

Six Go binaries in one module: a REST payments API, an in-process double-entry ledger (Postgres is the source of truth, balances derived from history), a network-isolated gRPC signer that signs only well-formed EIP-1559 payloads under a per-key spend cap, an EVM chain adapter that builds and broadcasts USDC transfers, a reorg-safe chain-watcher, and a webhook dispatcher fed by a transactional outbox → Kafka. Idempotency at every failure boundary, correctness chosen over throughput, and every decision written up as an ADR.

BOSS FIGHTTHE RESULT

Testnet only, not audited — a portfolio & learning project built in the open, milestone by milestone. Shipped so far: the idempotent ledger + payments API (M1), the signer + EVM submit path (M2), reorg-safe settlement tracking (M3), and the transactional outbox → Kafka relay (M4, in progress). Next up: policy engine + audit log, reconciliation, and published chaos/load benchmarks. The full stack boots from the README in under ten minutes.

WHAT'S NEXT
The Lab — now building