Description

When a new TSS public key is successfully voted on, the old TSS public key is still in effect until MsgUpdateTssAddress is executed.

In order to migrate funds from the old TSS account to the new TSS account, ZetaChain introduced the MsgMigrateTssFunds message. This message will migrate funds from the current TSS account to the newest TSS account. After this step, MsgUpdateTssAddress can be executed to start using the new TSS account for cross-chain transactions.

Overall, the ordering of steps for this is as follows:

1. Observers use MsgCreateTSSVoter to vote on the new TSS public key.

2. After a successful vote, MsgMigrateTssFunds is used to migrate funds to the new TSS account.

3. Finally, MsgUpdateTssAddress is used to start using the new TSS account.

Impact

The issue here is that nothing enforces the above ordering of steps. The MsgUpdateTssAddress can be executed prior to MsgMigrateTssFunds, and when this happens, the MsgMigrateTssFunds would attempt to migrate funds from the current (new) TSS to itself, which would not work as intended.

ZetaChain will likely have another way to migrate the funds. However, the implementation of this message suggests that they are attempting to make this the only way to migrate the funds; therefore, we mark the impact as "Low".

Recommendations

Implement a global flag of some sort to enforce that MsgMigrateTssFunds must be executed before MsgUpdateTssAddress.

Remediation

This was fixed in commit f34c26d3↗, by adding a key generation/migration process. Specifically one that enforces the order of operations such that a key migration cannot happen without the prerequisite steps. These steps have been outlined by the ZetaChain team as:

The keygen process should follow the order Add node account → Generate new keys → Migrate Funds → Update TS