t2000-sui-platform

Sui Address Balances + Gasless Stablecoin Transfers

Two Sui platform features that change how we architect any high-throughput payer (the Model B settlement float, the MPP gateway, future agent custody) and any gas-free user send (Audric Pay → creator payouts, send-to-email claim links). Read before assuming a single Sui address serializes, or before adding SUI-for-gas onboarding friction.

TL;DR — the two patterns

Pattern	What it gives you
Address Balances (SIP-58)	Fungible assets held as ONE accumulator balance at the address, not a scatter of Coin<T> objects. Concurrent debits are accumulator mutations → no owned-object lock → a single address is no longer single-threaded. Pairs with non-sequential nonces (many in-flight txs, keyed by digest not a serial counter). Gas can be paid from the balance (enable_address_balance_gas_payments).
Gasless stablecoin transfers	Move USDC without holding SUI — gas is sponsored or paid in-asset. Removes the onboarding wall and the SUI gas coin as a contention object on a busy payer.

Docs: docs.sui.io/onchain-finance/asset-custody/address-balances/using-address-balances · docs.sui.io/develop/transaction-payment/gasless-stablecoin-transfers

The myth these kill: "one Sui address can only do one tx at a time"

The classic owned-object model serializes a wallet on TWO objects:

1. The gas coin (every tx mutates it) → equivocation risk under concurrency.
2. The payload coin being spent (owned Coin<T>).

That's why the client-side consumer path ships enqueueWalletWrite (the equivocation queue) — correct for one human wallet doing occasional writes.

A high-throughput server payer must NOT inherit that constraint:

• Address Balances remove #2 (accumulator, not owned object).
• Address-balance gas payments / gasless transfers remove #1.
• Non-sequential nonces let many settlement txs be in flight at once.

→ A single settlement address scales. A wallet fleet is an OPTIONAL lever for blast-radius isolation or extreme headroom — never a scaling prerequisite.