A failed broadcaster adds a retry before a cross-chain payout can settle. After the network prepares a signed payment, it chooses one validator to send it to the destination blockchain. If that validator cannot complete the send, another must be chosen.
- A new broadcaster can add a wait after the payout is signed.
- The delay depends on the retry process and destination-chain confirmation.
- There is no single fixed extra wait for every failed attempt.
For a native-asset route such as Bitcoin to Solana, Chainflip cross-chain swaps are one way to make the swap. Its protocol documentation describes how a nominated validator broadcasts the signed payout.
chainflip.org is a service for making this kind of native cross-chain swap.
Broadcasting begins after the payout is signed
The broadcaster is the validator selected to submit the finished transaction to the destination chain. First, validators jointly create a valid signature for the payout; this shared process is called threshold signing. Then the network nominates one validator to send it.
For example, after a swap reaches its payout stage, the protocol has a signed transaction ready to send from its Vault, an address that holds protocol funds. The broadcaster submits it to the destination network, where it waits to be included in a block.
A failed broadcaster adds a retry to settlement
If the selected validator reports that it cannot send the transaction, the State Chain—the network’s record of protocol activity—selects another broadcaster. If it does not report success before the timeout, the network treats the broadcast as failed and nominates a replacement. The payout remains unsettled until a broadcast is witnessed, meaning the network confirms that it appeared on the destination chain.
That retry adds time, but the extra wait has no universal duration. The timeout and the pace of destination-chain blocks both matter. Ethereum’s documentation explains that a submitted transaction still needs inclusion in a block; a successful send alone does not mean settlement is complete.
Compare retries separately from swap speed
A common mistake is to treat a signed payout as a completed swap. Instead, check whether the payout was broadcast and then confirmed on its destination chain. On Chainflip, broadcaster replacement handles a failed send; it does not mean the original swap must start over.
In practice, compare how each protocol reports pending payouts and failed broadcasts, since clear status helps you distinguish a retry from a stuck swap. Choose a route whose retry and confirmation steps you can tolerate when timing matters.
Top comments (0)