DEV Community: Felipe Ascari

Fintech on Go: Signing, event loops, and replay protection without an SDK (Part 2)

Felipe Ascari — Sat, 02 May 2026 14:57:39 +0000

Part 2 of a two-part case study on building an ERC-20 rewards service in Go. This one covers stdlib signing, the event loop shape that runs the async pipelines, and replay protection at the consumer end.

TL;DR

Signing an on-chain transaction is two library calls. crypto/ecdsa plus go-ethereum/types land it in five lines.
Event pipelines are one for { select } over three channels. The same shape runs the deposit monitor and the reconciler.
Reach for Zerohash, Fireblocks, or Circle first. Write this code only when self-custody is part of the product.
Go does not give you ABI (Application Binary Interface) encoding, reorg handling, gas estimation, or HSM (Hardware Security Module) integration. Those are domain problems, not language problems.

Recap of Part 1

Part 1 covered three consistency problems in an ERC-20 (Ethereum's fungible token standard) backend: ordering (nonce sequencing across goroutines and replicas), resulting (idempotent retries that do not double-mint), and atomicity (the Transactional Outbox pattern that keeps Postgres and the broker in agreement). How Go's explicit error values turn each failure case into a named domain object ran through all three. Part 2 picks up where atomic dispatch hands off to the live chain: signing, event loops, and replay protection.

Read Part 1: what the language solves in a crypto backend

When to reach for an SDK

Custody is hard, and compliance is harder. Before any of this code earns its place, the commercial alternatives deserve the opening paragraph.

Provider	What it abstracts
Zerohash	Custody, signing, settlement, and compliance for fintechs
Fireblocks	Institutional custody with MPC (Multi-Party Computation) and a policy engine
Circle	USDC issuance, payouts, treasury, and a wallets API
Coinbase Prime	Institutional custody and trading with an API
BitGo	Multi-sig custody, staking, and a wallets API

An SDK (Software Development Kit) is the correct choice when crypto sits next to the core business, per-transaction fees are acceptable at the target volume, on-chain programmability requirements are shallow, and the team does not want to own signing key material. The self-custody path is correct when custody is part of the product, BaaS (Blockchain as a Service) fees stop being economic at scale, programmability exceeds what the SDK exposes, or regulation forces in-house signing. A Go service on this path ships as a single static binary. CGO_ENABLED=0 go build produces an executable that runs on a gcr.io/distroless/static base image. No shell, no package manager, and the container layer stays under 20MB. A Node or JVM (Java Virtual Machine) service at the same stage carries its runtime, its dependency tree, and warm-up time before the first signing call. The patterns below assume the second path, and most of them still apply to any team that writes wrappers around a BaaS response.

Problem 4: signing with the stdlib

A conventional payment API looks like stripe.Charge.Create(params). The SDK handles authentication, idempotency keys, retries, and webhooks. For an on-chain transaction with self-custody, no equivalent exists. Part 1 closed with an event dispatched from the Transactional Outbox. The worker downstream of the broker signs that event and broadcasts it to the chain. The backend computes transaction bytes, signs them with the wallet's private key, and submits the result to an RPC (Remote Procedure Call) endpoint. In Go, that is five lines:

signer := types.NewLondonSigner(chainID)
signed, err := types.SignTx(unsigned, signer, privateKey)
if err != nil {
    return common.Hash{}, fmt.Errorf("sign tx for %s: %w", from.Hex(), err)
}
return signed.Hash(), client.SendTransaction(ctx, signed)

NewLondonSigner encodes the chain identity and selects EIP-1559 rules. SignTx computes the ECDSA (Elliptic Curve Digital Signature Algorithm) signature over the RLP (Recursive Length Prefix) encoded transaction. These are native Go implementations, not bindings to a C library or a JNI (Java Native Interface) wrapper. The source is in go-ethereum/core/types and readable in the same language the service ships. The returned transaction carries its signature, and its hash is the broadcast identifier the database persists. SendTransaction is the RPC, and ctx carries the trace ID and the deadline.

Where the key lives is the real question. An environment variable is fine for development and for nothing else. Cloud KMS (Key Management Service, available as AWS KMS or Google Cloud KMS) is the right default for staging and low-volume production. crypto/ecdsa does not sign against a KMS directly. The integration is a thin adapter that calls the KMS Sign API and returns the r, s, v tuple that the go-ethereum signer wraps. HSM or MPC is the answer at high volume, where signing latency climbs into the hundreds of milliseconds per call and key caching becomes a correctness question rather than a performance one.

ECDSA runs at P99 (99th-percentile latency) under 10ms on modern hardware. Go's garbage collector does not pause the goroutine running ECDSA for the duration of a full heap scan. JVM signers without careful GC tuning can spike at the wrong moment. For a service with a broadcast SLA (Service Level Agreement), predictable latency is more valuable than raw throughput, and Go's concurrent GC delivers it without configuration.

Signing itself is CPU-local and fast. The temptation is to run a goroutine per transaction. Part 1 is the reason not to. Two goroutines signing from the same wallet race on the nonce. The correct parallelism axis is across wallets, not across transactions from one wallet. That is why Part 1 and Part 2 are one series rather than two.

Problem 5: event pipelines

Every crypto backend runs at least two long-running loops. A deposit monitor that ingests inbound transfers, and a reconciler that heals state when the database and the chain disagree. Each one must survive rolling deploys, propagate context into every downstream call, and shut down within the Kubernetes grace period. The pattern is the same in each:

func (r Relay) Run(ctx context.Context) {
    ticker := time.NewTicker(r.interval)
    defer ticker.Stop()
    for {
        select {
        case <-ctx.Done():
            return
        case <-r.done:
            return
        case <-ticker.C:
            r.tick(ctx)
        }
    }
}

Three channels and one select. ctx.Done() catches external cancellation. SIGTERM (the Unix process termination signal) from Kubernetes lands here when the runtime is wired with signal.NotifyContext. r.done catches internal shutdown, for example a health-check failure that asks the component to exit before the pod does. ticker.C drives the work cadence, and r.tick(ctx) passes the context forward so downstream RPC calls inherit the deadline and the trace ID.

Why not cron? Three reasons. The loop carries in-memory state across ticks, a cached block height for example, which cron cannot. The loop propagates context, which cron cannot. The loop shuts down deterministically on SIGTERM, which cron does not. A cron job that misses a tick because the previous invocation is still running is a distributed systems bug waiting to happen.

Two failure modes live inside this pattern. Omitting defer ticker.Stop() leaks the ticker's internal goroutine across hot reloads. Calling r.tick(context.Background()) instead of forwarding ctx severs trace propagation and deadline cascading, which turns a single slow RPC into a stuck loop.

Shutdown is handled with sync.Once to make Stop safe to call from multiple goroutines without closing a channel twice:

func (m *DepositMonitor) Stop() {
    m.once.Do(func() {
        close(m.quit)
    })
}

close(m.quit) unblocks the case <-m.quit branch in the for { select } loop. sync.Once guarantees the close happens exactly once regardless of how many callers race on shutdown. The pattern composes cleanly with os/signal.NotifyContext: the signal handler cancels the context, the loop exits, the caller calls Stop as cleanup, and once.Do is a no-op.

Bounded workers when the tick fans out

The for { select } loop fires every interval. A naive tick walks a work list serially, which is proportional at lower volumes. A service scanning hundreds of wallets per tick needs bounded parallelism: dispatch each wallet to its own goroutine, cap the concurrency so the RPC pool does not starve, and wire shutdown to the same context that kills the outer loop. errgroup.WithContext plus semaphore.NewWeighted from golang.org/x/sync gives that in 20 lines:

func (m DepositMonitor) tick(ctx context.Context) {
    wallets := m.repo.ActiveWallets(ctx)
    sem := semaphore.NewWeighted(8)
    g, gctx := errgroup.WithContext(ctx)

    for _, w := range wallets {
        if err := sem.Acquire(gctx, 1); err != nil {
            return
        }
        g.Go(func() error {
            defer sem.Release(1)
            return m.scanWallet(gctx, w)
        })
    }
    if err := g.Wait(); err != nil {
        m.log.ErrorContext(ctx, "tick failed", "err", err)
    }
}

Eight workers, one errgroup, one shared context. If the outer loop receives SIGTERM, gctx cancels, sem.Acquire returns immediately, in-flight workers finish the RPC call they already started and release, and g.Wait returns within the Kubernetes grace period. The first worker that fails cancels the rest through the errgroup, which matches the semantics the operator wants: a systemic RPC outage stops the tick fast instead of burning budget on 200 timeouts.

When does this lose to Kafka Connect, Debezium, or Flink? When the event rate dwarfs what a single process can reasonably handle, when the business already operates a streaming platform, or when the downstream consumers are polyglot. Until one of those holds, a 20-line Go worker pool beats a pipeline you do not own on ownership, operability, and on-call surface.

Problem 6: replay protection and idempotent consumption

Confirmed events from the chain are not the end of the pipeline. A deposit that triggers a credit in the database must not be credited twice when the deposit monitor restarts mid-batch, when the RPC provider replays a block, or when a reorg heals and the same log surfaces again. The contract the backend needs from the loop is at-least-once delivery with idempotent consumption. The chain gives the first half. The database enforces the second.

Two primitives carry the work. A unique constraint on (tx_hash, log_index) in the table that records processed events, and a persisted offset that records how far the monitor has scanned. The offset lets the loop resume after a crash without rescanning from genesis. The unique constraint lets a rescan be safe when it happens anyway.

func (m DepositMonitor) consume(ctx context.Context, ev Event) error {
    return m.tx.WithTransaction(ctx, func(ctx context.Context) error {
        if err := m.repo.MarkProcessed(ctx, ev.TxHash, ev.LogIndex); err != nil {
            if errors.Is(err, domain.ErrAlreadyProcessed) {
                return nil
            }
            return fmt.Errorf("marking event: %w", err)
        }
        return m.repo.CreditUser(ctx, ev.To, ev.Amount)
    })
}

Three properties fall out of this shape. MarkProcessed returns ErrAlreadyProcessed when the unique constraint rejects the insert, and the transaction commits a no-op instead of a double credit. The credit and the dedup row commit in the same transaction, so a partial apply is impossible. And the unique index is the source of truth, not the application cache, which means a new replica coming up cold cannot double-spend a replayed event.

Why not rely on the chain to tell you what is confirmed? Because the chain does not know what your backend has already done with its confirmed events. The database is the only actor with that memory. Every other pattern in this series leans on the same principle: the chain is the source of events, the database is the source of effects.

What Go does not give you

The language does not know what a reorg is. It does not know that an ABI change on a contract you do not own can break decoding in production six months after deploy. It does not know that a gas price estimate from a public RPC can lag the mempool by a full block. It does not know that a signing key must never leave an HSM or a cloud KMS, and that every path that touches the private key must be audited on every pull request.

It also does not hide its costs. Spring and NestJS carry request scope through ThreadLocal and AsyncLocalStorage, and the developer rarely sees it. Go forces ctx context.Context as the first parameter of every function that touches I/O. A misplaced context.Background() severs trace propagation and deadline cascading in one line. That explicitness is a virtue under load and a tax under review. A payments codebase that takes the tax seriously catches the bug before it ships.

The Transactional Outbox pattern from Part 1 covers the case where the write and the publish share a database. When the operation crosses service boundaries with independent stores, Outbox is not enough, and saga becomes the next pattern to reach for. I wrote the distributed version in a separate piece on concurrent transactions, saga, queues, and DDD (Domain-Driven Design) aggregates, which pairs with the in-process patterns covered here.

The stack this series leans on is Go plus Postgres plus an RPC provider. What sits above that is a design problem, not a language problem. Go makes the solutions short. It does not write them for you.

The honest take

Two articles, six patterns, zero frameworks. These Go properties directly earned their place in this domain.

Goroutines cheap enough to run one per monitored wallet without a thread pool
for { select } as the full concurrency model for a background worker
CGO_ENABLED=0 for a static binary under 20MB, no runtime required
crypto/ecdsa with no C bindings or JNI overhead
context.Context as the single pipe for cancellation, deadlines, and trace IDs

None of that is a reason to rewrite a working Java or Python service. It is a reason to start a new fintech service here.

If your team is evaluating stacks for a service that signs transactions, monitors a chain, or enforces idempotency against a public RPC endpoint, the patterns above are the argument. They fit the language without adapters or base classes.

There is one honest caveat. Go does not shrink the domain. Reorg handling, gas estimation under congestion, HSM integration, and contract ABI upgrades are still hard engineering problems. The language makes the implementation shorter. The domain knowledge is still yours to carry.

Building something similar, or hitting a problem not covered here? Drop questions and corrections in the comments.

References

go-ethereum: official Go implementation of the Ethereum protocol. Source of TokenContract, types.SignTx, and signer types used in code snippets.
golang.org/x/sync: errgroup and semaphore packages referenced in the bounded-workers pattern.
Martin Kleppmann, How to do distributed locking: context for the replay protection and fencing approach covered in Part 1.
Fireblocks MPC Wallet API: managed signing alternative when self-custody is not viable.
Zerohash Developer Docs: regulated crypto settlement infrastructure with API, webhooks, and SDK for fintechs.
Circle Developer Platform: programmable USDC wallets and payments APIs.
Coinbase Prime API: institutional custody, trading, and custody APIs for financial institutions.
BitGo: multi-sig custody, staking, and wallet services API.
fascari/cashback-platform: Go blockchain adapter service used as the running example throughout this series.

This is part 2 of a two-part series on Fintech on Go. Part 1 covered nonce sequencing, idempotent ERC-20 minting, and the Transactional Outbox pattern, the three consistency problems that surface before a transaction is signed and broadcast.

Fintech on Go: what the language solves in a crypto backend (Part 1)

Felipe Ascari — Thu, 23 Apr 2026 19:39:05 +0000

A two-part case study on building an ERC-20 rewards service in Go, covering goroutines, replicas, and the consistency problems that surface before a transaction is signed. Part 1 tackles nonce sequencing and idempotency.

TL;DR

A crypto payments backend holds state in two systems that disagree often: Postgres and the Ethereum chain. Consistency breaks at three points in an ERC-20 (Ethereum's fungible token standard) transfer. Before the broadcast, the nonce must be ordered correctly. After the broadcast, retries must be idempotent. Between the database commit and the broker that dispatches to the chain, the Transactional Outbox closes the atomicity gap. All three break because the backend is concurrent. All three resolve with the same move: coordinate outside the Go process, let Postgres be the arbiter, and make the outcome explicit in the return type. Every failure mode has a name and a type. Go's explicit error values turn financial failure cases into auditable domain objects, not hidden exceptions. Part 2 covers signing, event loops, and replay protection.

Why I wrote this

Go is the dominant language in the backend layer of crypto fintech. Kraken, Coinbase, Zerohash, Circle, Fireblocks, and go-ethereum itself run on Go. The Rust wave belongs to validators and consensus nodes, not the application layer that moves money and reconciles state.

I worked on Mercado Envios while Mercado Pago was building Mercado Coin and MELI Dolar. Recurring leadership meetings on those products pulled me into studying this niche. The running example mints ERC-20 tokens across goroutines and replicas.

Why Go for this layer

Tech leads ask this before they pick a stack, so here is the case in plain terms.

go-ethereum is Go, not a binding. The reference Ethereum implementation is written in Go. ethclient.Dial, types.SignTx, and crypto/ecdsa are not wrappers around a C library or JNI bindings to a Java implementation. They are the source code you can read, audit, and step through in a debugger in the same language you ship. When behavior at the protocol level is ambiguous, reading go-ethereum/core/types is the answer. Node and Java teams open a translation layer; Go teams open the same repository.

Interfaces over go-ethereum enable testing without a live node. The service defines a four-method EthereumClient interface at the use case layer:

type EthereumClient interface {
    SendTransaction(ctx context.Context, tx *types.Transaction) error
    SuggestGasPrice(ctx context.Context) (*big.Int, error)
    TransactionReceipt(ctx context.Context, txHash common.Hash) (*types.Receipt, error)
    PendingNonceAt(ctx context.Context, addr common.Address) (uint64, error)
}

A test replaces this with a struct returning canned receipts. No test container, no Anvil instance, no docker-compose up. Go's implicit interface satisfaction means the concrete ethclient.Client satisfies this interface without a single annotation. The interface lives in the use case, not next to its implementation, which is the dependency direction that keeps business logic framework-free.

Context cancellation reaches the last provider. A request walks from HTTP handler to use case to repository to the signer to one or more RPC (Remote Procedure Call) providers. Every function accepts a context.Context, and a client disconnect or a 3-second deadline at the top propagates to the last eth_getTransactionByHash call without glue code. Java teams emulate this with CompletableFuture and thread pools, Node teams reach for AsyncLocalStorage or abort controllers. In Go the cancellation is the function signature.

Errors are domain values, not exceptions. The mint use case returns a MintResult struct with a Retryable bool field. A caller retrying an in-flight broadcast reads that field and decides. Nothing propagates silently up a call stack. No catch (TransientException e) that hides a second case. In a payment system, every failure path has a financial consequence, and Go forces you to name it at the boundary where it occurs.

The concurrency primitives (goroutines, channels, errgroup) are in the language, not bolted on. 1,000 goroutines cost roughly 2MB of stack. A thread pool at the same count costs off-heap buffers and tuning. Part 2 shows the event loop that orchestrates signing and confirmation across all of this without losing work across restarts.

What makes these backends different

Two systems of record that disagree often. Postgres gives ACID and strong consistency inside its own transaction boundary. The chain gives probabilistic finality. A pending transaction can be reordered, dropped, or reorged before the receipt arrives. A confirmed receipt is still subject to short-window reorgs that senior teams handle by waiting N block confirmations. In CAP terms, Postgres is CP within the cluster and the chain is AP with eventual, probabilistic convergence. The job of the backend is not to move tokens. The job is to keep these two registers consistent under partial failure while many goroutines touch them at the same time.

Three consistency problems encode that job: ordering before the broadcast (nonce), resulting after the broadcast (idempotency), and atomicity across the database and the broker that feeds the chain. This article covers all three. Part 2 picks up from where atomic dispatch hands off to the live chain, covering signing, event loops, and replay protection.

Problem 1: nonce sequencing, before the broadcast

Every transaction from an Ethereum-style wallet carries a sequential nonce, the per-wallet counter that orders transactions from a single address. The service signs from a single hot wallet. Many goroutines issue mints in parallel, and the service runs in replicas behind a load balancer. Two goroutines that sign with the same nonce lose one of the broadcasts. A skipped nonce stalls every subsequent transaction from that wallet until an on-call engineer sends a no-op self-transfer at the missing nonce. Serialization is mandatory.

Why a mutex alone is not enough

sync.Mutex protects state inside one process. The nonce is shared across replicas and must survive a restart, so coordination has to live outside Go's memory. Redis provides cross-process mutual exclusion with a TTL that handles crashed holders. On its own, Redis cannot detect the case where the lock expired mid-transaction and another replica moved ahead. The stale holder would still come back and commit over the new state.

A fencing token, following Martin Kleppmann's argument against distributed locks used alone, closes that gap. I wrote a standalone piece on the theory at distributed locks and fencing tokens. This section takes the theory as given and walks how it composes on top of SELECT FOR UPDATE.

The flow

Redis is the outer gate. Postgres is the arbiter. The fence travels from Redis into the transaction, so a stale holder whose TTL lapsed mid-BEGIN is rejected at commit time.

The composition, in code

func (r Repository) incrementInTx(ctx context.Context, wallet string, fence int64) (int64, error) {
    var current int64
    err := r.db.WithContext(ctx).Transaction(func(tx *gorm.DB) error {
        m := new(walletNonceModel)
        if err := tx.Clauses(clause.Locking{Strength: "UPDATE"}).
            Where("wallet_address = ?", wallet).
            First(m).Error; err != nil {
            return err
        }
        if fence <= m.FenceToken {
            return ErrStaleLockToken
        }
        current = m.CurrentNonce
        m.CurrentNonce++
        m.FenceToken = fence
        return tx.Save(m).Error
    })
    return current, err
}

Tradeoffs

Mechanism	Cross-replica safe	Survives TTL expiry	Cost	Fit
`sync.Mutex`	No	N/A	Free	In-process only, fails on restart
Postgres advisory lock	Single master only	N/A	Free	No cross-region
Redis `SET NX PX` alone	Yes	No	1 RTT	Stale writer wins
Redis + fence + `SELECT FOR UPDATE`	Yes	Yes	1 RTT + row lock	Chosen: correctness critical

Failure modes

TTL expires mid-transaction. A second replica acquires the lock, increments the fence, and commits. When the stale holder finally reaches its commit, the fence comparison returns ErrStaleLockToken and the caller retries with a fresh fence.
Process crashes after releasing Redis but before the database commit. The uncommitted transaction is rolled back, and the next broadcast re-reads the pre-commit nonce. No data is lost.
Replicas partition from each other. Postgres is still the final arbiter. A reconciler calls SyncFromChain(ctx, wallet, nonce) which upserts the nonce on ON CONFLICT and heals drift.

Bridge

A correct nonce guarantees ordering before the broadcast. It does not guarantee the broadcast happens at most once. If the process dies between the RPC that sends the transaction and the database write that records the hash, a retry has no way to know the transaction already went out.

Problem 2: idempotent broadcast, after the broadcast

A broadcast is a side effect with no undo. Once the signed transaction leaves the process, the mempool owns it. The backend now faces a classic dual-write problem: the local database needs to record the hash, the chain already holds the pending transaction, and the process can die in between. With goroutines retrying failed or stuck mints in parallel, two retries of the same logical transfer must not produce two broadcasts. A double broadcast credits the user twice and the treasury loses the difference. Retrying blindly double-spends. Treating every unknown state as failure loses funds. Idempotency answers this at the API surface, and a UNIQUE constraint on idempotency_key is the last-line backstop that refuses duplicates even when the application retries aggressively.

The state machine

Four states, one per outcome the caller needs to distinguish. The state is stored by idempotency_key in the database, so the same check works across replicas and across restarts. Each state has its own explicit return:

if tx.Status == domain.TransactionStatusPending && time.Since(tx.CreatedAt) < 30*time.Second {
    return tx, &MintResult{Success: false, Retryable: true}, nil
}

Explicit results, not exceptions

type MintResult struct {
    Success         bool
    TransactionHash string
    BlockNumber     int64
    Status          string
    ErrorCode       string
    ErrorMessage    string
    Retryable       bool
}

Retryable is the field to internalize. It is not a wrapped exception, not a magic error code, but a boolean on a result struct that maps to a gRPC response, an HTTP body, and a client that decides whether to retry. Go's insistence on explicit returns turns the four-state machine into visible, testable API surface.

This is the errors-as-values pattern applied to a financial domain. Java and Kotlin throw TransientException and trust the caller's catch hierarchy. Node rejects with an error object that might or might not carry a retry signal. In Go, the contract is part of the type: Retryable bool is documented in the struct, enforced by the compiler, and visible in code review. Every failure case in a money system has a financial consequence. Naming them in the type system is not optional.

Failure modes

The process crashes between the SendTransaction RPC and the database insert. On restart, the worker queries by idempotency key, finds nothing, and starts a new broadcast. If the first RPC went through, the chain now holds a pending transaction whose hash the service does not know. A reconciler that watches the mempool by sender address heals that state.
A transaction sits in Pending for more than thirty seconds. The state machine transitions it to PendingStuck and returns Retryable: true. The caller backs off instead of holding an open request.

The database is the arbiter. Not the chain, not in-process memory, not the caller.

Retry orchestration without a framework

The state machine answers what to do when the caller asks again. It does not by itself drive the retries. A retry loop wraps every mint call with a deadline, exponential backoff with jitter, and a context that cancels every nested RPC when the budget runs out. The entire orchestration lives in the standard library plus one golang.org/x/sync helper:

func (u UseCase) MintWithRetries(ctx context.Context, req Request) (MintResult, error) {
    ctx, cancel := context.WithTimeout(ctx, 30*time.Second)
    defer cancel()

    backoff := time.Second
    for {
        res, err := u.mintOnce(ctx, req)
        if err == nil && !res.Retryable {
            return res, nil
        }
        if err != nil && !isRetryable(err) {
            return MintResult{}, err
        }
        jitter := time.Duration(rand.Int63n(int64(backoff / 2)))
        select {
        case <-ctx.Done():
            return MintResult{}, ctx.Err()
        case <-time.After(backoff + jitter):
        }
        backoff = min(backoff*2, 8*time.Second)
    }
}

Three things worth pointing at. mintOnce carries the same idempotency_key through every attempt, so the second call rejoins the state machine from wherever the first one left off. The select { case <-ctx.Done() } block is the whole framework. A deadline from the HTTP handler cancels the timer, the timer fires and drives the next attempt, and nothing leaks once the client disconnects. And isRetryable is a small predicate on domain errors, not an exception class hierarchy.

Node projects installing p-retry to get this surface, Java projects composing Resilience4j with CompletableFuture.orTimeout, and Kotlin projects stitching coroutine withTimeout plus a flow operator all end up at the same shape. In Go the shape is the stdlib.

Problem 3: atomicity across the database and the broker

The idempotency pattern prevents a double-broadcast when the caller retries. It does not prevent a lost event when the process dies between two writes. The use case needs to save a domain row in Postgres and emit an event that the chain dispatcher will consume. Two systems, one logical write, and the process can die between them. Chris Richardson's Transactional Outbox pattern is the proportional answer: write the domain row and the outbound event in the same Postgres transaction, then let a separate loop publish the event asynchronously. Postgres is the source of truth. The broker is always downstream of commit, never ahead of it.

The call site is one transaction boundary:

func (u UseCase) Credit(ctx context.Context, input CreditInput) error {
    return u.tx.WithTransaction(ctx, func(ctx context.Context) error {
        if err := u.cashback.Save(ctx, input.ToCashback()); err != nil {
            return fmt.Errorf("save cashback: %w", err)
        }
        event := outbox.NewMintRequested(input.ID, input.Wallet, input.Amount)
        return u.outbox.CreateWithTx(ctx, event)
    })
}

WithTransaction opens one Postgres transaction and threads it through the context. Save and CreateWithTx both land in that same transaction, and commit or rollback is a single decision. The outbox_events row carries the event downstream; a relay loop picks it up out-of-band.

The transaction propagation itself is short:

func (m Manager) WithTransaction(ctx context.Context, fn func(context.Context) error) error {
    return m.db.WithContext(ctx).Transaction(func(tx *gorm.DB) error {
        return fn(WithTx(ctx, tx))
    })
}

The transaction rides on context.Context, not as a threaded *gorm.DB argument. Use cases stay GORM-unaware. Repositories read the current transaction with DB(ctx) and get either the pending transaction or the pool. One code path covers both, and tests wire the same repositories against a real database without mock objects or flag switches. The pattern follows Robert Laszczak's Database transactions in Go with layered architecture on threedots.tech. It is the clearest write-up of why propagating the transaction through the context pays for itself once an application has more than three repositories.

The contract abstraction extends to the ERC-20 token itself. The use case defines a TokenContract interface alongside EthereumClient:

type TokenContract interface {
    Mint(opts *bind.TransactOpts, to common.Address, amount *big.Int) (*types.Transaction, error)
    BalanceOf(opts *bind.CallOpts, account common.Address) (*big.Int, error)
}

The concrete implementation is a generated ABI binding from abigen. Tests swap it for a struct that returns a deterministic transaction hash. The use case never sees the binding, never touches the ABI, and never knows whether the test runs against Anvil or a mock.

The published flow looks like this:

The window Outbox closes is clearer when drawn without it:

That failure mode is not theoretical. Any dual write across a database and a broker without a coordinating pattern leaves the window open. The options for closing it all have tradeoffs:

Pattern	Atomic DB + broker	Latency	Infra	Fit
Single DB transaction only	Yes (DB only)	Lowest	None	Breaks once the broker is involved
Transactional Outbox	Yes	+1 relay tick	Postgres + poller	DB is source of truth, chosen here
Two-phase commit (XA, eXtended Architecture)	Yes	High, blocking	XA-capable broker	Rarely available, high operational cost
Saga with compensations	Eventual	Variable	Per-step logic	Complements Outbox for multi-service flows
Change Data Capture	Yes	+replication lag	Debezium + Kafka	Heavy infrastructure for a small team

Outbox trades one relay tick of latency for full atomicity with existing infrastructure. Two-phase commit needs an XA-capable broker that rarely exists outside legacy enterprise stacks. Saga complements Outbox when a downstream step needs compensation; the service uses MarkFailed as the compensating action when retries exhaust. CDC (Change Data Capture) is the bigger-team answer for shops that already run Debezium. For a team with Postgres and any broker, Outbox is the proportional choice.

Two concrete failure modes sit on either side of this choice. Without Outbox, the database commits, the publish call fails, the user is under-credited, and somebody reconciles by hand. With Outbox, the relay can crash after publishing but before marking the row published, which causes a duplicate publish on restart. The consumer absorbs it with a UNIQUE (idempotency_key) constraint, which ties straight back to the idempotency pattern in Problem 2.

Hook to part 2

The three consistency problems are now covered. Nonce sequencing handles ordering before the broadcast. Idempotent state machines handle resulting after the broadcast. Transactional Outbox closes the gap between the database commit and the chain dispatcher. Part 2 picks up where the database hands off to the live service. It covers signing a transaction with the standard library and no C bindings, for { select } event loops that do not lose work across restarts, and replay protection at the consumer end when the chain delivers the same log twice.

References

go-ethereum: official Go implementation of the Ethereum protocol. Source of EthereumClient, types.Transaction, and signer types used in code snippets.
golang.org/x/sync: errgroup and semaphore packages referenced in the bounded-workers pattern.
Chris Richardson, Pattern: Transactional Outbox: foundational reference for Problem 3.
Robert Laszczak, Database transactions in Go with layered architecture: practical Go implementation of the transaction-through-context pattern.
Martin Kleppmann, How to do distributed locking: the original argument that motivates fencing tokens over distributed locks alone.
Distributed locks and fencing tokens: the standalone piece on the theory this article applies.
fascari/cashback-platform: Go blockchain adapter service used as the running example throughout this series.

This is part 1 of a two-part series on building crypto payments backends in Go. Part 2 covers signing with the standard library and event loops that do not lose work across restarts.