Moderato: deployment gas underestimates Tempo contract creation costs in Foundry

[okwme]

Summary

On Moderato testnet, Tempo TIP-20 native USD precompiles are callable from deployed contracts, but contract deployment from Foundry against the public RPC shows two surprising behaviors:

1. forge script calling TIP-20 precompiles inside the script VM hits OpcodeNotFound
2. large contract creates on-chain can consume the full gas cap and fail even when local Foundry deployment gas is much lower

What I verified

TIP-20 precompiles are not wallet-only:

• direct RPC cast call to pathUSD / AlphaUSD / BetaUSD / ThetaUSD works
• a deployed Solidity probe contract can call balanceOf(...) on all four
• a deployed Solidity probe contract can call approve(...) on pathUSD, and the allowance is stored on-chain

Example successful contract-originated approve:

• token: 0x20c0000000000000000000000000000000000000
• tx: 0x3458b929d74331dc1ffe99446cdd5c3505d93af017fb2f4355520844e130f9a7

Unexpected behavior

For PredictionMarket deployment on Moderato:

forge create src/PredictionMarket.sol:PredictionMarket \
  --broadcast \
  --gas-limit 20000000 \
  --rpc-url https://rpc.moderato.tempo.xyz \
  --private-key <funded-key>

Receipt:

• tx: 0x5f38ff9fc3c2d29436d098c74aa5b040159da19a5c31b99bfd801dcb838ed314
• status: 0
• gasUsed: 20000000
• feeToken: 0x20C0000000000000000000000000000000000000
• reported contractAddress: 0x6b821802e2cB86d3082EA47342b6d49D3618D62d
• cast code at that address returns 0x

Local Foundry gas report for the same contract says deployment cost is about 5,216,990 gas, so the live failure is unexpectedly far above local expectations.

Question

Is there any known Moderato behavior around:

• contract creation gas accounting when fees are paid in TIP-20 stables
• precompile behavior inside Foundry-style script/simulation paths
• limits or caveats for deploying larger contracts through the public RPC

If there is a recommended deployment method for large contracts on Moderato, that would help.

[okwme]

Update after deeper testing:

The core issue now looks like deployment gas underestimation against Tempo's documented metering, not TIP-20 precompiles being wallet-only or unavailable to contracts.

What we verified on Moderato:

• Deployed Solidity contracts can call Tempo native USD TIP-20s (pathUSD, AlphaUSD, BetaUSD, ThetaUSD).
• A deployed probe contract successfully executed balanceOf(...) on all four and approve(...) on pathUSD.
• So the earlier suspicion that these endpoints were external-only was incorrect.

What actually matched the observed deployment failures:

• TIP-1000 raises new state creation to 250,000 gas, adds 250,000 gas for account creation, and prices contract creation at code_size * 1,000 + 500,000, with account creation separate: https://docs.tempo.xyz/protocol/tips/tip-1000
• TIP-1010 says the 30M tx cap exists specifically to accommodate contract deployments under TIP-1000 state creation costs, and gives an expected max deployment cost around 25.85M-26.15M: https://docs.tempo.xyz/protocol/tips/tip-1010

Our live results on Moderato were consistent with that:

• PredictionMarket deployment succeeded at about 24,927,090 gas
• Vault succeeded at about 21,835,944 gas after moving constructor seeding out to a post-deploy admin call
• local Foundry estimates were much lower, which led us to under-gas the early deployment attempts

So the Tempo-side question is probably not “why can’t contracts call TIP-20 precompiles?” anymore.
It is closer to:

• are the docs/tooling recommendations for Foundry deployment on Moderato sufficient, given TIP-1000/TIP-1010 metering?
• should Tempo-specific Foundry guidance warn users that large deployments may need gas limits near the 30M cap even when local estimates are far lower?
• is there a known way for toolchains to query/reflect Tempo's contract-deploy gas model more accurately?

Separately, we also confirmed a Foundry bug where forge create can print success even when the receipt failed and no code was deployed. That part is filed upstream and is distinct from the Tempo metering issue.

[okwme]

Related Foundry-side issue: foundry-rs/foundry#13954 . That thread covers the separate tool bug where forge create can print success even when the deployment receipt failed and no code was deployed.

[mattsse]

working on integrating everything in here, but for now proper tempo support is baked into https://github.com/tempoxyz/tempo-foundry