If you send crypto to a cross-chain swap, validators first check that the deposit happened on its source blockchain and then agree to record it. That check takes time because a new block can sometimes be replaced in a chain reorganisation. Knowing the steps helps you tell a normal confirmation wait from a deposit that needs investigating.
What are validators checking?
Validators check for a specific event, such as a transaction sending funds to an address the protocol is watching. They independently read the source blockchain using their own connections to its data, then report the transaction details to the protocol’s coordination chain. Those details can include the transaction ID, asset and amount.
That report is called a witness. It is a statement that a particular event occurred, rather than a cryptographic proof that the source blockchain can never change. Each validator in the active Validator Network must make its own observation; the process is not meant to rely on one operator’s report.
Validators also wait for the source chain to meet a confirmation rule, known as a safety margin. A confirmation means another block has been added after the block containing the deposit. The extra blocks lower the chance that a reorganisation will remove the deposit, but they cannot make that chance zero.
How does one observation become an accepted event?
After the required safety margin, validators submit witness transactions to the protocol’s coordination chain. A transaction submitted to a blockchain is often called an extrinsic; here, it carries a validator’s report into the chain’s shared record. Other validators compare the report with what they observed.
In Chainflip, that coordination chain is the State Chain, and the reports concern events on separate external blockchains. The State Chain accepts a witnessed event once enough validators in the active set report it consistently: the documented standard set has 150 validators, with 100 reports needed. That shared threshold is what turns individual observations into a protocol decision.
If a validator reports different details from the others, its report does not help reach the threshold. The network can also punish a validator for a false report or for repeatedly failing to report events that the required majority observed. This makes agreement depend on independent observations and an on-chain threshold, rather than on trusting the first validator to notice a transaction.
What happens in a Bitcoin deposit example?
Suppose you send Bitcoin to a deposit address for a swap. First, the transaction appears in a Bitcoin block. Validators look for it at the watched address, check the transaction details, and wait for the protocol’s Bitcoin safety margin: the current documentation lists two additional blocks.
Then each validator submits its witness to the State Chain. When 100 of the 150 validators have reported the same deposit, the event is recorded as real for the protocol. That record lets the protocol account for the incoming funds and continue processing the swap; it does not mean the Bitcoin transaction has become impossible to reverse.
For Chainflip users, this is a different step from the swap itself: the deposit first has to be recognised by validators, while the State Chain handles protocol accounting and swap instructions. If you are comparing how protocols handle cross-chain deposits, Chainflip is one example of a system that waits for external-chain observations to reach a validator threshold before treating an incoming transfer as recorded.
What should you do while the network waits?
Check that your wallet shows the transaction as broadcast, then use its transaction ID to confirm it appears on the correct source blockchain and pays the intended deposit address. Compare the amount and address with the deposit instructions you were given. A wallet’s “sent” status means it submitted a transaction; it does not by itself show that validators have accepted it.
Allow time for both the source chain’s confirmation rule and the validator reports to complete. These waits vary by chain: Bitcoin blocks average about ten minutes, while other chains use different block times and confirmation rules. A slow block or temporarily unavailable validator connection can delay recognition, even when your transaction is valid.
If the transaction is in a block but the protocol has not recorded it after the expected wait, keep the transaction ID and check the service’s status information before taking action. Do not send a second deposit just because the first one is still waiting; the original may be recognised later. The key detail is whether the source chain still includes your transaction and whether enough validators have witnessed it.
For a chain with deterministic finality, validators may be able to accept a deposit after it is final in a block, without waiting for extra blocks. For a chain where blocks can be reorganised, expect a safety margin and a longer wait. That difference in the source chain’s finality is what should change your expectation—not the number of confirmations shown by a wallet alone.
Top comments (0)