docs: about using foundry script with precompiles

[bguiz]

• context: convo copied below
• action: write this up as a page, add to the EVM developer docs

---

zsystm 08:20
Hey guys. I have questions for using Foundry with Injective's precompile contracts.
Is that Foundry 100% compatible when even interacting with INjective's custom precompile?
I think this is impossible because Foundry would never know Injective's custom precompile which is written with Cosmos SDK
I'd like to hear what you guys think about it. It cannot be 100% compatible.
For example, you cannot write Forge Script interacting with custom precompiles with Injective Node.
Cast works in this case because it just sends JSON-RPC to node and get a response from it.
But for Forge Script which triggers Foundry creates its own EVM could never be compatible with Injective.
Feel free to correct me if I'm wrong or missing something.
zsystm 08:30
Of course we can mock custom precompile contracts in Forge Script, but we cannot say it 100% compatible because it is just interacting with Mock, not a real custom precompile logics.
zsystm 09:05
I also checked your demo scripts and it just uses forge create and cast send. They are just basic JSON-RPC wrappers. Only with this, we cannot guarantee it is 100% compatible with Foundry.
bguiz 09:26
I'm not familiar with forge script - but I think this depends on what network these commands are interacting with.

• If it is Testnet, they will work.
• If is a localhost injective node, they should work (haven't tried, assuming)
• If it is a generic emulation EVM chain (like Ganache), then it won't work, because it won't have the precompile.
  your question seems to imply that it is the 3rd case - is that right?
  zsystm - 27/06/2025, 09:34
  Yeah third case. Foundry script always try to create its own emulation EVM, so Injective’s precompile can’t be compatible with that.
  I have heard that Injective is 100% compatible with foundry, so I want to validate that is true or not.
  For my own view, that is not true.
  One more thing to add: One of the reason why Foundry is a famous tool is that it creates bunch of helpful infos like detailed call flow, gas usage by using its emulated vm.
  Unfortunately we can’t use that for Injective’s precompile.
  So we cannot say that it is 100% compatible
  Maxim | Injective Labs - 28/06/2025, 02:02
  But for Forge Script which triggers Foundry creates its own EVM could never be compatible with Injective.
  @zsystm the EVM that Injective has and Foundry has are the same EVM, just with empty state. As you correctly mentioned the difference is that the Foundry lacks precompile implementaiton. But since the interface of a precompile is known, for tests it's very easy to mock it. There is a method vm.etch that allows to place any code on any address, and we use it to implement bank precompile mock here https://github.com/InjectiveLabs/solidity-contracts/pull/18/files#diff-832036f547a5caec749a29aea92225cd68f83887f027ff61926080cc3f426f8eR9-R10 since bank itself is a simple thing, it's identical in features. Contrary to mocking orderbook matching with exchange logic.. that'd be hard. We'll be working on providing some reasonable mocks for our precompiles. Not enough to test E2E flows out of the box, but enough to test the interface. E2E testing shouldn't be mixed together with unit testing anyways.
  Regarding foundry's features:
  Allowing running forge test on a node over rpc. foundry-rs/foundry#5024 this is reasonable
  Support injecting custom precompiles to anvil foundry-rs/foundry#7498 this is cool, maybe we could inject some exchange logic directly via precompiles on the Rust side. This is advanced wizardry and it's not on the roadmap yet.