The patch associated with this ticket will use the IsMonolithEnabled() function to properly set script flags to enable all the new opcodes. We'll need several RPC tests for this diff. They are as follows:

First, an RPC test that creates a block with the new opcodes in script. It should have:

1. Create a block with transactions containing the new opcodes that are valid under new consensus rules.
2. The activation set at some block
3. Mine empty blocks up to that block, but no further, submit the block to activate Monolith. It should *FAIL* to be accepted.
4. Mine a few more empty blocks to actually activate Monolith.
5. Adjust the previously invalid block so that it would be connected to the new chain tip.
6. Submit the block, it should *SUCCEED* at being accepted as the new chain tip.

There should be a similar test for the mempool. These tests can be interleaved with the above test to ensure that transactions are being accepted into the node's mempool appropriately as well.

FINALLY, there should be a test that:

1. Mines some blocks.
2. Mines a few more blocks with MTPs to activate Monolith.
3. Submit some transactions to the mempool with the new opcodes that are valid.
4. Mine blocks with enough work to cause a reorg, but the MTPs should be such that Monolith would now be considered INACTIVE.
5. Finally, assert that the mempool has been cleared in this situation.

In conclusion, this should have 3 RPC tests:

1. Check that txs within blocks are not accepted until the hardfork has been activated (and not within the block which would cause it to be activated)
2. Check that transactions are accepted appropriately in the mempool only after Monolith has been activated.
3. Check that a reorg shortly after activation clears the mempool of txns with new opcodes. This ensures invalid blocks will not be mined on top.