Key management

This page describes the signer roles in the LinethLineth (Formerly the Linea Stack) The open-source ZK-rollup stack, codebase, and technical protocol that's the foundation of Linea Mainnet. Operators can deploy this stack to launch their own Ethereum-compatible L2 or L3 networks. stack, the key custody options each role can use, and the controls the operatorOperator The entity or consortium responsible for deploying, administering, and running the network infrastructure, contracts, keys, access controls, and operational procedures for a network built on Lineth. owns.

Signer roles

The Lineth deployment components sign data using dedicated keys. The coordinatorCoordinator Lineth's coordination module for batching, proof generation, and finality submission. The coordinator monitors block production, manages conflation deadlines, batches blocks, combines batches into blobs, orchestrates execution, compression, and aggregation proofs, and submits proofs and data to the finalization layer. has three signer roles (blob submission, aggregation, and message anchoring). The PostmanPostman The service that relays messages between the canonical message service contracts on a Lineth network and its finalization layer. Postman listens for calls made to the contract on one network and passes the submitted information to the contract on the other network. It's currently centralized, but is intended to be decentralized. has two (message relay on the Lineth network and finalization layer). The sequencerSequencer The set of Linea Besu plugins responsible for ordering, building, and executing blocks in a way that allows the subsequent ZK proof to be made, including the tracer. The sequencer is a plugin set rather than a standalone process; a node that runs it alongside a Maru validator is a sequencer node. liveness plugin and Maru validatorMaru validator A Maru consensus client that belongs to the QBFT validator set and proposes and votes on blocks. Each Maru validator requires its own dedicated Linea Besu execution client running the sequencer plugins, which builds the payload Maru then signs and broadcasts. A validator can also drive additional follower execution clients. each have one. Each signer role has its own key, configuration, and impact if that key is lost or compromised. Do not reuse one key across roles.

Component	What it signs	Configuration reference	If the key is lost or compromised
Coordinator	Blob submission to the finalization layer	l1-submission.blob.signer.type	Submission from that address stalls or can be issued by an attacker until OPERATOR_ROLE is revoked
	Aggregation and finalization submissions	l1-submission.aggregation.signer.type	Finalization from that address stalls or can be issued by an attacker until OPERATOR_ROLE is revoked
	Message-anchoring transactions	message-anchoring.signer.type	Anchoring from that address stalls or can be issued by an attacker
Postman	Message claim or relay on the finalization layer	L1_SIGNER_TYPE	Finalization layer relay from that address stalls or can be issued by an attacker
	Message claim or relay on the Lineth network	L2_SIGNER_TYPE	Lineth network relay from that address stalls or can be issued by an attacker
Sequencer liveness plugin	Liveness contract transactions	—plugin-linea-liveness-signer-type	Liveness reporting from that address stalls or can be issued by an attacker. Block production does not use this key
Maru validator	QBFT consensus messages	persistence.private-key-path	That validator can miss or sign unauthorized consensus messages. Replacing the key is a coordinated genesis update

Coordinator blob and aggregation signers must use an Ethereum address that holds the rollup contracts' OPERATOR_ROLE. Custody (how the key is stored) does not grant that role. Keep signer addresses aligned with the role holders in Admin keys and upgrade authority.

Key custody options

Each signer role configures a key custody backend. Lineth supports the following custody options.

Local private key

A local backend keeps the private key in the signing component: in process memory, or as a Maru validator key file.

Configure web3j for the coordinator or private-key for the Postman to load a hex-encoded secp256k1 private key into the process. Use those backends for development and local testing only. The local stack quickstart generates runtime keys for that purpose and is not a production custody model.

Do not use in-process keys in production

In a production deployment, keep coordinator and Postman keys in hardware-backed custody: a hardware security module (HSM) or cloud key management service (KMS), through Web3Signer, the Postman's AWS KMS backend, or a custom signer factory.

Set private-key-path for Maru to mount a validator key as a file. Protect the file in production. To use hardware-backed custody for Maru signing, use a custom signer factory.

Web3Signer

