Mint API: outboundTx.hash for the RGB leg is mojibake (raw bytes → U+FFFD) — fulfill txid unrecoverable from API and UI

[DmytroShalaiev]

Summary

For a FINISHED EVM→RGB transfer, GET /api/v0/transfers/{tx} returns outboundTx.hash
as a mangled string instead of a hex-encoded Bitcoin txid. The raw txid bytes appear to be
serialized as a UTF-8 string, so all non-ASCII bytes are replaced with U+FFFD (replacement
character) — the original txid is unrecoverable from the response. The web UI's "Fulfill tx"
copy button copies the same mangled value, so users cannot obtain their Bitcoin fulfill txid
from either the API or the UI.

Steps to reproduce

1. Complete an EVM→RGB transfer (mine: id 3652, created 2026-07-22, 1 USDT Ethereum → tUSDT RGB).
2. curl https://bridge.gateway.tricorn.network/api/v0/transfers/<creation-tx-hash-without-0x>
3. Inspect outboundTx.hash once status = FINISHED.

Expected

A hex string, consistent with triggeringTx.hash (e.g.
dd8119aec8e38677ef3376dd9f21b611edfbeb00ae36c5b02946eab17e5fd5a1 — the actual Bitcoin
anchor tx for my transfer, confirmed in block 959139; recovered via the receiving wallet,
not via the API).

Actual

outboundTx.hash contains U+FFFD-mangled bytes (JSON like "hash":"u\ufffd5\ufffd\u05de..."),
irrecoverable by design since invalid UTF-8 bytes are destroyed at serialization time.

Suggested fix

Hex-encode the txid bytes before serializing the response (and surface the same hex string in
the UI). A backfill for historical transfers would be nice but optional.

(Found while integrating against the Mint API; happy to provide more details.)