OUSD on Tempo
Open Standard lists native OUSD on Tempo. Use the contract below with Tempo Mainnet, chain ID 4217. Tempo has no native gas token: transaction fees use supported USD-denominated TIP-20 tokens. Open Standard: Build with Open USD ↗ Tempo: Network details ↗ Tempo: Fees ↗
Reviewed 2026-10-12. Token identity is source-backed; no OUSD transfer or provider integration independently tested.
Official OUSD contract
0x20c0000000000000000000006a37DA5C996874BEView OUSD on Tempo explorer ↗ · Official address listing ↗
This token address identifies OUSD on Tempo. It is not a customer receiving address. Do not send funds directly to it.
Connecting to Tempo or Moderato
Tempo Mainnet uses chain ID 4217, HTTP RPC https://rpc.tempo.xyz, and WebSocket RPC wss://rpc.tempo.xyz. The wallet currency symbol is USD, but it does not represent a native token balance. Tempo: Network details ↗
Moderato is the development testnet: chain ID 42431, HTTP RPC https://rpc.moderato.tempo.xyz, and WebSocket RPC wss://rpc.moderato.tempo.xyz. Mainnet and testnet funds, assets, and transaction histories are separate. Tempo: Network details ↗
Reading OUSD with a network check
The downloadable Node.js example first requires chain ID 4217, then queries the exact OUSD contract above. It pins eth_getCode, decimals() and balanceOf(address) to the same block number and prints the raw integer plus an exact decimal-string balance. eth_getBalance reads a native-currency balance, not OUSD. Open Standard: Build with Open USD ↗ Ethereum: JSON-RPC API ↗ Download: read-only EVM balance example ↗ Tempo: TIP-20 specification ↗ Tempo: Network details ↗
The example makes JSON-RPC reads only; it requests no wallet connection, signature or transaction. The queried owner address is sent to the selected RPC endpoint. The command below uses the zero address only as a syntax illustration; replace it with the public address you intend to inspect. Download: read-only EVM balance example ↗
Tempo’s TIP-20 specification fixes decimals at six and supplies the balanceOf interface. TIP-20 is implemented by native precompiles, so the example does not require ordinary ERC-20 bytecode on Tempo. It still validates the actual read responses. Open Standard: Build with Open USD ↗ Ethereum: JSON-RPC API ↗ Download: read-only EVM balance example ↗ Tempo: TIP-20 specification ↗ Tempo: Network details ↗
Validation limit: the script passed syntax and mocked-response checks, including wrong-network and malformed-response failures. Live RPC requests from this review environment were blocked, so no live EVM balance result is claimed. Output should include network, chainId, block, token, owner, codeBytes, decimals, rawBalance and balance. A latest-block read is not a settlement or spendability guarantee. Download: read-only EVM balance example ↗
Run the read-only balance example
Save the linked download as read-ousd-evm.mjs and use Node.js 18 or later. Use a trusted RPC endpoint; do not paste an RPC credential into source code or shared logs.
node read-ousd-evm.mjs tempo 0x0000000000000000000000000000000000000000Selecting and estimating the fee token
The fee token can differ from the payment token. If conversion to a validator’s preferred token is required, the Fee AMM needs enough liquidity. The sender can pay fees, or a separately authorized fee payer can sponsor them. Tempo: Fees ↗
Estimate the actual call with its sender and fee configuration. Transfers to a new token holder can require more gas than transfers to an existing holder. Gas prices, usage, and network state can change before inclusion; use the receipt and fee-token transfer to reconcile the amount charged. Tempo: Fees ↗
Using SDKs and checking delivery
Tempo publishes SDK references for TypeScript with Viem or Wagmi, Go, Python, Foundry, and Rust. Query TIP-20 balances for actual funds instead of interpreting an Ethereum-style native-balance response as spendable money. Tempo: SDKs and developer tools ↗ Tempo: EVM differences ↗
A successful TIP-20 call does not always mean the intended receiver was credited. If an account-level receive policy blocks delivery, funds go to ReceivePolicyGuard and a recovery receipt is recorded. Token-level policy failures instead revert. Check delivery effects when reconciling payments. Tempo: Receive policies ↗
OUSD fee eligibility and access limits
The native OUSD listing does not establish current OUSD fee-conversion liquidity or a provider-supported OUSD route. Verify fee-token eligibility and the available conversion liquidity for the intended transaction; no OUSD fee-payment transaction was tested for this reference. Open Standard: Build with Open USD ↗ Tempo: Fees ↗
Use the listed contract to identify OUSD, not as a personal receiving address. Mainnet setup and generic testnet instructions are separate from evidence of a successful OUSD transfer. This reference has not tested OUSD transfers or provider integrations on Tempo. Open Standard: Build with Open USD ↗ Tempo: Network details ↗
Provider routes involving Tempo
These records name Tempo in an OUSD-specific documented operation. Read the direction, delivered asset and eligibility limits; this is not a claim that every provider operation supports the network.
- Privy: Custodial OUSD wallets and transfers — Privy publishes an OUSD-on-Tempo transfer example. Its custodial-wallet chain list also includes Base and Solana, but that list alone does not establish each OUSD route; confirm those combinations with Bridge.
- Bridge: OUSD custodial wallets — The custodial-wallet asset table explicitly lists OUSD on these four networks.
- Bridge: OUSD transfers and conversion — OUSD destinations are documented on all four networks. OUSD source sections are documented for Base, Ethereum, Solana and Bridge Wallet; a Tempo source route is not established by the reviewed table.