Initially, an int64_t value representing satoshis is retrieved from the BaseTransactionSignatureChecker.GetTransactionData() function. This value is then converted into a minimally encoded CScriptNum, a process that doesn't necessarily require a separate opcode but can be executed within the OP_INOUT_AMOUNT implementation itself.

A significant adjustment is made by modifying the nMaxNumSize parameter in the CScriptNum constructor to accommodate 8 bytes instead of the previous limit, allowing for the handling of larger numeric values pertinent to Bitcoin transactions (modification reference). Following this adjustment, the CScriptNum is pushed onto the stack for subsequent use.

However, challenges arise when other opcodes consume the satoshi value at the stack's top, necessitating a mechanism to support an nMaxNumSize of 8 bytes. This requirement stems from the historical limitation where numeric opcodes interpreted CScriptNum with a nMaxNumSize of only 4 bytes, leading to potential overflow exceptions. An example of such an overflow exception can be found in the codebase (overflow exception reference). The issue extends to any opcode that utilizes CScriptNum to interpret stack top values, including OP_WITHIN, indicating a broader impact on script processing and necessitating careful consideration in the implementation of OP_INOUT_AMOUNT to avoid these pitfalls.