When a Hyperledger Besu network should use the secp256r1 curve
Besu lets a private network set an alternative elliptic curve through the ecCurve key in the genesis file, choosing between secp256k1, the Ethereum default, and secp256r1. The setting is an early access feature, so treat it as a decision to validate in a test network before any production commitment. The curve governs the cryptographic keys that identify nodes and sign with validator keys, and it is fixed when the network is created: every node in the network must use the same curve, because nodes that disagree cannot exchange messages or verify blocks. Changing it later is not a configuration tweak on individual nodes.
Teams look at secp256r1 because it is the curve used by many hardware security modules and key stores, so a network built on it may fit more naturally with keys that never leave hardware. Confirm this with your HSM vendor and your own key policy before assuming it, since the curves an HSM supports and the signing operations it exposes vary by product. Also confirm which node and validator key operations your chosen Besu version will perform with the curve you set, using the Besu documentation on alternative elliptic curves as the starting point for the exact behavior.
Keep the curve decision separate from the key storage decision. The curve sets the mathematics of the keys, while the hardware path is a different mechanism: Besu documents a security module plugin, such as the Besu HSM plugin enabled with the --security-module option, for holding keys in hardware. Choosing secp256r1 does not by itself place keys in an HSM, and an HSM does not require secp256r1. Before the genesis file is written, record the curve, the HSM product and plugin version you intend to use, and the test you will run to prove that every node and the plugin agree on the same curve.
Choosing between secp256k1 and secp256r1 for a private network
This table compares the two elliptic curves the Besu docs support for private networks, secp256k1 and secp256r1, and what each choice means for planning. Read each row as a decision point: the curve is set once in the genesis file, must match on every node, and sits in an early access feature. The main takeaway is that secp256r1 is a planning decision tied to your key storage, not a default you switch on later.
| Decision point | secp256k1 (Ethereum default) | secp256r1 |
|---|---|---|
| When it fits | Networks that use the standard Ethereum curve and tooling without a hardware key storage requirement | Networks where keys must be held in hardware security modules that support secp256r1 (confirm with your HSM vendor) |
| Status in Besu | Default curve for Ethereum networks, with no early access label in the Besu docs | Early access feature according to the Besu docs, so confirm its maturity before committing |
| Where it is set | Default when no alternative is configured in the genesis file | Set with the ecCurve key in the genesis file of the private network |
| Requirement across nodes | Every node must use the same curve as the rest of the network | Every node must use the same curve, or nodes cannot exchange messages or verify blocks |
| What to check before go-live | Confirm your tooling, wallets and signing libraries expect this curve | Confirm the HSM, the security module plugin and your signing workflow all support secp256r1 for your keys |
| Changing the choice later | Changing away from the default requires the same coordinated genesis change as any curve decision, so plan it before go-live | Switching to or from this curve after a network runs needs a coordinated plan across all operators, so treat it as a day-one choice |
| Key storage implication | Keys can be held in software or in HSMs that support this curve, depending on your vendor | The local node key file is not encrypted by default, so hardware-backed storage through a security module plugin is the main reason to choose this curve |
| Who signs off | Your security and platform teams confirm the curve matches existing standards and integrations | Your security, key management and network teams jointly confirm the HSM path and the early access risk |
Why every node must use the same curve
The curve is a network-wide setting, so every node must load the same value of `ecCurve`. Nodes use the elliptic curve to exchange messages with each other and to verify the blocks they receive. A node configured with a different curve cannot complete those exchanges or validate blocks produced by the rest of the network, so it cannot take part in the chain. This is true whether the mismatch is between two organizations or between two nodes run by the same team. Because the setting lives in the genesis file, a curve decision is effectively a decision about the whole network, and it has to be made before the first validator starts producing blocks.
A mismatch usually appears during onboarding, when a new node is started against the existing network and fails to connect or fails to keep up with the chain. Teams often first suspect peer discovery, firewall rules or a stale bootnode list, so the onboarding runbook should list the genesis curve as an early check. The genesis file also needs to be treated as one shared artifact: a single version held under change control, with a recorded hash, and distributed unchanged to every participating organization. Each member should confirm that the file it runs is byte-for-byte the one agreed in the governance process. Confirm the exact error messages and log lines your Besu version produces in a test network before you write alerts or runbooks around them, since the behavior is best verified in your own environment and not assumed from documentation.
How curve choice changes hardware key storage plans
Choosing secp256r1 changes what your hardware key storage must support, so the curve decision belongs in the HSM plan from the start. The four checks below connect the curve, the Besu security module option and the key types your network depends on.
Confirm curve support in the HSM
Before you commit to secp256r1, ask your HSM or key service vendor whether the device generates, stores and signs with the P-256 curve that Besu uses under the secp256r1 setting. Support for a curve in a general-purpose cryptographic library does not guarantee that the same curve is exposed through the interface Besu's plugin calls. Get the answer in writing, with the firmware or service version it applies to, and confirm it again when the vendor releases updates.
Reach the HSM through the security module
Besu supports hardware-backed key storage through a security module plugin, such as the Besu HSM plugin, enabled with the --security-module option. Your curve decision determines whether the plugin and the device agree on the key type, so test the plugin against the exact curve in your genesis file. Confirm the plugin version is compatible with your Besu release, since plugins are maintained separately from the client.
Separate node keys from signing keys
The node private key that identifies a Besu node on the peer network is stored in a file that Besu does not encrypt, unless a security module holds it. Transaction signing keys for application accounts can be kept outside Besu entirely, in a signing service or HSM, and those keys must use the same curve as the accounts they sign for. Decide which key types move into hardware first, because the node key, validator key and account keys can have different owners and recovery paths.
Test generation and signing before go-live
Run key generation, signing and verification on the exact HSM model, firmware and Besu release planned for production, using a non-production network with the same genesis file. Confirm that signatures produced by the device are accepted by every node, and that blocks and transactions verify across all participants. Record the results as evidence, and repeat the test after any HSM firmware change or Besu upgrade, since curve handling can differ between versions.
Configure secp256r1 on a new private network
This sequence sets one elliptic curve across every node of a new private Besu network before genesis, then confirms the nodes agree on the chain and can produce blocks. It ends with the optional hardware security module wiring for teams whose key storage plan requires it.
Agree the curve across all organizations
Before anyone writes a genesis file, the governance group for the network records in writing which curve it will use, secp256k1 or secp256r1, and who owns each validator and node. Every participating organization should confirm the choice, because a mismatch cannot be repaired after nodes start. Confirm with your Besu version and your key storage vendor that the chosen curve is supported in your environment, since the curve setting is an early access feature. The output is a signed decision record that names the curve and the owner of each node.
Set the ecCurve key in genesis
The network architect adds the ecCurve key to the genesis file and sets it to secp256r1. The key is only read at genesis, so the value must be final before the file is shared. Keep the genesis file under source control so every later change is reviewed and traceable. Check the Besu private network documentation for the exact placement of the key in your consensus configuration. The output is a reviewed genesis file with a single curve value in its committed history.
Distribute identical genesis to every node
The coordinator sends the same genesis file to every operator through an agreed channel and each operator stores it unchanged. Operators should not edit the file to suit local tooling. Each operator computes a hash of the file on their own host and posts it to the coordinator. The check passes when all hashes match exactly, and any difference means the file must be re-sent and recomputed before anyone starts a node. The output is a hash record that every organization has signed off on.
Initialize nodes with the shared genesis
Each operator initializes its Besu node with the shared genesis file and its own node key, using a data directory on a dedicated volume. Record the node identity that Besu reports for each node and keep a copy in the network inventory. Confirm that the node keys are the ones the governance group approved in step one. The check is that each node starts without a genesis error and writes its node identity to its logs. The output is a set of initialized nodes that all reference the same chain definition.
Confirm peering and block production
Start the nodes in the order the consensus design requires and watch the logs for peer connections. Use the metrics endpoint, enabled with the metrics option, to confirm the peer count rises as expected on each node. Then confirm that validators produce blocks and that every node imports the same block hashes at the same height. A node that cannot exchange messages or verify blocks usually indicates a curve or genesis mismatch, so return to step three before changing anything else. The output is a network where all nodes report the same head block hash.
Confirm the curve in node logs
Check each node's startup output and configuration to confirm that it is running with the curve set in genesis, and that no node has a local override. Record the result per node in the network inventory. This check guards against a node that was rebuilt with an older genesis or a different configuration file. The output is a per-node record showing that the curve matches the agreed decision.
Wire the HSM security module plugin
Teams that plan to hold node keys in hardware security modules now install the Besu HSM plugin and start the node with the security module option pointed at it. Confirm with the HSM vendor and the plugin documentation that the device supports the secp256r1 curve before going further. Restart a test node first, confirm it peers and produces blocks with the plugin active, and only then roll the change across the network. The output is nodes that load their signing keys through the HSM and have passed the same peering and block checks as before.
What to do in three common situations
If you are designing a private network from scratch and want HSM-friendly keys, set the curve in the genesis file before the first node starts. The Besu docs describe the ecCurve key as supporting secp256k1 (the Ethereum default) and secp256r1, and they mark it as an early access feature, so treat it as a decision to validate rather than a default to copy. Every node, validator and non-validator alike, must be built from the same genesis with the same curve.
- Confirm feature status first: Check the current Besu docs and release notes for the status of the curve setting before you commit a production design.
- Pin one genesis file: Keep the genesis under source control and deploy the identical file to every node.
- Map key types early: List validator keys, node keys and transaction signing keys, and note which ones the HSM plan will hold.
- Test with a throwaway network: Build a disposable network with the same versions and run block production, peer connections and transactions before go-live.
- Document the decision: Record why secp256r1 was chosen so auditors and future operators understand the trade-off.
Before go-live, confirm that every key type in your HSM plan can be generated, stored and used with the chosen curve in your environment.
If your network already runs on secp256k1 and you are considering secp256r1, the Besu docs support the curve setting in genesis, but a running chain is a different case. Changing the curve on an existing network is not a configuration tweak. Because all nodes must use the same curve to exchange messages or verify blocks, a change affects every participant at once. Do not start this work until you have confirmed the approach with the Besu maintainers and written a full backup plan.
- Confirm with maintainers: Raise the change with the Besu maintainers and get their guidance on whether and how it applies to your chain.
- Back up everything: Capture the genesis file, node keys, configuration and the data directory, and test that you can restore them.
- Plan a coordinated cutover: Every validator and node operator must change at the same time, so agree a schedule and a rollback decision point.
- Check the upgrade path: Confirm the Besu version you run supports the change, and plan any upgrade separately so the two changes are not mixed.
- Rehearse on a copy: Run the full change on a cloned network that matches production before touching the live chain.
Confirm in writing that the maintainers have reviewed your plan and that your restore test has passed before any node is touched.
A network that stays on secp256k1 can still use hardware security modules, provided the HSM protects keys that sit outside Besu's consensus and transport layers. Besu documents a security module plugin, such as the Besu HSM plugin enabled with the --security-module option, for hardware-backed storage. Your first task is to confirm which HSM features your chosen plugin and your HSM support for the secp256k1 curve, since that is the curve your network already uses.
- Separate key roles: Decide which keys are node keys, validator keys and transaction signing keys, because each has different integration needs.
- Confirm curve support: Verify with the HSM vendor and the plugin documentation that secp256k1 signing is supported for each key type you plan to hold.
- Keep the local node key in mind: The Besu docs say the local node private key file is not encrypted, so plan how that file is protected if the HSM does not hold it.
- Test signing paths: Confirm that signed transactions and block production work end to end with the HSM in the path.
- Plan key rotation: Define how keys are rotated and how the validator set changes without interrupting the chain.
Before committing, ask the plugin maintainers and HSM vendor to confirm the exact key types and curve support in writing.
Security considerations for the node key and curve choice
The curve choice sets how every node in the network signs and verifies, so it is also a security decision. The cards below cover where the node key lives, how the genesis file is governed, the risk of an early access feature, how the JSON-RPC and metrics endpoints are protected, and how keys are rotated and recorded with the HSM team.
Node key is unencrypted by default
The Besu docs state that the local node private key file is not encrypted. Anyone who can read that file on the host can act as the node, so file permissions, host access and disk protection matter from day one. Confirm with your security team who can read the data directory and whether the file sits on an encrypted volume. If the key must be protected by hardware, plan for the HSM route rather than relying on file controls alone.
HSM storage through a security module
For hardware-backed key storage, the documented route is a security module plugin such as the Besu HSM plugin, enabled with the --security-module option. Before you commit to this route, confirm that your HSM supports the secp256r1 curve you intend to use, and that the plugin works with the Besu release you plan to run. Test signing and node restart against a non-production network first.
Genesis file under change control
The genesis file defines the ecCurve for the whole network, so every member must hold the same file. Store it in source control with reviewed changes, record the hash agreed by all operators, and reject any node that starts from an unapproved copy. A mismatched curve stops nodes from exchanging messages or verifying blocks, so the change record should show which operators approved each version.
Early access as a change risk
The Besu docs describe the alternative curve setting as an early access feature. Treat that as a change risk: review release notes before each upgrade, test curve-dependent behavior after every Besu version change, and confirm with the maintainers whether the feature is covered by the support terms you need. Build a rollback plan that includes a database backup taken before any upgrade.
Protecting JSON-RPC and metrics endpoints
Besu supports username and password credentials or externally issued JWTs for JSON-RPC authentication, but it does not terminate HTTPS natively. Put a reverse proxy or gateway in front of the API for transport encryption, restrict the metrics endpoint on the default port to your monitoring network, and confirm which methods each client may call. Test these controls with the same node configuration you will use in production.
Key rotation and access records
Agree the rotation process with the HSM team before go-live. Define who can request a new node key, how the replacement is registered in the permissioned network, how the old key is retired, and where each access event is logged. Ask your HSM vendor which audit logs it produces and how long they are retained. Rehearse one rotation on a test network so that the procedure is proven before it is needed.
Questions teams ask before using secp256r1 on Besu
Is secp256r1 the right choice if we plan to use an HSM?
It can be, but the curve choice should follow your HSM vendor's supported algorithms, not the other way around. Besu's documentation describes secp256r1 as an alternative to the Ethereum default secp256k1 for private networks, so a curve your HSM already signs with is the starting point. Confirm with the HSM vendor which curves and signing operations its module supports, and confirm how Besu's security module plugin integrates with that module before you commit. Treat early access status as a reason to validate the full signing path in a test network first.
Can we switch a live network from secp256k1 to secp256r1 later?
Plan on the answer being no, at least not as a simple setting change. The curve is set in the genesis file through the ecCurve key, and every node must use the same curve or nodes cannot exchange messages or verify blocks. Changing it on a running chain therefore means coordinated changes across all operators and usually a new network or a planned migration. Decide the curve before genesis is finalized, and record that decision in your design documents.
What does the work need from our own team?
Your team needs to own the decisions that stay with you: which curve the network uses, which keys sit in hardware, who approves genesis changes, and how node operators coordinate. On the technical side, you need people who can manage genesis files under source control, run Besu nodes and handle key files or HSM access. Engineers should be comfortable testing signing and block validation end to end before go-live. Ask a partner to state which of these tasks it performs and which remain with your staff.
Can an internal team set up secp256r1 on its own?
An internal team with Besu experience can set up a test network with a non-default curve by following the Besu documentation, but the risk sits in the surrounding work. The hard parts are aligning every node's configuration, proving HSM signing works with Besu's plugin, and building a restore and change-control process. Early access status means the documentation may change, so check the current release notes before each build. Teams without prior Besu operations experience usually benefit from a written review of their design.
How do the number of organizations, HSM vendors and change control affect cost and effort?
Effort grows with each organization that runs a node, because every operator must receive the same genesis file, confirm the same curve and test signing with its own key storage. Each additional HSM vendor adds separate integration and testing work. Change control adds time because genesis, key and node configuration changes usually need written approval from every member. These are the main drivers. Ask any provider to break its estimate down by organization, HSM model and approval steps rather than quoting one lump sum.
What should we ask a partner for in a written quote?
Ask for a written scope that lists the curve decision and its rationale, the number of nodes and organizations in scope, the HSM vendor and model, and the Besu version to be used. Request the test plan for signing and block validation, the restore procedure, and the handover documents. Also ask which items are one-time, such as the initial build and HSM integration, and which recur, such as upgrades and support. Confirm who holds keys, who approves changes and how the early access status will be handled if the feature changes. DeployOpen provides quotes based on this written scope.
Does the curve choice change how we back up and recover node keys?
Yes, because the curve determines which keys a node must restore and how they are protected. The Besu documentation notes that the local node private key file is not encrypted, so keys held outside an HSM need separate protection. If keys are held in an HSM, your backup plan must cover how signing access is restored and tested, not just the key file. Confirm with your HSM vendor how key backup and recovery work for the chosen curve, and include restore tests in your resilience evidence.
Limits to confirm in your environment before go-live
The secp256r1 curve is an early access feature in Besu, and its value depends on whether your release, your HSM, your signing libraries and your change policy all agree. Confirm each of the limits below with the people who own that part of the stack before you commit the genesis file.
Early access status
The Besu docs label the ecCurve setting as an early access feature. Ask your change board whether an early access setting is acceptable on a production network, and whether your policy requires a documented exception, a stated support boundary or a rollback plan for features still in early access. Record the answer before the genesis file is finalized, because the curve cannot be changed on a running chain without rebuilding it.
Release support for the setting
Confirm that the Besu release you plan to run supports the ecCurve setting and that the release is one your team will patch on a schedule. Check the release notes for the exact version you select, since support for a feature can change between releases. Ask your Besu vendor or internal platform owner which release is pinned for go-live and who approves moving to the next one.
HSM vendor support for the curve
Ask your HSM vendor whether the device generates, stores and signs with secp256r1 keys in the way your Besu security module plan requires. Confirm which firmware and client library versions carry that support, and whether the key import and export paths you need are included. Do not assume that a device supporting P-256 for TLS or general signing also supports the signing flow Besu uses for node and validator keys.
Wallet and application signing libraries
Every transaction signer in your network must produce signatures on the same curve that the chain expects. Ask the teams that own wallets, payment services and back-office integrations whether their libraries can sign on secp256r1 and whether they can recover addresses from those signatures. A library that defaults to secp256k1 will produce transactions the network cannot verify, so test with signed transactions from each library before go-live.
Third-party tools built for secp256k1
Block explorers, indexers, bridges, custody platforms and monitoring tools often assume secp256k1 and Ethereum address derivation. Inventory every third-party tool that touches the network and ask its vendor whether it supports a non-default curve. Where a tool does not, decide whether to replace it, run it against a separate secp256k1 network, or accept the gap in writing with the business owner.
JDK requirement for the chosen release
Besu requires a specific JDK to build and run, and the requirement changes with the release. Confirm the JDK version your selected Besu release needs, and check that your build pipeline, base images and hardened host packages provide it. Assign ownership for JDK patching, because a JDK change on a validator host is a change to the node, and it should follow the same approval path as a Besu upgrade.
How DeployOpen scopes a secp256r1 Besu deployment
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Besu network that uses secp256r1, we start by confirming the curve decision against your key storage plans, then build and verify every node against one written scope before handover.
How we scope
- We confirm whether the network needs secp256r1 or can stay on the secp256k1 default, based on your key storage requirements.
- The written scope lists every node, the shared genesis file, and the key storage approach for each validator and node.
- We agree in writing which early access limitations apply and how your team will track changes to the feature.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We set the ecCurve value in the genesis file under version control and treat it as a single source of truth for all nodes.
- We test that every node starts with the same curve and can exchange messages and verify blocks before any traffic is allowed.
- We check how the chosen hardware security module plugin signs with secp256r1 keys, using a test network before production.
- We document node key handling, curve settings and rollback steps so your operators can repeat the build without us.
How we hand over
- You receive the genesis file, node configuration, key handling records and a verification report for each node.
- Runbooks cover adding a node with the same curve, restoring from backup and confirming the curve after each upgrade.
- We walk your engineers through the Besu upgrade path, including the backup needed before any database upgrade.
- Handover includes a list of open questions to confirm with your HSM vendor and the Besu maintainers.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer for the network after handover.
- A retainer can cover monitoring of node health, curve consistency checks and review of each new Besu release.
- We can re-run verification when you add nodes, change the HSM or move the network to a new environment.
