Federation membership governance on the Liquid Network is the highest-stakes parameter change possible. The strong federation of functionaries—a geographically and organizationally diverse group of exchanges, financial institutions, and Bitcoin infrastructure companies—is the root of trust for the entire sidechain. Adding or removing a member is not a routine operational task; it is a governance action that reconfigures the multi-signature threshold, redistributes key material, and shifts the trust assumptions for every exchange holding L-BTC, every custody provider managing Liquid assets, and every issuer relying on the network's censorship-resistance profile. The process is governed by a formal voting mechanism among existing functionaries, requiring a supermajority to ratify any roster change, followed by a coordinated key generation ceremony to update the block-signing and peg multi-signature wallets.
Federation Member Onboarding and Offboarding Governance
The Governance Surface of Federation Membership
How the Liquid Network's governance process for adding or removing federation members directly alters the protocol's trust model, operational security, and peg integrity for all participants.
The operational impact of a membership change cascades through the ecosystem. A new functionary must undergo a rigorous key generation ceremony, producing and verifying block-signing keys that are compatible with the existing dynamic federated peg. This ceremony requires synchronous participation from a quorum of current functionaries, introducing a period of heightened coordination risk. For integrators, a change in the federation roster demands immediate updates to watchtower configurations, block-signer monitoring scripts, and peg transaction verification logic. Exchanges and custody providers must re-assess their counterparty risk model, as the addition of a new functionary with a different jurisdictional or organizational profile can alter the network's collective resilience to legal coercion or operational failure. The removal of a functionary, whether voluntary or forced, triggers a similar re-keying event and requires verification that the departing member's keys are securely invalidated.
The governance surface extends beyond the technical ceremony to the economic and legal rationale for membership changes. Proposals to onboard a new functionary are often debated around the member's operational capability, jurisdictional diversity, and long-term alignment with the Liquid Network's mission. Offboarding discussions can stem from sustained signing failures, security incidents, or strategic withdrawal. For risk teams and protocol architects, the key question is not just who is in the federation, but how the governance process for changing that set is itself governed. Chainscore Labs provides independent review of federation membership proposals, assessing the impact on multi-signature threshold security, operational readiness for key ceremonies, and the downstream integration changes required for exchanges, wallets, and asset issuers to maintain a secure and compliant Liquid integration.
Governance Snapshot: Membership Changes
Operational and trust-model impact analysis when functionaries are added to or removed from the Liquid Network federation. Covers voting mechanics, key ceremony requirements, and downstream actions for integrators.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Voting power distribution | A new functionary gains voting weight; a departing functionary loses it. The m-of-n threshold may remain constant or be adjusted in a separate governance action. | Governance delegates, risk teams, investors | Re-evaluate the de facto control concentration and the number of entities required to collude or be compromised to halt the peg. |
Block signing quorum | The set of keys contributing to block signatures changes. A new member must complete a key ceremony and be added to the dynamic federation multisig. | Functionaries, watchtower operators, node operators | Verify that the new signing key is observed in the blocksigning set and that block production remains consistent during the transition. |
Peg multi-signature control | The set of keys controlling the Bitcoin reserve wallet is updated. A new member must generate and attest to a peg key; a departing member's key must be securely retired. | Exchanges, custody providers, asset issuers | Confirm the updated peg wallet script and monitor for test transactions before resuming high-value peg-in operations. |
Key generation ceremony | A new functionary must participate in a distributed key generation ceremony to create block-signing and peg wallet key shares without exposing the full private key. | Functionaries, auditors, security teams | Review the ceremony transcript and attestations to ensure no single party gained access to a complete private key during the process. |
Network topology and peering | A new functionary must establish peering connections with all existing functionaries and critical watchtowers. A departing member's nodes are decommissioned. | Node operators, infrastructure teams | Update firewall rules and peer lists. Monitor for connectivity degradation or increased block-signing latency during the transition period. |
Trust model assumptions | The set of jurisdictional and organizational entities securing the network changes. A new member introduces a new legal and operational risk surface. | Investors, compliance teams, risk analysts | Re-assess the federation's geographic and organizational diversity. Update threat models to account for the new member's regulatory exposure and operational security posture. |
Emergency key access | If the new or departing member was an emergency key holder, the disaster recovery authorization set must be updated. | Custody providers, risk teams | Verify the current emergency key holder roster against the canonical source. Confirm that the threshold for emergency recovery actions remains intact. |
Voting Mechanics and the Key Generation Ceremony
How the Liquid federation translates governance decisions into cryptographic action through voting and distributed key generation.
The onboarding or offboarding of a Liquid functionary is not a single transaction but a coordinated cryptographic ceremony that alters the trust anchor for the entire sidechain. The process begins with a formal governance proposal, but its execution depends on the federation's ability to reach a supermajority vote and then collectively perform a distributed key generation (DKG) ceremony. This ceremony reconfigures the multi-signature threshold that controls the two-way peg, effectively transferring custody authority over the network's Bitcoin reserves to the new functionary set.
The DKG ceremony is the operational bottleneck and the highest-risk phase of any membership change. Each functionary must run a coordinated protocol to generate a new shared public key without any single member ever holding the full private key. A failed ceremony—due to a member being offline, a software incompatibility, or a network partition—can stall the onboarding process and leave the federation in an intermediate state. This creates a window of operational fragility where the old and new key sets may both be partially active, requiring manual intervention and careful watchtower monitoring to ensure peg transactions continue to be signed.
For exchanges, custody providers, and asset issuers, the voting outcome is less important than the successful completion of the ceremony. A governance vote to onboard a new member signals intent, but the actual change in trust assumptions only crystallizes when the new multi-signature key is active. Teams integrating with Liquid should monitor not just governance proposals but also the on-chain evidence of a completed key ceremony. Chainscore Labs can assist operators in reviewing ceremony readiness, validating the new key configuration against the governance mandate, and updating integration monitoring to track the active signer set.
Who Is Affected by a Roster Change
Federation Members
A roster change directly alters the operational burden and security responsibility for all functionaries. New members must complete a key generation ceremony, establish secure block-signing infrastructure, and integrate with the federation's watchtower and monitoring systems. Existing members must update their local configurations to recognize the new block-signing keys and adjust their multi-signature coordination logic. If the change involves an offboarding, remaining functionaries must verify that the departing member's keys are revoked and can no longer participate in peg-out authorizations.
Operators should test the new quorum dynamics in a staging environment before the change activates on mainnet. Failure to update configurations can lead to missed signing rounds, degraded block production, or peg transaction delays.
Operational Impact and Integration Changes
Changes to the Liquid federation roster directly alter the multi-signature trust model, requiring exchanges, custody providers, and asset issuers to update their operational security assumptions and integration configurations.
Multi-Signature Threshold Re-evaluation
Onboarding or offboarding a functionary changes the total number of signers (n), which may shift the security-to-liveness ratio of the m-of-n peg threshold. Integrators must re-evaluate their trust model: a larger federation can increase decentralization but also expands the attack surface for key compromise. Exchanges should update their risk assessments to reflect the new threshold configuration and verify that the required number of compromised functionaries for a malicious peg-out remains within acceptable limits.
Peg-In Address and Script Rotation
A change in the federation membership requires a new multi-signature aggregate public key, which in turn generates a new peg-in Bitcoin address. All systems that generate or display peg-in addresses must be updated immediately to prevent user funds from being sent to an inactive script. Custody providers and exchanges must coordinate the cutover, ensure old addresses are deprecated in user interfaces, and monitor the old address for any residual deposits that require manual recovery.
Watchtower and Monitoring Reconfiguration
Operators running watchtowers or custom monitoring for Liquid peg transactions must update their configurations to track the new functionary set. This includes updating the list of block-signing public keys to verify chain finality and the peg-out authorization keys to detect unauthorized withdrawal attempts. Failure to update monitoring will result in a loss of visibility into peg health and an inability to detect a malicious quorum of the new functionary set.
Key Ceremony Verification Requirements
The onboarding of a new functionary involves a distributed key generation ceremony to create a new threshold signing key without any single party reconstructing the full private key. Integrators and auditors should request attestations that the ceremony was completed correctly, that old key material was verifiably destroyed, and that the new functionary's operational setup meets the federation's security policy. This is critical for maintaining trust in the peg's integrity.
Client and Library Compatibility Check
While federation roster changes are a governance action rather than a hard fork, downstream client software that hardcodes functionary public keys or peg-in scripts will break. Wallet libraries, bridge interfaces, and asset issuance tools must be audited for hardcoded constants that reference the old federation set. Teams should implement dynamic federation parameter discovery where possible to reduce the operational overhead of future member rotations.
Chainscore Labs Readiness Review
A federation roster change is a high-stakes event that can disrupt the two-way peg if integrations are not updated in lockstep. Chainscore Labs provides protocol impact assessments and integration readiness reviews for exchanges, custody providers, and asset issuers facing a functionary set change. We verify address rotation procedures, monitor configuration updates, and trust model re-evaluations to ensure a safe transition.
Risk Matrix for Membership Transitions
Evaluates the operational, security, and trust implications when functionaries are added to or removed from the Liquid federation, helping operators and integrators assess readiness and monitor transition risk.
| Risk Area | Failure Mode | Severity | Affected Actors | Mitigation and Action |
|---|---|---|---|---|
Multi-Signature Threshold | A change in the total number of functionaries without a corresponding threshold adjustment can break the liveness/security balance, making the peg unspendable or easier to compromise. | Critical | Functionaries, Exchanges, Custody Providers | Verify the new m-of-n configuration against the canonical source. Model the impact on peg finality and Byzantine fault tolerance before the transition completes. |
Key Generation Ceremony | A compromised or incorrectly executed ceremony for a new functionary's block-signing key can introduce a malicious key, enabling signature forgery or peg theft. | Critical | Functionaries, Watchtower Operators, Asset Issuers | Require attestations of ceremony integrity. Monitor for unexpected key material on the network immediately following the onboarding. Chainscore Labs can review ceremony design. |
Peg-In/Out Authorization | A newly onboarded functionary may not have their peg wallet correctly configured, delaying or failing peg-out transactions and freezing user funds. | High | Exchanges, Custody Providers, End-Users | Monitor peg-out latency and failure rates during the transition window. Confirm the new functionary's participation in successful peg transactions. |
Block Signing Liveness | The removal of a functionary before its key is fully phased out can cause a temporary drop in block production if the remaining signers cannot reach the threshold. | High | Exchanges, Wallet Providers, dApp Developers | Track block times and missed block rates. Ensure watchtower alerts are configured for liveness drops. Confirm the new signing set is stable before declaring the transition complete. |
Governance Centralization | Onboarding a functionary controlled by an already-dominant entity or removing an independent member increases governance capture risk, altering the trust model. | Medium | Investors, Risk Teams, Governance Delegates | Map the new power structure. Assess if the change concentrates voting weight for emergency peg freezes or asset freezes. Re-evaluate the federation's censorship resistance profile. |
Watchtower and Monitoring | A change in the federation roster invalidates hardcoded lists of trusted signers in monitoring tools, causing false alarms or a failure to detect a real compromise. | Medium | Watchtower Operators, Security Teams | Update all monitoring configurations with the new functionary public keys and endpoints. Test alerting logic against the new signing set. |
Integration Compatibility | Wallets and exchanges that maintain a static list of federation members for proof verification may reject valid transactions or accept invalid ones after a roster change. | High | Wallet Developers, Exchange Integration Teams | Audit integration code for hardcoded federation member lists. Implement dynamic discovery or a verified update mechanism. Chainscore Labs can perform an integration readiness review. |
Operational Readiness Checklist
A checklist for exchanges, custody providers, and asset issuers to validate operational readiness when the Liquid federation roster changes. Each item identifies a critical verification step, the risk it mitigates, and the signal that confirms readiness.
What to check: Verify that the new functionary's block-signing public key is present in the latest fedpegscript and that blocks are being signed with the expected new threshold.
Why it matters: A misconfigured or malicious key could stall block production or, in a worst-case scenario, enable a minority coalition to censor transactions if combined with other compromised keys.
Readiness signal: Your node's getblockchaininfo RPC call returns a signblock_script containing the new key, and your monitoring system confirms a consistent block production rate with the new signer participating.
Canonical Resources and Monitoring
Federation member onboarding and offboarding governance should be tracked across official documentation, implementation repositories, network telemetry, and signed operational communications. Because public materials may not expose every vote or key ceremony, teams should preserve evidence and verify the current federation state before changing risk assumptions.
Federation Change Evidence Register
Maintain an internal register for every proposed or completed member change. Record the approving governance artifact, effective activation condition, old and new functionary sets, affected signing or peg roles, key-generation attestations, software requirements, rollback plan, and responsible contacts. Evidence should be authenticated and independently reviewed; a public announcement alone does not prove that new keys are active or retired keys are unusable. Risk and compliance teams should separately document whether the change alters organizational, jurisdictional, infrastructure-provider, or correlated-failure concentration within the federation.
Integration Readiness and Escalation
Before the effective membership transition, exchanges and custodians should test deposit detection, confirmation policies, peg workflows, node synchronization, and incident escalation paths. Wallets and asset issuers should verify that no federation-specific assumptions are hard-coded into transaction validation or operational controls. Establish alerts for chain stalls, node divergence, delayed peg processing, and inconsistent activation notices. If the active roster, thresholds, or effective height cannot be independently confirmed, use conservative confirmation and withdrawal controls until the federation or relevant operator supplies authenticated clarification.
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
Frequently Asked Questions
Operational and risk-focused answers for teams integrating with the Liquid Network who need to assess the impact of federation membership changes.
Adding a new functionary changes the multi-signature threshold's security composition. You must verify:
- Identity and jurisdiction: A new member may introduce a legal jurisdiction or operational entity not previously represented, altering the network's censorship-resistance profile.
- Key generation ceremony integrity: Confirm that the new member's block-signing key was generated in a ceremony with verifiable attendance and no single point of compromise.
- Threshold re-evaluation: If the total number of functionaries (n) increases without a corresponding change to the required signatures (m), the security threshold effectively weakens. Check if a governance vote to adjust m is bundled with the onboarding.
Action: Re-run your federation risk model with the new member set. If your custody or exchange integration hardcodes a trust assumption about the federation roster, update your configuration and monitoring alerts.
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.