Security Council

The Security Council is a trusted group responsible for safeguarding Citrea and Clementine operations. It is not a governance body but a security-critical role focused on bridging, vault operations, and system upgrades.

Composition

The Security Council consists of 5 members operating under a 3-of-5 multisignature scheme. At least three members must provide verifiable signatures for any action to be valid.

The majority of the security council operates independently from Chainway Labs, ensuring developers cannot unilaterally control Citrea.

Responsibilities

The Security Council has authority over critical operations on both Bitcoin L1 and Citrea L2.

Clementine Side (L1)

Clementine Spending Paths

• The Security Council controls one of the spending paths for all L1 deposits processed by the Clementine N-of-N multisig

• In case of signer changes or emergencies, it can spend and send a replacement deposit to a new vault address

Vault Management

• Upgrading vaults that store BTC deposited into Citrea during emergencies or planned upgrades

• Receiving and storing BTC in case of an emergency; funds are held until the emergency is resolved and a replacement deposit is sent

Bridge Signer Management

• Adding and removing bridge signers and migrating control to a new N-of-N signer set if existing members are unavailable or compromised

Replacement Deposits

A replacement deposit is a Security Council-created deposit that replaces an old move-to-vault transaction when the system needs to update the deposit covenant on-chain. It is not created by users. Instead, it is constructed by the Security Council and commits to the old move-to-vault transaction ID inside the deposit script (the citreaReplace tag plus old_move_txid). This links the new deposit to the previous move transaction, which is useful for the Citrea contract to identify which move transaction is being replaced, while using the new verifier N-of-N key so the current verifiers can sign again.

Replacement deposit outputs have two spend paths:

• The replacement deposit script (the aggregated MuSig2 verifier key for the current signer set)

• The Security Council's m-of-n multisig path. The old move-to-vault output being replaced is spent via the Security Council multisig to fund the replacement deposit.

When Replacements Happen

Replacement deposits are used in these situations:

• Bridge issues / upgrades: If a bug is discovered or design changes are made to Clementine or Citrea, funds are moved by the Security Council to a new deposit that encodes the updated rules. This is the primary "upgrade" mechanism for deposits on-chain.

• Signer changes: If the verifier (signer) set changes, the old N-of-N key may no longer be usable. The Security Council creates a replacement deposit that updates the N-of-N key while keeping a link to the old move transaction.

Emergency Stop Flow

An emergency stop transaction provides a fallback mechanism in the event that a soundness bug is identified, allowing operations to be temporarily paused while the issue is addressed. Once a fix is in place, a replacement deposit transaction is submitted to resume normal operation.

The emergency stop path is a two-step flow:

1. An emergency stop transaction spends the move-to-vault output and sends funds to a Security Council-controlled multisig output.

2. The Security Council then creates and signs a replacement deposit transaction that spends that emergency stop output to create a new replacement deposit output.

Citrea Side (L2)

System Contract Upgrades

• Upgrading the Bridge system contract

• Upgrading the Fee Vaults contracts

• Upgrading the Bitcoin Light Client contract

• Changing parameters in system contracts during emergencies or planned upgrades

Method ID Updates

• Updating the batch prover circuit Method ID stored on Bitcoin when the ZK circuit changes (for security fixes or planned upgrades)

Method ID Updates

The Method ID is the cryptographic identifier of the batch prover ZK circuit. When the circuit changes (due to security fixes or upgrades), the Security Council must update the Method ID on Bitcoin.

How It Works

Method ID updates are published to Bitcoin as a special inscription transaction type (BatchProofMethodId). Unlike regular transactions signed by a single sequencer or prover key, these transactions contain:

1. Body: The new Method ID, activation L2 height, and chain ID

2. Security Council signatures: Exactly 3 EIP-191 signatures from council members

3. Public key indices: Index (0-4) identifying which council member signed

┌──────────────────────────────────────────────┐
│         BatchProofMethodId Transaction       │
├──────────────────────────────────────────────┤
│  Body:                                       │
│    - method_id (ZK circuit identifier)       │
│    - activation_l2_height                    │
│    - chain_id                                │
│                                              │
│  Security Council Data (3 entries):          │
│    - (signature_1, pubkey_index_1)           │
│    - (signature_2, pubkey_index_2)           │
│    - (signature_3, pubkey_index_3)           │
└──────────────────────────────────────────────┘

Verification in the ZK Circuit

The Security Council's 5 public keys are hardcoded in the ZK circuit at compile time for each network. When verifying a Method ID update, the circuit performs the following checks:

1. Activation height check: The new activation L2 height must be greater than the last known activation height (prevents replay attacks)

2. Chain ID validation: The chain_id in the transaction must match the network's chain ID (prevents cross-network replay attacks)

3. Index validation: Each public key index must be between 0-4 (in correspondence with the signer set)

4. Ascending order check: Indices must be in strict ascending order to prevent duplicate signatures from the same member

5. Signature verification: Each signature is verified using EIP-191 standard against the hardcoded public key at that index

6. All-or-nothing: If any single check fails, the entire update is rejected

Batch Proof Method ID Update Transaction Verification

Network Chain IDs

Each Citrea network has a unique chain ID used for Method ID validation:

Network	Chain ID
Mainnet	4114
Testnet	5115

This design ensures that only legitimate updates signed by at least 3 distinct council members can modify the batch prover Method ID, and prevents replay attacks across networks or from historical transactions.

Trust Model

The Security Council represents a trusted component in Citrea's security model

As Citrea evolves, the goal is to minimize reliance on trusted parties through cryptographic and protocol-level guarantees. The Security Council serves as a practical security mechanism during the early phases of the network.