TransactionManager - Hard-coded chain ID might lead to problems after a chain split  Pending
The ID of the chain on which the contract is deployed is supplied as a constructor argument and stored as an `immutable` state variable:\\n```\\n/\\*\\*\\n \\* @dev The chain id of the contract, is passed in to avoid any evm issues\\n \\*/\\nuint256 public immutable chainId;\\n```\\n\\n```\\nconstructor(uint256 \\_chainId) {\\n  chainId = \\_chainId;\\n  interpreter = new FulfillInterpreter(address(this));\\n}\\n```\\n\\nHence, `chainId` can never change, and even after a chain split, both contracts would continue to use the same chain ID. That can have undesirable consequences. For example, a transaction that was prepared before the split could be fulfilled on both chains.
It would be better to query the chain ID directly from the chain via `block.chainId`. However, the development team informed us that they had encountered problems with this approach as some chains apparently are not implementing this correctly. They resorted to the method described above, a constructor-supplied, hard-coded value. For chains that do indeed not inform correctly about their chain ID, this is a reasonable solution. However, for the reasons outlined above, we still recommend querying the chain ID via `block.chainId` for chains that do support that — which should be the vast majority — and using the fallback mechanism only when necessary.
```\\n/\\*\\*\\n \\* @dev The chain id of the contract, is passed in to avoid any evm issues\\n \\*/\\nuint256 public immutable chainId;\\n```\\n