Ordering of steps for TSS funds migration is not enforced
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:
Observers use
MsgCreateTSSVoter
to vote on the new TSS public key.After a successful vote,
MsgMigrateTssFunds
is used to migrate funds to the new TSS account.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