Wallet Auth Now Reads Tron, Stellar, Sui, and XDC
--
Stablecoin settlement runs through Tron. Tokenized money market funds issue on Stellar. Object-native value lives on Sui. Trade finance is collateralizing on XDC. Four chains. Four different storage models. Four different reasons to be there. Wallet auth reads all of them now.
The chain count moved from 33 to 37 this week. That is not the headline. The headline is what the new four represent: four economic environments that look nothing like each other underneath, all answering to the same signed boolean on the way out.
InsumerAPI’s primitive is wallet auth. Read on-chain state, evaluate against caller-supplied conditions, return an ECDSA-signed attestation. Conditions in. Signed attestations out. The contract surface for a relying agent or service is one POST to /v1/attest and one signature to check against the public JWKS. What changes when a new chain ships is not that surface. It is the set of things the surface can answer about.
Tron: where USDT actually moves
USDT on Tron is the largest stablecoin venue on chain by transfer volume. The supply of USDT-TRC20 has, at various points across 2025 and into 2026, exceeded the supply of USDT on every other chain combined. Remittance corridors in Southeast Asia, Latin America, and parts of Africa default to it. Centralized exchanges treat it as the canonical deposit rail.
If an agent’s job is to evaluate whether a counterparty wallet can settle in dollars, ignoring Tron means ignoring the largest dollar venue on chain. The new tronWallet parameter on POST /v1/attest and POST /v1/trust closes that gap. Pass a T-prefixed base58 address, set chainId to "tron", and the attestation returns the same shape as every other chain. Native TRX uses contractAddress: "native". TRC-20 tokens use a T-prefixed contract address. USDT-TRC20 lives at TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, six decimals.
Stellar: where tokenized US Treasuries issue
Stellar hosts BENJI, Franklin Templeton’s tokenized US Government Money Market Fund (the on-chain wrapper of FOBXX). BENJI is one of the largest tokenized money market funds in circulation. Holders receive the underlying fund’s yield. Redemption is in-fund. The token tracks the share price. BENJI on Stellar is a classic trustline asset, not a smart-contract balance.
Stellar also hosts Circle’s classic-trustline USDC, distinct from any Soroban contract version. Wallet auth reads the classic trustline state, because that is the issuer-anchored deposit ledger that BENJI and USDC actually live on. Pass a G-prefixed StrKey wallet, set chainId to "stellar", and add an assetCode field for trustline tokens ("USDC", "BENJI"). The signed attestation comes back with ledgerIndex and ledgerHash alongside the boolean. Soroban contract balances are out of scope for this release.
The USDC issuer on Stellar is GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN. The BENJI issuer is GBJW74JRHIIIYC3X3J5VKLR2CR4UJHKO76V5J5SAYTUFAUE7PJBKCT5R. Pass either as the contractAddress, pair with the matching assetCode, and the trustline state is the read.
Sui: object-native USDC
Sui runs on the Move language, and Move does not think about balances the way EVM does. There is no contract holding a mapping from address to amount. There are objects, owned by addresses, with types. USDC on Sui is a Coin<USDC> object type. Reading how much USDC a wallet holds means summing the wallet's owned objects of that type.
Circle deployed native USDC on Sui in 2024, and the deployment has expanded supply through 2025 and into 2026, with growing integration on Cetus, Navi, and Sui’s institutional rails. The contractAddress for a Sui token is the fully-qualified Move type string. For USDC on Sui, that is 0xdba34672e30cb065b1f93e3ab55318768fd6fef66c15942c9f7cb846e2f900e7::usdc::USDC. Pass a 64-hex-character suiWallet, set chainId to "sui", and the attestation comes back with checkpointSequence and checkpointDigest binding the read to a specific Sui consensus checkpoint.
XDC: enterprise EVM where trade finance settles
XDC ( chainId: 50) is the EVM chain banks actually point at. It is the only EVM ledger with native ISO 20022 message-format compatibility, which is the standard banks already use for cross-border wire and clearing instructions. That alignment is why the TradeFinex consortium runs there and why a growing pile of tokenized trade-finance assets, factoring receivables, and institutional RWAs issue on XDC rather than on consumer-DeFi EVM venues. The economic identity is different from a Base or an Arbitrum: it is the venue where regulated cash-flow instruments tokenize.
Because XDC accepts standard EVM tooling, every condition type works without any chain-specific wrapper. Add chainId: 50 to a condition that already worked on another EVM chain and it evaluates the same way. No new wallet parameter. No new address shape. The same wallet field handles it. Merkle proofs (EIP-1186 storage proofs) are available for token_balance conditions on XDC, the same as on the other EVM chains whose RPC supports eth_getProof.
The trust profile got a new dimension
POST /v1/trust returns a multi-dimensional fact profile. The previous shape had four base dimensions: stablecoins (USDC and USDT across 21 EVM chains), governance, NFTs, and staking. Optional solanaWallet, xrplWallet, and bitcoinWallet would tack on Solana, XRPL, and Bitcoin dimensions when those wallets were supplied.
This release adds a fifth base dimension that runs on every call: institutional_stablecoins. Eight checks spanning EVM, Solana, XRPL, Stellar, and Sui. The inventory covers Société Générale-FORGE's EURCV on Ethereum, Solana, and XRPL; FORGE's USDCV on Ethereum and Solana; Circle's classic-trustline USDC on Stellar; Franklin Templeton's BENJI on Stellar; and Circle's native USDC on Sui. The five EVM/Solana/XRPL checks resolve from the standard wallet fields. The three Stellar and Sui checks activate when stellarWallet and suiWallet are passed.
Optional tronWallet adds a separate tron dimension covering USDT-TRC20. Up to 49 checks across 27 chains in a single signed profile. No score. No opinion. Just verifiable evidence organized by dimension.
What did not change
The /v1/attest envelope is byte-identical for existing callers. The signature scheme is unchanged: ECDSA P-256, kid: "insumer-attest-v1", JWKS at /v1/jwks. The JWT format (set format: "jwt" on the request body) returns an ES256 token verifiable by any standard JWT library. Existing integrations on EVM, Solana, XRPL, and Bitcoin keep working with zero code changes. The four new wallet fields and the new chainId enum values are additive optionals.
That non-event is the point. Wallet auth as a primitive is meant to abstract chain differences. If adding four chains had broken the envelope, the primitive would have failed its job.
Available today
All four chains are live in production at api.insumermodel.com. The SDK family shipped the same day: [email protected] (npm), [email protected] (npm), @insumermodel/[email protected] (npm), [email protected] (PyPI), and [email protected] (PyPI). The OpenAPI spec, ChatGPT Custom GPT action schema, and llms.txt agent-discovery files all reflect the 37-chain surface.
The free tier at insumermodel.com/developers grants 10 verification credits, which is enough to run a multi-chain trust profile call against a wallet that touches Tron, Stellar, Sui, and EVM, then inspect the institutional_stablecoins dimension end to end. Add tronWallet, stellarWallet, and suiWallet to the same request body and the response composes everything in one signed envelope.
The full chain list and per-chain condition shapes live in the API reference and the trust profile docs.
Try it now
InsumerAPI is free to start. Get an API key with 10 verification credits and test the new chains in a single signed call.
Originally published at https://insumermodel.com.
