# Timelock on ownership

## Context

In the SFT contracts (Offchain Asset Vault - ethgild repo) we have a standard Open Zeppelin ownership setup.

The owner can change the authorizer contract, but the main contract itself is not upgradeable.

The authorizer however controls critical functionality such as minting and burning.

If a mint function on a token contract is ever hacked, the hacker can instantly rug the supply (programatically within the same transaction), making a response impossible.

### Multisig hacks

The usual setup is to put the owner behind an M of N multisig, such as a gnosis safe.

The problem with these, is that hacks are surprisingly common as the value secured by the multisig scales.

As the TVL/MC increases, the budget for an attacker also increases. For contracts that are worth hundreds of millions or even billions, there are attackers that have essentially infinite time, expertise and money.

For example, ByBit multisig was recently hacked by the North Korean government for a loss of $1.5B (https://rekt.news/bybit-rekt). The hacker compromised the server that presents the gnosis safe front end, presenting a different interface only for the owners of the singular multisig wallet being targetted.

For a $1.5B payday, phishing and supply chain hacks can get *very* sophisticated. In such a situation, both the M and N are irrelevant if the signers are eclipsed (their devices have no honest view on the network, so are tricked to sign malicious data).

Generally multisig security doesn't have much room for improvement beyond the initial setup. Increasing both M and N give somewhat diminishing returns relative to the resources than an attacker can field as the honeypot grows. Mathematically, if the M are all perfectly uncorrelated, this should not be the case. In reality the practicalities of running a business typically forces the M to be not only correlated but increasingly likely to take shortcuts as security processes become more onerous.

We've seen straight key compromises of over $600M from a 5 of 9 multisig (https://rekt.news/ronin-rekt) demonstrating this issue. Having a 5 of 9 setup sounds very secure on paper, but 4 of the 5 keys used in the compromise were held by the same real world entity, effectively reducing the M for the attack from 5 to 2.

It's easy to be critical from the couch of such compromises, especially when large value is stolen, but the reality is that managing multisigs correctly is a challenge that most organisations do not have the competence to tackle.

**If we're going to be focussing on tokenising real world assets, the expectation should be that keyholders will have a tradfi background, and not even a technical one. It's more likely that a non-technical company director will hold the master key to their issuance contract than one of their employed IT security professionals (if they even have any).**

### Implications of an infinite mint

The infinite mint is really the worst case scenario for a token, or "rug" as it is more commonly known. The fact that this scenario even has a coloquial term for it should allude to both the frequency and severity of the danger.

The basic attack is that the hacker gives themselves a gorrillion tokens. The exact number doesn't matter, what's important is that the pragmatic gap between the size of the mint and infinity is merely a technical formality.

Once the user has unlimited tokens, they proceed to raid all the onchain and offchain sources of liquidity that they can, until they're detected and liquidity dries up. For onchain liquidity specifically, the trade that cleans out the uniswap pool and the mint itself could be literally the same transaction onchain, so it's physically impossible for anyone to guard themselves against this, the response time is effectively zero.

The problem with this is that the damage to liquidity is irreversible. For everyone who was merely holding the token, the issuer could always airdrop a fresh token based on a snapshot of balances in the moment before the hack. But for everyone who had buys up for the token, they've lost all the money backing their purchases, which includes all uniswap LPs who are simultaneously buying and selling every token they LP 24/7/365.

The real kicker is that once the LPs have been wiped out, they're significantly less likely to come back and LP a 2.0 airdropped token, as the project reputation is now seriously damaged (and also they lost their money).

**In summary, infinite mints kill/cripple *secondary* markets for tokens, both in the moment of the hack, and for a very long time afterward.**

Side note, this is basically why "security modules" in protocols where the project's own token insures the protocol are very weak guarantees. If a project is compromised badly enough, the secondary market will instantly evaporate, long before any hypothetical insurance payments could be made from token sales.

### Implications of other forms of compromise

The hacker can replace the authorizer arbitrarily so they can corrupt other authorization logic beyond mints.

E.g.

- They can (un)certify the SFT to (un)freeze transfers
- Can confiscate tokens from any existing holder to themselves
- Can burn any tokens they confiscate, so can burn any token from any wallet

These actions are all either strictly equivalent to, or a less damaging version of the infinite mint OR they would be generally recoverable via. a snapshot and airdrop mechanism if the damage was at the level of mere vandalism/griefing.

As the RWA are all held offchain, the attacker can't actually damage the primary market value of the tokens unless they can also convince the offchain business processes to deliver the offchain assets to them. In the vast majority of cases this would be simply impossible as it would involve physical delivery, or at least some kind of transfer and settlement process.

The only attack that potentially wouldn't be handled exactly the same way as an infinite mint would be an infinite freeze. The infinite freeze scenario doesn't benefit the attacker, but griefs and damages token holders. For example, if tokens were frozen into a uniswap pool, then LPs would not be able to withdraw their paired tokens in the pool, even if a snapshot and airdrop were to take place. From the LPs position, they lost their money exactly as they would have in a straight rug, the only difference is that the money is locked in defi rather than siphoned to the attacker.

There's no clear reason an attacker would freeze if they could rug, but as it is a dangerous possibility it is worth enumerating.

### Straight timelock

The simple/naive suggestion is to timelock any ownership change.

For example, a proposal would have to be made by the current owner, and it could not be finalised by that owner for 24 hours.

This partially mitigates the phishing scenario, where the attacker merely tricks the key holders that control ownership, but does NOT mitigate a key compromise scenario.

This is because, once the keys are compromised, the attacker can repropose themselves as the new owner an unlimited number of times, as long as they pay gas. The whole system becomes a war of attrition with the incentives extremely stacked in the attackers favour. The budget for the attacker is the entire TVL of the protocol that they can liquidate when they succeed, and they only have to succeed once. The budget for the defender is whatever funds they have available in their personal security budget, and they have to succeed in preventing the attacker every time.


This is bad because somewhere between 43-69% of thefts in the crypto industry in 2024 were private key compromises.

While the ByBit hack was record breakingly catastrophic, by frequency of type of exploit, it represents the minority. Stealing keys is generally the most direct and effective route for attackers compared to elaborate supply chain hacks.

We don't need to speculate on why this is, we can simply accept the numbers, and that our target audience - tradfi directors and CFOs, etc. - are not going to beat the averages here.

To make matters worse, once the keys are visibly compromised, the process is all public onchain and so the overall effect may well still be functionally the same on the secondary market. All the token holders can see the tug of war between attacker and defender happening in real time, and have no incentive to do anything other than dump their tokens as quickly as possible and move on to greener fields. Not many investors are going to feel comfortable bag holding a token that is one undefended timelock away from going to zero. Even if the attacker does nothing, other than publicly signal that the keys are compromised, that's enough to severely and permanently damage both the primary and secondary market for the token.

The straight timelock also introduces a secondary problem that doesn't exist in an instantaneous rug. At least in the case of a sudden rug, there's a clear moment in which the project team *could* take a snapshot and make as many people whole as possible. In the case of a timelock, there will be a lot of market activity that continues, unware of the situation, while the whole attack plays out. The longer things are drawn out, the ability to take a clean snapshot only decreases. This is because every token that changes hands between peers *other than the attacker* is going to be rolled back by the snapshot, meaning that token senders get to have their cake and eat it too, while receipients get nothing post-airdrop.

## Timelock and freeze

As a proposed solution, alternative to the straight timelock, we could put the contract into a new frozen state very similar to an uncertified contract but controlled directly by the owner, ostensibly exclusively for the purpose of disaster mitigation and recovery.

The freeze would be in addition to the regular certification freeze mechanics, i.e. BOTH the owner and certification freezes have to be `false` in order for users to transfer tokens.

The owner freeze would exist in its own "space" however, in the sense that regular considerations such as confiscation/handler overrides that normally apply to certification freezes would be ignored by the owner freeze.

Similarly, the owner freeze would have its own list of exempt addresses that can send/receive tokens, maintained by the owner.

The idea of the above is that if a highly sensitive operation such as changing the ownership/authorizor were being performed, the system could pre-emptively freeze itself temporarily. This way, if a hacker attempted to modify the contracts, the system would immediately freeze giving the real owners the ability to respond.

In the case of a hack, the real owners would *extend* the freeze continually (potentially permanently) until/while they facilitate a migration to a new token.

As long as the compromised owner accounts are not also priviledged (e.g. can't infinite mint etc.) then the attacker has limited direct options to influence/harm the migration process.

Even if the attacker were to add exemptions for themselves to unfreeze their accounts, this would not give them any additional tokens that they didn't already have, and the project team could track and ignore any bad addresses in offchain migration scripts.

The attacker could attempt to remove exemptions to grief the migration, e.g. by attempting to keep uniswap LPs frozen in the old token, so this would need to be considered by the governance process for the owner itself.

### Token implementation

The goal is to make the minimum and simplest possible modifications to the token contract to facilitate the above.

The assumption is that the owner of the token *will be a dedicated governance contract* and not just an EOA or vanilla multisig.

This way, the governance of the system can be iterated on over time and tailored to more specific project needs in the same way as the authorizer is currently.

Note that conceptually there is a lot of overlap between the authorizor and ownership restrictions, potentially in the future it would make sense to merge everything into the scope/responsibilities of the authorizor. For now, we keep the ownership/governance of the contract and the authorizor as separate, with the owner strictly "above" the authorizor.

The token contract will have additional external methods all with the `onlyOwner` modifier:

- `ownerFreezeUntil(uint256 timestamp)` sets the token to be frozen until this time
- There is no "thaw" ability, if the time is in the past relative to the current freeze end (if frozen) then this is a no-op
- This can be used to extend a current freeze if `timestamp` is in the future relative to the end of the current freeze
- `ownerFreezeAddSender(address sender)` Adds `sender` to the mapping of addresses that cannot be frozen when sending
- `ownerFreezeRemoveSender(address sender)` Removes `sender` to the mapping of addresses that cannot be frozen when sending
- `ownerFreezeAddReceiver(address receiver)` Adds `receiver` to the mapping of addresses that cannot be frozen when receiving tokens
- `ownerFreezeRemoveReceiver(address receiver)` Removes `receiver` from the mapping of addresses that cannot be frozen when receiving tokens

Note that these methods by themselves do NOT improve security at all. If some attacker directly compromises the private keys they can do all the above in an unrestricted manner.

However, they provide the minimal toolset for a owner contract to be written with appropriate governance protocols.

Also note that the existing `onlyOwner` external methods for transferring ownership and updating the authorizor still exist.

The freezing logic is very simple, when the contract is frozen by the owner, if the sender is not in the mapping and neither is the receiver, every transfer reverts.

This includes minting, burning, confiscations, etc. as they're all forms of transfer.

It DOES NOT include emitting data as events, that would continue as usual. Data emissions are unauthorized function calls that only impact offchain logic anyway, so freezing them is irrelevant.

### Example owner contract

Similar to the authorizor contract, there's no singular owner contract that will be correct in all contexts.

There's a few basic recommended minimum requirements we can state that most or all owner contracts would need to meet, such as:

- All sensitive state changes should trigger a freeze
- Changing the owner
- Changing the authorizor
- Changing the freeze behaviour
- Changing sender/receiver bypasses
- The duration of a freeze should be preset by the owner, and merely triggered by sensitive operations
- i.e. it should NOT be determined in the moment of the trigger, otherwise an attacker will just set it to `0` for the attacks
- Changing the freeze duration should itself trigger the freeze
- Ad hoc freezing should probably be exposed to allow the msig controlling the owner contract to arbitrarily freeze as required in addition to the automated freezes
- Time locks on removing sender/receivers after they have been added, to prevent an attacker griefing and instantly removing access as soon as it is granted

A basic implementation of the above should be sufficient for attack mitigation and recovery provided:

- The owner is NOT granted additional priviledges in the authorizor
- The freeze duration is sufficiently long for the real owner to stage an appropriate response 24/7/365
- e.g. consider an attacker waiting til new years eve to move, will the real owners have enough time to coordinate a response while out celebrating?
- The owner operators are sufficiently connected to their community and have the technical capacity to coordinate a migration while the token is frozen, and appropriately unfreeze assets as needed

A more sophisticated/situational implementation of the above might include more complex logic such as:

- Dynamic freeze durations, where the team could temporarily extend freezes (e.g. during holiday period freezes could last several days)
- 2-step proposal/acceptance governance workflows on state changes, to add additional speed bumps for attackers to overcome
- Additional freeze triggers, potentially even integrated with the authorizor contract

## Rollout

Initially there won't be any ownership contracts written, which means the owner for tokens will be a normal multisig or even EOA.

While the TVL for the token is relatively low, this is reasonable as the cost to an attacker is high relative to the reward.

As the value secured by the token increases, the owner should strongly consider implementing governance mechanisms as an ownership contract.

Note that because the initial setup is a simple multisig the token contract WILL NOT freeze when the ownership is changed. Similarly, nothing will freeze when the authorizor is changed.

This means that the initial transition from a multisig to a dedicated governance contract will be seamless without a system freeze.

It also means that as long as the multisig directly owns the token contract, there is no native protections against neither phishing nor direct key compromise attacks.