Matt Solomon

I looked into hardhat's caching approach a little while back (see https://github.com/foundry-rs/foundry/pull/698#issuecomment-1033111981). The answer is yes, they store call/response pairs: - `cache/hardhat-network-fork/network-{chainId}/` is the path containing cached responses for a...

Ah yes good point, did not mean to imply we should use hardhat's approach of a chain-specific reorg threshold—I agree the blockhash approach is better and forgot to mention it

I would probably create a general ownership transfer template where the inputs are a the chain, contract name, and the new owner address, where the new owner address is a...

> `OWNER_SAFE`: This can be inferred by retrieving the proxy admin owner (upgrade-controller) of an L2 chain from the array. All upgrade-controllers should be the same. We already have checks...

> It would be much cleaner (and more logical, since `Account` should not be connected to `StdCheats`) to be able to do this instead: Hmm, I agree it's cleaner because...

Going to close this one as stale and to avoid breaking changes

I think this needs to be spec'd out before a PR is opened :) First it's worth noting this concept can apply to all `expect*` cheats, not just `expectRevert`, so...

Another idea is a cheat to enable disable `expect*` checks for staticcalls, because really the use case here most of the time is going to be skipping staticcalls (h/t @brockelmore)

> it's a pass. That is because when reverter address is specified `vm.expectRevert(address(countRevert));` we're not looking for the next call to revert but rather for the next reverted call to...

Does that mean the next top level to `reverterAddress` (i.e. call from the test contract), or a call at any depth? See comments below for example: ```solidity function test_count_with_revert() public...