Go backend engineering at Trust Wallet: multi-chain integrations

The problem: different chains, different upstream behavior

In blockatlas PR #698, newer Blockbook instances had changed the response fields consumed by the Bitcoin integration. I added support for both response versions. The code accepted transaction lists under either transactions or txs, selected valueOut when value was absent, and read output addresses from either a direct field or scriptPubKey. These were concrete compatibility differences in an upstream service that the wallet backend needed to normalize.

Normalization helpers kept the representation used by the adapter consistent while handling variation in the upstream data. The trade-off was additional parsing logic to maintain: compatibility now included more than one field layout. Requiring every upstream instance to use a single response format would simplify the adapter, but would remove the compatibility this change was designed to preserve. That distinction matters when a backend integrates systems with separate upgrade schedules.

Reusable RPC batching

PR #891 added a batch method to the shared JSON-RPC client. It submitted a collection of requests through one HTTP POST and decoded a collection of responses. The change also added tests for the default JSON-RPC version and request identifiers. JSON-RPC is the request format used by these node calls; batching packages several operations into a single request envelope.

PR #892 then used that method in the Zilliqa adapter. Previously, transaction retrieval launched a goroutine for each transaction hash and collected results through a channel and a wait group. The replacement built GetTransaction requests from the block's hashes, submitted them together, and converted decoded responses into the adapter's transaction type. An empty block returned without making the batch call.

The batching trade-off

The Zilliqa change moved transaction retrieval from separate concurrent calls to a batch request, removing the adapter's goroutine and channel coordination for that operation. This exchanged local concurrency management for a dependency on batch support at the node endpoint. The implementation did not introduce batch-size limits or a comprehensive per-item retry policy; it skipped responses that could not be decoded. Fewer request envelopes also do not establish a latency or throughput improvement without measuring endpoint behavior and the response workload.

HTTP visibility

PR #372 added HTTP instrumentation and a metrics route. Its code defined outbound request counters and duration histograms, added server middleware, and connected a Prometheus handler to the API. Prometheus is the metrics collection system targeted by this implementation. The route also included optional bearer-token checking when a token was configured. The PR description identified missing visibility into incoming and outgoing requests as the problem.

The counters and duration histograms made request volume and timing available to a metrics collector. This complemented the adapter work: normalization and request execution handle data movement, while instrumentation provides observations about the HTTP path. Exposing these measurements supplies the foundation for monitoring; the PR itself does not describe an alerting policy or quantify operational improvements.

Contribution scope

These four merged contributions connect three recurring Go backend concerns: compatible data models, external I/O and observability. Their common thread is the integration boundary, where differences between external systems must become data and operations the application can use. The linked PRs document these particular changes, including their implementation choices and limits.