TempleGold

[L-01] - Arbitrum hard forks would force a redeployment

When dealing with the TempleGold (TGLD) contract we enforce that the minting of TGLD can happen only on Arbitrum via a chain id check. However the variable in that check is hardcoded in the constructor with no setter functionality. In case the Arbitrum chain faces a hardfork and the chain id changes, the contract will be rendered useless and will force a redeployment, essentially creating a new ERC20 which leads to it's own set of impacts

[L-02] - migrated tokens could get stuck in the migrator address

Inside TempleGoldStaking.sol the migrateWithdraw function is meant to be called individually on each user and transfer their current stake to the new staking contract, claiming their rewards for them. It utilizs the withdrawFor functionality to send all staked funds to the new migrator directly, without passing on information on who the staker is and the index of the stake. This means that the new migrator would receive raw ERC20 transferred funds without accounting them towards their respective staker. The staker will lose his stake even if he wished to continue holding in the new contract for maximum rewards. E.g:

Bob stakes in contract1. A migration happens and withdrawFor is called for Bob and his funds are sent to contract2. contract2 does not have info on who Bob is and if those funds are his, it just receives some ERC20 tokens via the transfer. Bob cannot withdraw his stake or continue earning rewards on the new migrator.

[L-03] - using create instead of create2 inside factory

As the deployment is meant to be across different EVM chains, some of which are more prone to block reorganisation, it is safer to user the create2 opcode when deployin spice auctions. The calculated pair id/hash can be used as the salt value, encoded with the msg.sender to prevent front-running.

Impacted area more specifically: SpiceAuction spiceAuction = new SpiceAuction(templeGold, spiceToken, daoExecutor, name)