Summary

Variable that holds the block.chainid is immutable - therefore it can not be changed. This could lead to vulnerabilities in case the built-in block.chainid changes due to a hard fork.

Vulnerability Details

Due to the nature of the blockchain logic, it can go through a hard fork when going through an update. In such cases - the built-in variable block.chainid can change to a new value.
This will break the TempleGold contract since it has an immutable _mintChainId variable to determine if its being used on Arbitrum. Once the chain goes through a hipothetical hard fork - the contract is left useless since this modifier will not go through:

It will revert with WrongChain().

In order for this to happen - Arbitrum has to go through a hard fork that changes its chain id. Even though its unlikely - it has the potential to completely break the protocol.

Inspiration for submission found here:
https://zokyo-auditing-tutorials.gitbook.io/zokyo-tutorials/tutorials/tutorial-4-block.chainid-domain_separator-and-eip-2612-permit/understanding-block.chainid-and-domain_separator

Impact

Impact is sufficient to break entire protocol functionality since minting is not possible on the main chain - in case it changes its block.chainid after hard fork.

Tools Used

Manual review

Recommendations

Store _mintChainId in a mutable variable so it can be updated if a fork happens and the in-built block.chainid variable changes.

Add following function:

function updateChainId(uint256 updatedChainId) external onlyOwner {
_mintChainId = updatedChainId;
}

Alternatively, implement a mechanism for pausing mints and distributions of tokens in order to setup a new contract on the forked chain.