Web3SignerWeb3Signer An open-source, remote signing service that externalizes private key management from nodes. Web3Signer integrates with enterprise-grade key stores and exposes HTTP-based signing APIs so consensus and execution clients can obtain signatures on blocks, attestations, and transactions without directly holding the private keys. is a remote signing service you call over HTTP. When using Web3Signer, the Lineth component holds the endpoint and the public key. Web3Signer holds the private key in the store attached to it.

Configure web3signer for the coordinator or Postman, or WEB3SIGNER for the sequencer liveness plugin, to call Web3Signer over HTTP. Optional mutual TLS uses PKCS12 keystore and truststore files.

Use Web3Signer when a component should sign without holding the private key, or when you want an HSM or KMS that Lineth does not call directly. Several components can share one Web3Signer. See the Web3Signer documentation for more information.

AWS KMS (Postman)

AWS Key Management Service (KMS) is a managed cloud keystore. When using AWS KMS, the PostmanPostman The service that relays messages between the canonical message service contracts on a Lineth network and its finalization layer. Postman listens for calls made to the contract on one network and passes the submitted information to the contract on the other network. It's currently centralized, but is intended to be decentralized. holds a key ID, Amazon Resource Name (ARN), or alias. It loads the public key from the KMS and asks the KMS to sign; the private key stays in the KMS.

Configure aws-kms for the Postman to sign with AWS KMS. Provide the key ID, ARN, or alias. Region is optional and falls back to the AWS SDK default.

The Postman requires a key with spec ECC_SECG_P256K1 and usage SIGN_VERIFY. It calls kms:GetPublicKey once to derive the Ethereum address, then kms:Sign with MessageType=DIGEST for each transaction. Credentials come from the AWS default provider chain, not from the Postman configuration.

The coordinator and the sequencer liveness plugin do not have a built-in aws-kms type. To keep those keys in a KMS, point those components at Web3Signer and load the key from AWS KMS in Web3Signer, use another store Web3Signer supports, or use a custom signer factory.

Custom signer factory

A custom factory injects a named signer that is not one of the built-in local, Web3Signer, or AWS KMS backends.

Configure CUSTOM for the coordinator or sequencer liveness plugin to resolve a named signer through an injected factory. The coordinator fails if no factory is configured for that name.

Lineth for institutions

For institutional and enterprise deployments, Lineth can supply the custom factory so the coordinator, sequencer liveness plugin, and Maru validator sign with AWS KMS without deploying Web3Signer. This is a proprietary feature that is not part of the open-source stack. To request access, use the strategic inquiries form.

Operator responsibilities

Operators own the following controls:

• Key generation: Create each key in the chosen store (local file, Web3Signer store, or AWS KMS).
• Storage and custody: Keep private key material out of application configuration and source control. Use hardware-backed custody for production signing.
• Access to the signer: Apply least-privilege identity and access management (IAM) policies or a signer access control list (ACL), network isolation, and credential rotation for anyone allowed to sign.
• Onchain authorization: Grant the signer address the role it needs (OPERATOR_ROLE for coordinator submission), and revoke it when the key is retired.
• Access review and audit: Review who can use the KMS key, Web3Signer API, and onchain roles. Retain and review signer and KMS audit logs against your policy.
• Incident response: Detect compromise, pause affected subsystems, revoke roles, and replace keys.
• Rotation and recovery: Plan rotation and recovery per key class:
  • Operational signers (coordinator, Postman, sequencer liveness plugin) sign as a specific Ethereum address. Changing the key changes the sender unless the new material is the same key pair. If you change the address, update the matching onchain role (for example, OPERATOR_ROLE for coordinator submission) before the old key is retired, or submission reverts. Web3Signer can load a replacement key in its store while components keep calling the same endpoint.
  • In the open-source stack, Maru validator keys are mounted as files. Changing that validator key or the validator set requires a coordinated genesis update. When Lineth supplies AWS KMS signing for an enterprise deployment, the validator key lives in the KMS. The local key file is still used for P2P identity.
  • Contract admin keys (DEFAULT_ADMIN_ROLE and related roles) are rotated by granting a new holder and revoking the old one through the deployment's governance or multisig process. See Failure modes and recovery.

For high availability placement, hardware-backed keys that stay in an HSM boundary can be used from more than one region without a new key ceremony.

See also

• Access control: How to restrict access to JSON-RPC, APIs, and tooling.
• Trust and responsibilities: Onchain roles and component trust boundaries.