tldr: want to run simulated transactions against deployed bytecode on rinkeby that has no verified solidity source, and step through opcodes and view stack/memory leading up to revert.

To clairfy: in Remix, you can run a transaction on your local javascript VM with contracts you wrote (and thus have the source for), and then click DEBUG and get a nice interface that lets you step through opcodes, view the stack and memory as the transaction progresses, etc.

I am interacting with a contract for which no source is published, but if I could have the same interface just for stepping through the opcode execution itself with a tool showing me the state of the stack, that would be enough for me to debug the issue I'm working on.

Executing through Remix doesn't seem to yield the debug function I want for a failed transaction on rinkeby for a contract I don't have the source for. Tenderly likewise will only show a friendly function trace, but no opcode trace for contracts lacking a source.

Is such a tool available? Am I missing a feature somewhere?

  • 1
    In the remix debugger you can enter a transaction hash and start debugging without source code. You might need an archive node if the transaction is old.
    – Ismael
    Commented Mar 9, 2022 at 5:56
  • @Ismael does 2-3 days count as old? Anyways, tried making a new transaction to test, that also didn't work. Looked up github, found issues open on this topic. I added to one: github.com/ethereum/remix-project/issues/1841 || anyways, though, good to know that a tool at least exists that should do this, even if it seems to perhaps be broken at the moment.
    – Kyle Baker
    Commented Mar 10, 2022 at 12:34
  • The "old" depends on the web3 provider. Usually for free providers like infura "old" is quite recent.
    – Ismael
    Commented Mar 15, 2022 at 15:36

1 Answer 1



  • Remix can do this, and so far is the only tool that I'm aware of that does this (short of running geth yourself and logging output manually or something).
  • Remix has major limitations, though. It can do this sometimes, but:
    • if the transaction is too complex/has too many opcodes, it'll crash
    • it also seems to just fail sometimes for unknown reasons on transactions that seems like they should work, too; it seems like rinkeby transactions are also more likely to fail than mainnet, but this isn't confirmed.
    • there are open issues related to this on github, follow those for updates, this answer is a 'right now' answer, and is subject to change.

To use this feature:

  1. copy the transaction hash
  2. click the bug icon on the left (if you don't have it, you'll need to add it in your extensions.)
  3. paste the transaction hash and start debugging


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.