I was able to import OVM_ETH here instead, but could not access OVM_ETH.balanceOf.selector for whatever reason...

just noticed: this could be a staticcall

After talking this through with @maurelian this definitely needs to be fixed. We need to do some sort of enforcement of gasleft beforehand (perhaps line 1112 above becomes (success, returndata) = _contract.call{gas: min(_gasLimit, gasleft() - MIN_GAS_FOR_RETURN_VALUE_BACK) }(_data);

Otherwise, this code path here potentially allows a malicious contract to out-of-gas anyone who calls it with nonzero value, even if they only give the malicious contract a small portion of their own gas.

In addition to ^^^ I'm going to give my understanding of the problem we're facing here and the proposed solution because I found it quite difficult to wrap my head around. This is based on conversation with @ben-chain (please correct me if you see any mistakes).

What we're trying to achieve here is to duplicate the behavior of EVM calls that come with attached value. Specifically, this behavior is as follows:

1. If making a call with a value > 0 and the call fails, then the value IS NOT transferred to the recipient.
2. If making a call with a value > 0 and the call succeeds, then the value IS transferred to the recipient.
3. If making a call with a value > 0 and the user is unable to transfer funds (e.g., because they don't have enough balance OR because they don't have enough gas to execute the payment), then the value IS NOT transferred to the recipient AND the call fails with (success=false, returndata=0x). This IS how the EVM behaves. See geth: https://github.com/ethereum/go-ethereum/blob/2dee31930c9977af2a9fcb518fb9838aa609a7cf/core/vm/evm.go#L298

Case (2) is the straightforward happy path case.
Case (3) is also pretty easy to handle by checking for failure of the initial transfer.

Case (1) is slightly harder -- you want to revert the payment if the call fails. You can either do that by reverting the call frame in which the payment was transferred or by transferring the payment back to the original sender. Reverting the call frame here IS technically an option for cases where the transfer fails for some unexpected reason but we can avoid this because OVM_ETH is trusted. The only case we really need to be careful of is if we were to run out of gas when trying to transfer the ETH back. We could get around this by adding an extra call frame (expensive) or by making sure that the user always provides enough gas to execute both transfer steps when the value is greater than 0.

can also remove this 0

on second thought: gonna leave these. Slightly more efficient and minimizes usage of an effectively deprecated code path

As discussed with @ben-chain, we can either attach the call value to the message context or pass it as a parameter to _callContract. Attaching the call value to the message context is probably best because it effectively is a message-specific parameter and it must be accessible for the sake of msg.value.

In addition to ^^^ I'm going to give my understanding of the problem we're facing here and the proposed solution because I found it quite difficult to wrap my head around. This is based on conversation with @ben-chain (please correct me if you see any mistakes).

What we're trying to achieve here is to duplicate the behavior of EVM calls that come with attached value. Specifically, this behavior is as follows:

1. If making a call with a value > 0 and the call fails, then the value IS NOT transferred to the recipient.
2. If making a call with a value > 0 and the call succeeds, then the value IS transferred to the recipient.
3. If making a call with a value > 0 and the user is unable to transfer funds (e.g., because they don't have enough balance OR because they don't have enough gas to execute the payment), then the value IS NOT transferred to the recipient AND the call fails with (success=false, returndata=0x). This IS how the EVM behaves. See geth: https://github.com/ethereum/go-ethereum/blob/2dee31930c9977af2a9fcb518fb9838aa609a7cf/core/vm/evm.go#L298

Case (2) is the straightforward happy path case.
Case (3) is also pretty easy to handle by checking for failure of the initial transfer.

Case (1) is slightly harder -- you want to revert the payment if the call fails. You can either do that by reverting the call frame in which the payment was transferred or by transferring the payment back to the original sender. Reverting the call frame here IS technically an option for cases where the transfer fails for some unexpected reason but we can avoid this because OVM_ETH is trusted. The only case we really need to be careful of is if we were to run out of gas when trying to transfer the ETH back. We could get around this by adding an extra call frame (expensive) or by making sure that the user always provides enough gas to execute both transfer steps when the value is greater than 0.