Sponsored writes fail when funds are in address balance (Enoki: 'Invalid bcs bytes for TransactionData')

[funkiirabu]

Summary

Sponsored writes (save_deposit, repay_debt, send_transfer, swap_execute) fail at the Enoki execute step with:

gas_station_error: Request to gas station failed
{"error":"Invalid bcs bytes for TransactionData"}

…whenever the user's source funds live in their Sui address balance (the new gasless-stablecoin / Address Balances feature) rather than as coin objects.

Root cause

@mysten/sui@2.17.0's coinWithBalance resolver (transactions/intents/CoinWithBalance.mjs) sources from the address balance when addressBalance >= totalRequired, emitting 0x2::coin::redeem_funds + a FundsWithdrawal reservation input. That FundsWithdrawal is a new TransactionData field. Enoki's sponsor endpoint accepts the kind bytes (200), but its gas station can't deserialize the resulting TransactionData → Invalid bcs bytes.

Notably coinWithBalance takes the address-balance branch even when coin objects exist, as long as the address balance alone covers the amount.

Evidence

• devInspectTransactionBlock of the exact composed save_deposit kind bytes succeeds on mainnet → the PTB is valid on-chain; the fullnode parses FundsWithdrawal fine. Only Enoki's gas station rejects it.
• Repro with a wallet holding coin objects + $0 address balance → clean PTB (MergeCoins/SplitCoins), no FundsWithdrawal, would sponsor fine.
• Repro wallet with 100% address-balance USDC → PTB contains coin::redeem_funds + FundsWithdrawal → Enoki rejects.
• Enoki app config verified healthy (keys unchanged, gas pool funded, 47 prior sponsored txs OK) — not a config/credit issue.

Why this matters

Gasless stablecoin transfers (Audric Pay receives, bridges, Circle) deposit USDC into the recipient's address balance. As these spread, more wallets become address-balance-only, and every sponsored write against those funds silently breaks.

Options

• A. Enoki adds FundsWithdrawal TransactionData support — the real, permanent fix. On Mysten's side (escalation filed separately). Tracks the address-balance-only case.
• B. Self-funded fallback when the user holds SUI (sign + submit to fullnode directly, bypass Enoki). Stopgap; breaks gasless promise; most zkLogin users have no SUI.
• C. SDK coin-object-only sponsored path (this issue's deliverable). In sponsoredContext, source from coin objects only; if insufficient, throw a clear typed error (ADDRESS_BALANCE_UNSPONSORABLE) instead of the cryptic Enoki failure.

Fix C — planned scope

• Centralize in packages/sdk/src/wallet/coinSelection.ts (selectAndSplitCoin): when sponsoredContext, fetch coin objects via getCoins → merge → split; never call coinWithBalance.
• Throw ADDRESS_BALANCE_UNSPONSORABLE with actionable copy when coin objects don't cover the amount.
• Engine preflight/guard surfaces the message before the confirm card.
• Covers save_deposit / repay_debt / send_transfer (all via selectAndSplitCoin). Follow-ups: swap_execute (Cetus addSwapToTx uses coinWithBalance directly) + SUI path (selectSuiCoin).

Limitation: C does NOT unblock address-balance-only wallets (no coin objects to use). Those depend on A or B.

Refs

• https://docs.sui.io/develop/transaction-payment/gasless-stablecoin-transfers
• Issue sponsoring transaction MystenLabs/sui#22306 (same Invalid bcs bytes error class)

[funkiirabu]

Enoki escalation draft (forward to Enoki support)

Subject: Gas station fails to sponsor transactions that withdraw from Address Balances (Invalid bcs bytes for TransactionData)

Enoki app: Audric (mainnet) · Starter plan · gas pool funded, keys verified.

Symptom

POST to the Enoki gas station execute endpoint returns HTTP 400:

{"error":"Invalid bcs bytes for TransactionData"}

The sponsor step (kind bytes → sponsored TransactionData) returns 200; the failure is at execute when the assembled TransactionData is deserialized.

Root cause

The transaction sources coins from the sender's Address Balance (the Sui Address Balances / gasless-stablecoin feature). @mysten/sui's coinWithBalance resolver (v2.17.0) emits a 0x2::coin::redeem_funds call plus a FundsWithdrawal reservation input — a newer TransactionData shape. Enoki's gas station appears unable to deserialize TransactionData containing a FundsWithdrawal input.

Evidence it's a gas-station deserialization gap (not a malformed tx)

• devInspectTransactionBlock of the exact same transaction-kind bytes succeeds on the public mainnet fullnode — the fullnode parses FundsWithdrawal fine.
• The identical operation on a wallet whose funds are held as discrete coin objects (no FundsWithdrawal) sponsors + executes successfully.
• Only wallets with funds in Address Balance fail, and only through the gas station.

Minimal repro

import { Transaction, coinWithBalance } from '@mysten/sui/transactions';
// Sender holds USDC ONLY in address balance (e.g. received via 0x2::balance::send_funds)
const tx = new Transaction();
tx.setSender(SENDER);
const coin = coinWithBalance({
  type: '0xdba34672e30cb065b1f93e3ab55318768fd6fef66c15942c9f7cb846e2f900e7::usdc::USDC',
  balance: 1_000_000n, // 1 USDC
})(tx);
tx.transferObjects([coin], SENDER);
// Build kind bytes → Enoki sponsor (200) → Enoki execute → 400 "Invalid bcs bytes for TransactionData"

Ask

1. Does Enoki's gas station support sponsoring TransactionData that contains FundsWithdrawal inputs (Address Balance withdrawals)?
2. If not, what's the timeline? Address Balances are a first-class Sui mainnet primitive and gasless stablecoin receives deposit funds there, so any sponsored write against received funds currently fails.
3. Is there a recommended interim pattern other than forcing coin-object sourcing?

Impact (our side)

Address-balance-only wallets cannot perform any sponsored write (save / swap / borrow-repay / SUI send) until this is supported. We've shipped an SDK mitigation that sources from coin objects under sponsorship (covers mixed wallets) and surfaces a clear error otherwise — but address-balance-only wallets depend on this gas-station fix.

— Tracked in t2000#93.

[funkiirabu]

Upstream escalation filed: MystenLabs/sui#26852 (public, scrubbed repro). Correction to the draft above: #22306 is related ("transaction kind bytes are invalid" at the sponsor step) but NOT the same error — ours is "Invalid bcs bytes for TransactionData" at execute. Same family, different step/string.