Summary
Node operation failures can be very expensive and very visible. As well as node operators losing their stakes, they can cause significant loss of customer funds, as well as serious problems or even failure for the network as a whole.
The Node Operation Standard is a set of requirements that defines the baseline security criteria expected of a blockchain node operator with the goal of enabling clients and third-parties to perform safe and confident integrations. Certification against the Node Operation Standard signifies that a node operator adheres to industry best practices and has had their security practices rigorously tested and measured.
The goals of the Node Operation Standard are as follows:
- Present a clear set of security requirements for node operators that ensure a robust level of safety in fulfilling node responsibilities.
- Establish a set of requirements that are common across multiple blockchain ecosystems and protocols.
- Boost the confidence of consumer and business clients in engaging with node operators for blockchain-related services.
- Establish a certification process for the Node Operation Standard that is consistent with many existing network and security audit practices.
- Define a process for recurring re-certification which can be achieved through self-attestation as long as certain conditions did not change.
Table of Contents
Introduction
Scope
The controls in this specification have been written broadly to cover a wide variety of different node types.
Some nodes, in particular those that host Oracles and Bridges, can be used by other on-chain nodes, while having additional connections outside the blockchain. Such nodes can face additional threats of manipulation and other vulnerabilities, as they are not governed by the same set of incentives.
Some, but not all, of the additional seecurity requirements that are important for such nodes are covered by the BSSC Smart Contract Security Standard [SCSS].
Future versions of this specification or other work from the BSSC MAY provide additional more specific guidance for these node types.
Conformance
The key terms "MUST", "MUST NOT", "SHOULD", and "MAY" in this document MUST be interpreted as described in [RFC2119] as modified by [RFC8174] when they appear in all capitals, as shown here.
Where a requirement refers to document, the relevant documentation MUST be available to all customers of the Node Operator and SHOULD be available publicly without restriction.
Where a requirement refers to provide documentation, auditors MUST review the relevant documentation. Attesting conformance to this specification is an endorsement of the accuracy of such documentation.
Where a requirement refers to equivalent standards or guidelines, attestation of conformance is an explicit endorsement that the relevant specification is an appropriate alternative in the circumstances.
Taxonomy of Node Types
A full taxonomy of node types is beyond the scope of this document. However, for informational purposes, we offer a categorization of node types as follows:
- Consensus Nodes. Nodes that actively participate in the blockchain’s consensus mechanism to propose, validate, or finalize blocks.
- This includes: Validator nodes, Mining nodes, Proof-of-Authority nodes, Masternodes, etc
- Full Nodes and Verification Nodes. Nodes that maintain the state of the blockchain by storing either the full or partial
blockchain ledger and verifying transactions and blocks.
- This includes: Full nodes, Light nodes, Archive nodes, Observer nodes, etc
- Interoperability and Communication Nodes. Nodes that enable interaction between multiple blockchains or provide off-chain data to the blockchain.
- This includes: Relay nodes, Bridge nodes, Oracle nodes, Relayer nodes, etc
- Utility Nodes. Nodes that provide auxiliary services such as decentralized storage, data indexing, or serving as
gateways to the blockchain network
- This includes: Storage nodes, Indexer nodes, etc
Requirement Domains
The Node Operation Standard covers the following requirement domains:
- 0. Basic Security
- 1. Protocol Onboarding
- 2. Network Participation
- 3. Resilience and Performance
- 4. Security and Access Control
- 5. Transparency
Currently these domains only outline the outcomes of the standard, not the specifics of how each requirement would be audited.
0. Basic Security
Security failures that allow malicious actors to compromise a node or a Node Operator pose a financial risk to the users or customers of such nodes, and thus to the reputation of the Node Operator.
This is why Node Operators need basic security hygiene processes in place, as well as meeting requirements more specific to their role as Node Operators.
Manage Key Security
A Node Operator MUST securely manage Keys and
Key material in accordance with the requirements in the BSSC Key Management Standard
or equivalent standards. [KMS]
Implement Standard Security Practices
A Node Operator MUST follow the
guidance in the BSSC General Security and Privacy
Guidelines or an equivalent
standards. [GSP].
1. Protocol Onboarding
Each Protocol is subtly different, even where the underlying systems are the same (such as for EVM-based blockchains). Failure to account for the individual characteristics of a specific blockchain protocol can introduce exploitable vulnerabilities, or lead to operational errors.
Meeting the requirements in this domain ensures that node operators possess comprehensive technical expertise in any new protocol, including a clear understanding of the operational responsibilities, security considerations, and associated risks involved. Additionally, it ensures that operators understand the maturity of the blockchain project and implement appropriate risk mitigation strategies to ensure a secure and stable deployment.
Risk Assessment
Document Protocol Analysis
Node Operators MUST document their process for protocol selection
and risk analysis of a new protocol
Monitor Protocol Changes
Node Operators operator MUST implement a
process that continuously monitors changes to the network and adjusts
risk accordingly
Software Supply Chain
Document Supply Chains
Node Operators MUST provide documentation of software supply
chains, and risk analysis and management for all node-related
components.
Use Official Software Sources
Node Operators MUST follow
official sources of software.
Document Protocol Software Security Assessment
Procedures MUST be
documented and followed for assessing the security of new software
packages related to the protocol
Protocol Assessment
Document Protocol Responsibilities
Node Operators MUST document the technical and non-technical
responsibilities they have with respect to the protocol.
Document Protocol Operation
Node Operators MUST document the operation of the protocol such
as mechanisms for network upgrades, governance (on-chain, off-chain, or
both), voting procedures, killswitches, etc
This is important to demonstrate that the Node Operator actually understands the Protocol, specific risks, and details that are unique to a given protocol.
Test in Controlled
Environments
Node Operator MUST conduct pilot testing in a
controlled test network environment to validate a protocol's
performance, interoperability, and security posture, prior to mainnet
deployment
Best practice is to use official protocol testnets where available and up to date with the protocol.
Compliance
Comply with Applicable Regulation
The node operator MUST adhere to
applicable anti-money laundering and national security address
blacklists, or locally established
equivalent standards or guidelines,
whenever such measures are available
Cryptographic Agility
Document Protocol Cryptography Algorithms
Node Operators MUST document the cryptographic algorithms
employed by the protocol, including signature schemes, hash functions,
and key exchange mechanisms.
Evaluate Protocol Crypto-agility and Post-quantum plans
Node
Operators SHOULD evaluate the protocol's roadmap or capability for
transitioning to quantum-resistant cryptography.
2. Network Participation
Validator failures that incur slashing penalties for a Node Operator and their clients are generally on a permanent public record, representing a reputational risk. Decentralization failures in Node Operations can damage the overall safety of a blockchain Protocol, with consequent effects in market perception. The potential for damage can attract malicious actors who seek to profit from destructive behaviour.
This domain's requirements ensure that nodes strictly adhere to established best practices, and network-specific regulations or conventions. It emphasizes proactive measures to prevent issues such as slashing as well as to uphold the overall integrity and reliability of the blockchain network.
Consensus
Follow Protocol Conventions
Nodes MUST perform all standard
activities — including attesting, executing, proposing, and any other
responsibilities — in strict accordance with the documented best
practices of their respective network.
Follow Protocol Consensus
Nodes MUST remain on the most recent
accepted chain
For nodes that do not produce on-chain attestations (e.g., full nodes, archive nodes), Node Operators SHOULD maintain logs that enable verification of chain-head adherence, such as periodic chain-head comparisons against independent reference sources.
Rewards and Slashing
Follow Reward Conventions
Nodes that are eligible for rewards MUST
receive any form of incentive in accordance with the specific chain’s
established protocols.
Log Protocol
Payments
Node Operators MUST maintain a verifiable log of
all reward or incentive events.
Document Double-signing Controls
Node Operators MUST provide documentation of the controls
they follow to prevent double signing
A particularly important risk arises with failover systems that can lead to double-signing, and thence to a slashing penalty.
Document Anti-slashing Controls
Node Operators MUST provide documentation of the controls
they follow to prevent slashing or other penalties for non-participation
in network dutiesed
Network Topology
Maintain Boot Peers Lists
The node operator MUST maintain boot peers
lists to protect against network fragmentation.
Configure Discovery Appropriately
Nodes intended to be discoverable
SHOULD be configured to allow discovery by other peers.
Verify Discover Configuration
Node Operators SHOULD verify and
confirm the discoverability configuration of all nodes.
Decentralization
Limit Consensus Power
Node operators MUST limit control of
consensus-setting power to support decentralization of the protocol:
- In proof‐of‐work systems, a single entity or group of colluding entities MUST NOT control more than 50% of the network’s total hash power
- In proof‐of‐stake systems, a single entity or group of colluding entities MUST NOT control more than 33% of the total stake
- For components such as bridge validators or analogous critical functions, equivalent decentralization controls MUST be applied
Node Operators MUST include in their calculation of controlled consensus power all validators operated directly, through subsidiaries, through white-label or sub-operator arrangements, or through any entity under common control.
These thresholds reflect the fact that any entity able to marshall a higher proportion of the network decision-making power can single-handedly force consensus, breaking the fundamental security guarantee of the blockchain.
3. Resilience and Performance
Individual nodes failing generally impacts the operators and users of those nodes, however serious cases can impact the overall network as well.
This domain specifies requirements for nodes that enable them to adapt to evolving threats and quickly recover from failures elsewhere in the network, including within the set of nodes managed by a Node Operator. Implementing these requirements can significantly enhance the overall stability and security of the network as well as in their own operation, thereby reinforcing trust among participants.
Client Diversity
Practice Client Diversity
Node operators SHOULD deploy a diverse set of client software implementations where they are available.
Client diversity is important both to ensure overall network robustness, and to ensure that if a given client has a specific bug the Node Operator is not completely compromised.
Balance Client Share
Node Operators SHOULD NOT run any single
client software representing more than 2/3 of their overall
deployment.
Running a super-majority of clients that have a specific bug can exacerbate problems caused by that bug, for the Node Operator, and, if the Node Operator's deployment pattern is common, for the network itself.
Resilience
Document Continuity Process
Node Operators MUST provide documentation of their continuity
and failover procedures.
These processes are necessary to ensure the most seamless transition possible of node operations during downtime events.
A particular risk during failover is that double-signing occurs, leading to slashing. See also Document Double-signing Controls, specifically addressing that risk.
Document Uptime Process
Node Operators MUST provide documentation of processes for monitoring node uptime and remediating detected issues.
Document Fault-tolerance Strategies
Node Operators MUST document fault-tolerance strategies they implement.
Distribute Nodes
Nodes SHOULD be distributed among multiple hosting providers, data centers, and geographic regions.
Software Updates
Document Recovery Procedures
Node Operators MUST provide documentation of the procedures
they follow for the deployment, recovery, and updating of nodes.
Document Procedural Deviations
Node Operators MUST provide documentation of any deviations
from documented procedures for node deployment, recovery, and
update.
Document Cryptography Migration Procedures
Node Operators SHOULD document contingency procedures for
cryptographic migration scenarios, including protocol-level transitions to post-quantum algorithms.
Prepare for Cryptography Migration
Node Operators SHOULD maintain operational readiness to adopt updated cryptographic schemes in
accordance with protocol governance timelines.
Node Capacity
Provision Nodes Sufficiently
Node operators MUST provision nodes with
sufficient hardware and network resources—including, but not limited to,
disk space, disk speed, network speed, and bandwidth—to effectively
perform their designated duties.
Configure Resilient Nodes
Node Operators MUST provide documentation of resilience to
spikes in activity, with relevant measures assessed and if necessary updated at least annually.
Network activity can jump significantly due to events such as a "hard fork" or "network upgrade", or a sudden rush. It is important that Nodes have sufficient capacity to manage this heightened activity effectively.
4. Security and Access Control
Unauthorized access to the keys that secure nodes continue to be a cause of significant financial losses, alongside insufficiently documented security protocols, or failures to implement those protocols in practice.
This domain defines critical measures to protect nodes from unauthorized access and mitigate potential security threats, both through proactive defense, and logging that supports investigation of incidents to identify necessary improvements.
Access Control
Use Remote Signers
Remote signers SHOULD be employed toveliminate the need for storing sensitive key material on
network-connected nodes.
It is important to consider the network configuration for remote signers. If they are on insecure networks, this can introduce a new vulnerability.
Secure Remote Signer Alternatives
Where remote signer support is unavailable, operators MUST implement alternative security controls to
safeguard key material.
Secure Node Communication
Cross-node communications SHOULD be secured.
Best practice is to use encryption or equivalent measures to mitigate the risk of man-in-the-middle (MITM) and denial-of-service (DoS) attacks.
Document Unsecured Channels
Node Operators MUST provide documentation of any instance
where encryption is not used due to an adverse impact on performance, including a risk assessment.
Restrict Control Plane Access
Access to node control planes MUST be restricted to authorized personnel only.
Minimize Network Exposure
The network exposure of node clients MUST be minimized to include only the services essential for effective
network operation
Activity Logging
Retain Logs
Node logs MUST be retained for a minimum of 90 days,
or a longer period where required by applicable regulation or documented
retention policies. Security-relevant logs (access events,
authentication events, configuration changes) SHOULD be retained for at
least 180 days.
Aggregate Logs
Node logs SHOULD be aggregated where feasible.
Do Not Log Sensitive Information
Logs containing sensitive information, such as cryptographic keys or personally identifiable information (PII),
MUST be suppressed, sanitized, or otherwise secured to prevent unauthorized access.
Restrict Log Access
Node Operators MUST enforce strict access controls to logging systems to ensure that any sensitive data is
adequately protected.
Log Access Events
Access events MUST be comprehensively logged and
subject to regular audits to ensure compliance with security policies
and detect unauthorized activity.
Incident Response
Document Incident Response Plans
Node Operators MUST provide documentation of the Security
incident response procedures they follow.
Follow Incident Response Plans
In the event of a security incident, Node
Operators MUST execute documented Incident Response Procedure to ensure
node availability and to facilitate a secure and safe return to
operations.
5. Transparency
Customers cannot make rational choices about Node Operators without clear and accurate disclosure of relevant operational information. Failure to provide the necessary transaparency can bring significant regulatory pressure, as well as expanded legal risk in the event of anything going wrong.
This domain mandates clear and accessible disclosures regarding operational practices and risk mitigation measures, to minimize the exposure of a Node Operator to risks that are taken by their customers.
Document Insurance
Node Operators MUST document the scope and terms of any insurance
coverage they provide. This must specifically detail the protections
afforded against losses resulting from each of
- slashing,
- downtime, and
- compromise.
This requirement ensures transparency, not a mandate for insurance coverage. Where no insurance coverage is provided for one or more loss vectors, documentation MUST clearly state this.
Deliver Exit Transactions Securely
Node operators that support
pre-signed exit transactions MUST deliver these transactions to clients
using a cryptographically secure and confidential communication
method.
Document Exit Procedures
Node Operators MUST document exit procedures including:
- Trigger events, notification procedures and timelines for ceasing operation, and arrangements for outstanding stored transactions
- Unbonding procedures and any penalties for withdrawal or early exit
- Any circumstances that delay exit or withdrawal
Documentation of exit procedures and triggers is important to users both at an individual level in making rational choices, and in enabling better assessments of the overall networks that a Node Operator participates in. Reliable and clear documentation can increase user trust, leading to a "virtuous cycle" of improved stability. Likewise, inadequate or unreliable documentation can significantly reduce trust in a given Node Operator or even in the networks where they participate.
Communicate Securely
Node Operators MUST only use communication methods
that adhere to industry-standard encryption protocols that protect data
from unauthorized access or modification
Document Governance Positions
Node operators participating in
protocol governance MUST document
governance participation policies including:
- criteria for participating (or not) in governance of protocols where the node is deployed,
- criteria for making and evaluating governance proposals,
- voting history where applicable and where disclosure does not create security risks, and
- any conflicts of interest.
Note that abstaining from or not casting a vote where a Node Operator is eligible to do so is governance participation covered by this requirement.