Lifecycle of the validator
Last updated
Last updated
A user of the Glitter Bridge starts the bridging process by creating a deposit transaction on the origin network with a smart program. This transaction contains routing information about the target chain, target wallet, and information about bridged tokens and their amount.
Each validator periodically checks for the new deposit transactions on all configured chains with Glitter SDK Scroller. Validator first exclusively claims the latest scroller cursor for the available blockchain network from the shared database. This cursor is locked for other validators until the scrolling process is finished.
The retrieved transactions from Glitter SDK are validated against the validator's configuration including database settings of all existing tokens for each chain. Invalid transactions are stored in the error_transactions
working as a dead letter queue for further investigation and possible retry mechanism (not implemented yet). If the transaction passes the validation process, the validator creates and signs a release transaction on the target chain and saves the serialized transaction blob in the multisig_transactions
table.
Other validators are periodically checking the database for release transactions that are waiting for their signature. These transactions are picked up by the validator from the database, signed with the chain-specific mechanism, and the validator appends its id to the list of the signers stored in the database together with the transaction blob. Once the multi-signature threshold is achieved, the release transaction is picked up by a random validator and executed on the specific chain.