Threshold Signing. Signing requests on the Axelar network are processed similarly to the key-generation requests. These are invoked, for instance, when a user wants to withdraw an asset from one of the chains. These are interactive protocols, and state transition between the rounds is triggered as a function of the messages propagated via the Axelar blockchain view and every validators local memory. Handling Validator Membership Changes. The validator set needs to be rotated periodically to allow for new stakeholders to join the set. Upon a validator set update, we need to update the threshold key to be shared across the new set. Thus if we allowed anyone to join at any time, we would have to update the threshold key very frequently. To prevent this, we rotate validators every T blocks. Within intervals of T rounds, the set V R and the threshold key are xed. At every round that is an integral multiple of the parameter T , we update the validator set as follows: 7

1. At any round R, the Axelar state keeps track of the current validator set V R. V R+1 = V R unless R + 1 is a multiple of T . 2. During rounds ((i 1)T, iT ], users post bonding/unbonding messages. 3. At the end of round iT , these messages are applied to V iT 1 to get V iT .

Threshold Key Generation and Signing in the Presence of Rotating Validators. Axelar blockchain may issue a request for a new key or a threshold signature at round R. The signing process takes longer than one round, and we dont want to slow down consensus, so we request that the signature is produced before round R + 10 starts. In particular, validators start round R + 10 only after seeing a certicate for round R + 9 and a signature for each keygen/signature request issued at round R. The outcome of all round R requests must be included in block R + 11. In other words, a round R block proposal that does not contain the outcomes from a round R 11 is considered invalid, and validators dont vote on it. To ensure that all threshold messages are signed before a validator set update, Axelar does not issue any threshold requests during a round equal to 1, 2, . . . , 9 modulo T .

5.2 Network Security The security of blockchain systems relies on various cryptographic and game theoretic protocols, as well as the decentralization of the network. For instance, in proof-of-stake blockchains, without the proper incentives validators may collude and rewrite the history, stealing other users funds in the process. In proof-of-work networks, without sucient decentralization, it is quite easy to create long forks and double spend, as the multiple attacks on Bitcoin Gold and Ethereum Classic have proven.