Block Signing Ceremony Mechanics

The Liquid Network produces blocks through a round-robin signing ceremony among its federation of functionaries, a process distinct from Bitcoin's proof-of-work. In this model, a designated block proposer is selected from the active functionary set to construct a new block. This selection rotates through the federation members in a deterministic order. The proposer gathers pending transactions from the mempool, assembles them into a block, and broadcasts the block proposal to all other functionaries for validation and signature.

Upon receiving a valid proposal, each functionary verifies the block's contents and, if accepted, generates a partial signature using their threshold signing key. These signatures are gossiped among the functionaries. The ceremony is governed by critical timeout parameters, such as signblockscript timeout values, which dictate how long a functionary will wait for a proposal or for sufficient signatures to be collected. If a proposer fails to produce a block in time, or if signature collection stalls, a new proposer takes over in the next round, ensuring liveness. A block is finalized and committed to the chain once the required threshold of signatures is collected, forming a complete block signature.

For functionary operators and watchtowers, diagnosing signing anomalies requires monitoring these specific mechanics. Missed slots, high proposal latency, or signature collection failures often point to network partitions between functionaries, resource exhaustion on proposer nodes, or clock synchronization drift. Understanding the interplay between the round-robin schedule and timeout parameters is essential for tuning infrastructure to maintain signing reliability and for identifying which functionary is responsible for a signing fault during an incident.

In the Liquid Network, block creation is not a competitive process but a cooperative, round-robin ceremony among the federation's functionaries. The block proposer for a given round is selected deterministically based on the current block height and the ordered list of active functionary keys. This ensures that every functionary receives a fair and predictable share of proposal opportunities, eliminating the latency and resource races inherent in proof-of-work mining. The selection algorithm is a simple modulo operation: proposer_index = block_height % number_of_functionaries. This index corresponds to the functionary's position in the sorted list of active signing keys, making the proposer identity known to all participants well in advance of the round.

Once the designated proposer constructs a valid block, the signature collection phase begins. The proposer broadcasts the block to all other functionaries, who then validate its contents against the network's consensus rules. Upon successful validation, each functionary signs the block with its private key and returns the signature to the proposer. The ceremony is governed by a critical timeout parameter, signblockscript_timeout, which defines the maximum duration the proposer will wait for signatures. The block is finalized only when the proposer collects a threshold of signatures, defined by the signblockscript_threshold parameter, which is typically a supermajority of the total number of functionaries. If the proposer fails to collect the required signatures within the timeout window, the round fails, and the next functionary in the sequence will attempt to propose a block for the subsequent height.

Operational monitoring of this ceremony is essential for diagnosing network health. A pattern of missed rounds from a specific functionary can indicate node misconfiguration, network partition, or HSM signing failures. Watchtower operators and functionaries should track metrics such as proposal success rate per functionary, signature collection latency, and timeout frequency. Anomalies in these metrics often precede more severe degradation of the two-way peg's reliability. Chainscore Labs can assist federation members and integrators by analyzing signing performance data, tuning timeout parameters to match network conditions, and designing alerting systems that provide early warning of ceremony disruptions before they impact peg operations.