The upgradeability of MinerRegistry, AgentPolice, and Agent is overcomplicated and has a hight chance of errors.  Acknowledged
During the engagement, we have identified a few places that signify that the `Agent`, `MinerRegistry` and `AgentPolice` can be upgraded, for example:\\nAbility to migrate the miner from one version of the Agent to another inside the `migrateMiner`.\\nAbility to `refreshRoutes` that would update the `AgentPolice` and `MinerRegistry` addresses for a given Agent.\\nAbility to `decommission` pool. We believe that this functionality is present it is not very well thought through. For example, both `MinerRegistry` and `AgentPolice` are not upgradable but have mappings inside of them.\\n```\\nmapping(uint256 => bool) public liquidated;\\n\\n/// @notice `\\_poolIDs` maps agentID to the pools they have actively borrowed from\\nmapping(uint256 => uint256[]) private \\_poolIDs;\\n\\n/// @notice `\\_credentialUseBlock` maps signature bytes to when a credential was used\\nmapping(bytes32 => uint256) private \\_credentialUseBlock;\\n\\n/// @notice `\\_agentBeneficiaries` maps an Agent ID to its Beneficiary struct\\nmapping(uint256 => AgentBeneficiary) private \\_agentBeneficiaries;\\n```\\n\\n```\\nmapping(bytes32 => bool) private \\_minerRegistered;\\n\\nmapping(uint256 => uint64[]) private \\_minersByAgent;\\n```\\n\\nThat means that any time these contracts would need to be upgraded, the contents of those mappings will need to be somehow recreated in the new contract. That is not trivial since it is not easy to obtain all values of a mapping. This will also require an additional protocol-controlled setter ala kickstart mapping functions that are not ideal.\\nIn the case of `Agent` if the contract was upgradable there would be no need for a process of migrating miners that can be tedious and opens possibilities for errors. Since protocol has a lot of centralization and trust assumptions already, having upgradability will not contribute to it a lot.\\nWe also believe that during the upgrade of the pool, the PoolToken will stay the same in the new pool. That means that the minting and burning permissions of the share tokens have to be carefully updated or checked in a manner that does not require the address of the pool to be constant. Since we did not have access to this file, we can not check if that is done correctly.
Consider using upgradable contracts or have a solid upgrade plan that is well-tested before an emergency situation occurs.
```\\nmapping(uint256 => bool) public liquidated;\\n\\n/// @notice `\\_poolIDs` maps agentID to the pools they have actively borrowed from\\nmapping(uint256 => uint256[]) private \\_poolIDs;\\n\\n/// @notice `\\_credentialUseBlock` maps signature bytes to when a credential was used\\nmapping(bytes32 => uint256) private \\_credentialUseBlock;\\n\\n/// @notice `\\_agentBeneficiaries` maps an Agent ID to its Beneficiary struct\\nmapping(uint256 => AgentBeneficiary) private \\_agentBeneficiaries;\\n```\\n