Skip to main content

Fee Field Update: Non-Charged Currency Now Reports 0

Affects: /broadcasttransaction and order-resource responses.

On any response where the charge completed (code / charge_result is CHARGED), the fee field for the currency you did not pay with (tx_fee_rtrx_account / tx_fee_rusdt_account / tx_fee_rtrx_instant / tx_fee_rusdt_instant, and the order-resource fee_rtrx / fee_rusdt equivalents) now reports 0.

Previously, both currencies carried real, non-zero values on a CHARGED response — even though only one was actually charged. Now only the currency actually charged carries a non-zero value; the other reports 0. You can still tell which currency was charged the same way as before: it's the field that's non-zero.

No client action is required. The field was, and remains, a Number — its type never changed, so any client parsing it as a number continues to work unmodified. Only the value for the non-charged currency changed.

Not affected:

  • FREE responses — both currencies are still returned as before.
  • The estimate endpoints (/wallet/triggersmartcontract, /api/v1/resources/estimate) — both currencies are still returned as before.

See Transatron Extension Objects and POST broadcasttransaction for the full field reference.

Charge Token Relabeling: USDT to RUSDT on Historical Orders​

Affects: GET /api/v1/orders — the charge_token field.

A migration relabels the underlying user_charge_type database column from USDT to RUSDT. charge_token is served verbatim from that column with no mapping layer, so an order that used to report "charge_token": "USDT" now reports "charge_token": "RUSDT" — the migration rewrites the stored value in place, it does not add a translation step.

GET Orders limits queries to a 90-day search window, so this is only observable for affected orders that still fall inside that window. Only a small number do: 4 orders, the newest dated 2026-08-06.

This is not a data error — RUSDT is the internal token name and USDT was a naming defect in the older rows. Same value, corrected vocabulary. The migration is one-way; there is no revert path, so integrators that key off charge_token on historical orders should treat RUSDT as the current and permanent label.