DZEKA

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 04 · MISSION BRIEFING

Payment Rail

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

ROLEDESIGN → BUILD → OPERATE
TIMELINE2026 — PRESENT
STACKGO · POSTGRES · KAFKA · EVM · gRPC
STATUSSHIPPED · M7 / M7 ↗
Live capture against the real stack: the dev stack comes up (Postgres and Redpanda healthy), a payment is created via curl and replayed with the same idempotency key — same payment back, no double-spend — then a 5,000-payment load test at 32 workers and an append-only audit-chain verification.

LEVEL 1THE PROBLEM

Sending an ERC-20 transfer is trivial. Being the company that owes someone money — at volume, on a rail that can reorganise underneath you — is not, and the people carrying that risk are finance and ops, not the engineer who wrote the transfer call. 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

Seven 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 (paired with an EVM chain adapter that builds and broadcasts USDC transfers), a reorg-safe chain-watcher, a transactional outbox relay that drains domain events to Kafka, a webhook dispatcher that HMAC-signs every delivery, and an operator CLI for approvals, replays, and audit checks. Idempotency at every failure boundary, correctness chosen over throughput, and every decision written up as an ADR.

Payment Rail system architecture Clients and the paymentrailctl CLI call the api service, whose in-process ledger writes double-entry postings and an outbox to PostgreSQL; outboxrelay drains the outbox into Kafka for webhookd's signed webhooks, while the isolated signer broadcasts transactions to EVM testnets and chainwatcher polls confirmations back into the ledger. PAYMENT RAIL 7 Go binaries clients REST paymentrailctl operator CLI api REST payments API in-process one atomic tx ledger double-entry signer isolated - no DB gRPC chainwatcher confirms + reorgs confirmation effects PostgreSQL ledger + outbox idempotency SQL outbox outboxrelay drains outbox Kafka Redpanda domain events webhookd signed delivery signed webhooks EVM chains Base + Ethereum Sepolia testnets broadcast poll Go binary store / rail external chain system boundary

BOSS FIGHTTHE RESULT

Feature-complete: every milestone from M0 to M7 landed — the idempotent ledger + payments API, the isolated signer + EVM submit path, reorg-safe settlement, a transactional outbox → Kafka → signed-webhook delivery pipeline, policy/velocity/four-eyes controls backed by an append-only hash-chained audit log, treasury reconciliation with a proof-of-reserves check, and a fault-injection chaos suite plus a published load-test benchmark (~568 req/s sustained, P99 146.5 ms on a local single-host bench). Testnet only, not audited — a portfolio & learning project built in the open. The full stack boots from the README in under ten minutes, on a machine I have never touched.

HIGH SCORES

  • 568REQ/S SUSTAINEDLOCAL BENCH · LOOPBACK
  • 45.7 MSP50 LATENCYCONCURRENCY 32
  • 147 MSP99 LATENCYCONCURRENCY 32
  • 0ERRORS25,000 REQUESTS
  • 7GO BINARIESONE MODULE
  • 30ADRSDECISIONS RECORDED
NEXT LEVEL
Tollgate