Vulnerability: Unpredictable behavior due to front running or general bad timing
Severity: high

Description:
In a number of cases, administrators of contracts can update or upgrade things in the system without warning. This has the potential to violate a security goal of the system.\\nSpecifically, privileged roles could use front running to make malicious changes just ahead of incoming transactions, or purely accidental negative effects could occur due to unfortunate timing of changes.\\nSome instances of this are more important than others, but in general users of the system should have assurances about the behavior of the action they're about to take.\\nSystem Parameters\\nThe owner of the `TBTCSystem` contract can change system parameters at any time with changes taking effect immediately.\\n`setSignerFeeDivisor` - stored in the deposit contract when creating a new deposit. emits an event.\\n`setLotSizes` - stored in the deposit contract when creating a new deposit. emits an event.\\n`setCollateralizationThresholds` - stored in the deposit contract when creating a new deposit. emits an event.\\nThis also opens up an opportunity for malicious owner to:\\ninterfere with other participants deposit creation attempts (front-running transactions)\\ncraft a series of transactions that allow the owner to set parameters that are more beneficial to them, then create a deposit and reset the parameters to the systems' initial settings.\\n```\\n/// @notice Set the system signer fee divisor.\\n/// @param \\_signerFeeDivisor The signer fee divisor.\\nfunction setSignerFeeDivisor(uint256 \\_signerFeeDivisor)\\n    external onlyOwner\\n{\\n    require(\\_signerFeeDivisor > 9, "Signer fee divisor must be greater than 9, for a signer fee that is <= 10%.");\\n    signerFeeDivisor = \\_signerFeeDivisor;\\n    emit SignerFeeDivisorUpdated(\\_signerFeeDivisor);\\n}\\n```\\n\\nUpgradables\\nThe proxy pattern used in many places throughout the system allows the operator to set a new implementation which takes effect immediately.\\n```\\n/\\*\\*\\n \\* @dev Upgrade current implementation.\\n \\* @param \\_implementation Address of the new implementation contract.\\n \\*/\\nfunction upgradeTo(address \\_implementation)\\n    public\\n    onlyOwner\\n{\\n    address currentImplementation = implementation();\\n    require(\\_implementation != address(0), "Implementation address can't be zero.");\\n    require(\\_implementation != currentImplementation, "Implementation address must be different from the current one.");\\n    setImplementation(\\_implementation);\\n    emit Upgraded(\\_implementation);\\n}\\n```\\n\\n```\\n/// @notice Upgrades the current vendor implementation.\\n/// @param \\_implementation Address of the new vendor implementation contract.\\nfunction upgradeTo(address \\_implementation) public onlyOwner {\\n    address currentImplementation = implementation();\\n    require(\\n        \\_implementation != address(0),\\n        "Implementation address can't be zero."\\n    );\\n    require(\\n        \\_implementation != currentImplementation,\\n        "Implementation address must be different from the current one."\\n    );\\n    setImplementation(\\_implementation);\\n    emit Upgraded(\\_implementation);\\n}\\n```\\n\\nRegistry\\n```\\nfunction registerFactory(address payable \\_factory) external onlyOperatorContractUpgrader {\\n    require(\\_factory != address(0), "Incorrect factory address");\\n    require(\\n        registry.isApprovedOperatorContract(\\_factory),\\n        "Factory contract is not approved"\\n    );\\n    keepFactory = \\_factory;\\n}\\n```\\n

Impact:

Recommended mitigation:
The underlying issue is that users of the system can't be sure what the behavior of a function call will be, and this is because the behavior can change at any time.\\nWe recommend giving the user advance notice of changes with a time lock. For example, make all upgrades require two steps with a mandatory time window between them. The first step merely broadcasts to users that a particular change is coming, and the second step commits that change after a suitable waiting period.