[decofe]

Workspaces without an explicit default_token_address fell back to PathUSD on every chain. This makes OUSD (0x20c0000000000000000000006a37DA5C996874BE) the fallback default on Tempo mainnet and Moderato testnet. OUSD uses the same address on both chains, and the Moderato faucet (tempo_fundAddress) mints it.

• Add Tempo.addressLookup.ousd and Tempo.getDefaultTokenAddress(chainId): OUSD on mainnet and testnet, PathUSD on localnet.
• Replace the hardcoded ?? Tempo.addressLookup.pathUsd fallbacks in tips, raffles, asks, airdrops, account links and config views with getDefaultTokenAddress(chain_id).
• Allow OUSD on mainnet and testnet, add it to the workspace token picker and App Home balances, and resolve ousd / openusd aliases.

Workspaces with an explicit default_token_address, including the X workspace (USDC.e), keep that setting.

The address is hardcoded because the viem/tokens ousd definition ships in viem 2.56+, and those versions drop the viem/tempo/zones export that the pinned @wagmi/core 3.4.11 imports. Only @wagmi/core 3.6.5+ avoids that, which also requires accounts ~0.18. That upgrade is left for a separate PR.

Validation: CI Unit, Workers and E2E pass. Checked onchain that symbol() returns OUSD on Moderato, and that tempo_fundAddress mints 1,000,000 OUSD to a fresh address. Check / Verify fails on pnpm audit advisories (undici, brace-expansion, ip-address, fast-uri), which also fail on main.

Prompted by: @tmm

[socket-security]

No dependency changes detected. Learn more about Socket for GitHub.

👍 No dependency changes detected in pull request

[github-actions]

The latest Tipbot preview deployment for 13ce444

Name	Status	Preview	Updated (UTC)
pr95	Shut Down	pr95.tip.bot	Nov 4, 2026, 10:24 PM

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

[claude]

Still open from earlier reviews (1):

• Unresolved: 1 minor or pre-existing.

[claude]

The latest commits fix both of my earlier inline points. getTokenAddress now resolves 'usd' to the workspace's stored default_token_address and falls back to the chain default only when that is null, and both callers (chat.ts, twitter.ts) pass the stored value. I found no new bugs. I'd still suggest a human look, because this changes payment defaults for existing workspaces.

What was reviewed:

• The ?? pathUsd to getDefaultTokenAddress(chain_id) replacements in api.ts, chat.ts and tip.ts. Each one now uses the row's own chain_id.
• The isAllowedToken split. Localnet drops OUSD, which matches getDefaultTokenAddress returning pathUSD there.
• Migration 0026. It only touches one workspace, filtered by provider, provider_id and chain 4217.
• One open product question. Mainnet and testnet workspaces with a null default move from PathUSD to OUSD, so access keys already authorized for PathUSD no longer match the default token. Those users get a re-authorization or confirmation prompt instead of a direct tip.

Extended reasoning...

The change touches the tip, batch-tip, access-key and link flows in src/api.ts, src/lib/tip.ts and src/chat.ts, plus token resolution in src/lib/tempo.ts and a one-row data migration. These are payment paths. There's no injection or auth-check change, but the token used for spending and key scoping now differs for workspaces whose default is null. Both of my earlier findings about the 'usd' alias are addressed in the current code. I deferred instead of approving because silently moving existing workspaces' default token, and the effect that has on already-authorized PathUSD access keys, is a product decision a maintainer should confirm.