Node Operation Standard, version 1

BSSC Specification

This Version
https://specs.blockchainssc.org/nos/v1.html
Date
2025-05-13
Editors
Max Courchesne-Mackie (Figment), John Kemp (BSSC)
Contributors
Britton Ballard (Figment), Logan Ballinger (Figment), Joe D'Annolfo (Coinbase), Sky Gul (Kraken), Joel Kerr (Coinbase), Mark Nesbitt (Turnkey), Chaals Nevile (BSSC), Matan Nevo (Fireblocks), Akshar Rawal (Coinbase), Kishore Suri (Coinbase)
Latest Version URL
https://specs.blockchainssc.org/nos/

Copyright ©2025 Blockchain Security Standards Council (BSSC) Inc. All Rights Reserved.

Summary

The Node Operation Standard (NOS) 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 NOS signifies that a node operator adheres to industry best practices and has had their security practices rigorously tested and measured.

The goals of the NOS are as follows:

  1. Present a clear set of security requirements for node operators that ensure a robust level of safety in fulfilling node responsibilities.
  2. Establish a set of requirements that are common across multiple blockchain ecosystems and protocols.
  3. Boost the confidence of consumer and business clients in engaging with node operators for blockchain-related services.
  4. Establish a certification process for the Node Operation Standard that is consistent with many existing network and security audit practices.
  5. 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

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.

This document depends on guidance in two other documents. To conform to these requirements a Node Operator MUST comply with the requirements in the BSSC Key Management Standard, and follow the guidance in the BSSC General Security and Privacy Guidelines.

Taxonomy

A full taxonomy of node types is beyond the scope of this document. However, for the purposes of standardization, we categorize node types as follows. Note that controls have been written broadly to cover a wide variety of different node types. Fitting into this taxonomy exactly is not an explicit requirement for conformance, as this section is informational.

Some nodes, in particular Oracles, 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. Future versions of this specification or other work from the BSSC MAY provide additional, more specific guidance for operating these node types.

Requirement Domains

The Node Operation Standard will cover the following requirement domains. Currently these domains only outline the outcomes of the standard, not the specifics of how each requirement would be audited.

1. Protocol Onboarding

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 requires that operators evaluate the maturity of the blockchain project and implement appropriate risk mitigation strategies to ensure a secure and stable deployment.

  1. A process for protocol selection and risk analysis MUST be documented and followed prior to operating nodes for a new protocol
  2. Software supply chains for all node-related components MUST be assessed, documented, and risk-managed, and follow official sources of software
  3. Procedures MUST be documented and followed for assessing the security of new software packages related to the protocol
  4. The operator MUST understand and document the technical and non-technical responsibilities it has with respect to the protocol
  5. The operator MUST understand and document the intricacies of the protocol such as mechanisms for network upgrades, governance (on-chain, off-chain, or both), voting procedures, killswitches, etc
  6. The operator MUST implement a process that continuously monitors changes to the network and adjusts risk accordingly
  7. The node operator MUST adhere to applicable anti-money laundering and national security address blacklists, or locally established equivalent guidelines, whenever such measures are available
  8. Prior to mainnet deployment, if a protocol testnet is available, the operator SHOULD conduct pilot testing on it; otherwise, the operator MUST use a controlled test network environment to validate the protocol's performance, interoperability, and security posture.

2. Network Participation

This domain requires that nodes strictly adhere to established best practices and network regulations. It emphasizes proactive measures to prevent issues such as slashing and to uphold the overall integrity and reliability of the blockchain network.

  1. 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
  2. Nodes MUST remain on the most recent accepted chain
  3. Nodes that are eligible for rewards MUST receive any form of incentive in accordance with the specific chain’s established protocols, and MUST maintain a verifiable log of all reward or incentive events
  4. Controls to prevent double signing MUST be documented and strictly followed
  5. Controls to prevent slashing or other penalties for non-participation in network duties MUST be documented and strictly followed
  6. The operator MUST maintain boot peers lists to protect against network fragmentation
  7. When discoverability is appropriate, nodes intended to be discoverable SHOULD be configured to allow discovery by other peers, and the operator SHOULD verify and confirm this configuration. Nodes not intended for external discovery MAY be configured to restrict peer discovery
  8. Node operators MUST implement and enforce controls that guarantee the decentralization of the protocol. These controls SHOULD be automated wherever possible and MUST be subject to regular audits and documented reviews to ensure ongoing compliance and effectiveness.
    • 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

3. Resilience and Performance

This domain requires that nodes be designed and managed to quickly recover from failures and adapt to evolving threats. By implementing robust fault-tolerance strategies, documenting and following continuity and failover procedures, and ensuring diverse and distributed deployments, operators can significantly enhance the overall stability and security of the network, thereby reinforcing trust among participants.

  1. Node operators SHOULD strive to deploy a diverse set of client software implementations within their blockchain ecosystem to enhance resilience and mitigate centralization risks. In cases where operational or performance considerations lead to the exclusive use of a particular client, operators SHOULD document the rationale for this decision and periodically assess the impact on overall ecosystem diversity
  2. Continuity and failover procedures MUST be documented and strictly followed to ensure the seamless transition of node operations during downtime events
  3. Processes for monitoring node uptime and remediating detected issues MUST be documented and strictly followed. All remediation actions MUST be recorded to facilitate subsequent audits and ensure compliance with established procedures.
  4. Node operators MUST document and adopt fault-tolerance strategies. Nodes SHOULD be distributed among multiple hosting providers, data centers, and geographic regions.
  5. Protocol-specific procedures for the deployment, recovery, and updating of nodes MUST be thoroughly documented and consistently followed. Any deviations from these documented procedures MUST be promptly reported and remediated.
  6. 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.
  7. Nodes MUST be configured to remain resilient to spikes in activity. Measures implemented to ensure such resilience MUST be documented and subject to periodic audit.

4. Security and Access Control

This domain defines critical measures to protect nodes from unauthorized access and mitigate potential security threats. It also requires the maintenance of comprehensive audit logs to support effective threat hunting and facilitate thorough security investigations.

  1. When supported, remote signers SHOULD be employed to eliminate the need for storing sensitive key material on network-connected nodes. In instances where remote signer support is unavailable, operators MUST implement alternative security controls to safeguard key material
  2. Cross-node communications SHOULD be secured, preferably through encryption or equivalent measures, to mitigate the risk of man-in-the-middle (MITM) and denial-of-service (DoS) attacks. In instances where encryption adversely impacts performance, operators MUST document and conduct a risk assessment
  3. Node logs MUST be recorded and SHOULD be aggregated where feasible. These logs MUST be retained for a period sufficient to enable timely investigation and response to unexpected behaviors, as defined by documented retention policies and procedures.
  4. Logs containing sensitive information, such as cryptographic keys or personally identifiable information (PII), MUST be suppressed, sanitized, or otherwise secured to prevent unauthorized access. Logging systems MUST enforce strict access controls to ensure that any sensitive data is adequately protected
  5. Access to node control planes MUST be restricted to authorized personnel only. Additionally, all access events MUST be comprehensively logged and subject to regular audits to ensure compliance with security policies and detect unauthorized activity.
  6. The network exposure of node clients MUST be minimized to include only the services essential for effective network operation
  7. Security incident response procedures MUST be documented and strictly followed. In the event of a security incident, these procedures MUST be executed to ensure node availability and to facilitate a secure and safe return to operations. Additionally, all incident response activities MUST be logged and audited for compliance with established protocols

5. Transparency

This domain mandates that node operators provide clear and accessible disclosures regarding their operational practices and risk mitigation measures.

  1. Node operators MUST clearly disclose, in an accessible and auditable manner, the scope and terms of any insurance coverage they provide. Such disclosures MUST specifically detail the protections afforded against losses resulting from slashing, downtime, and compromise
  2. Node operators that support pre-signed exit transactions MUST deliver these transactions to clients using a cryptographically secure and confidential communication method. The method SHOULD adhere to industry-standard encryption protocols and ensure that transaction data is protected from unauthorized access or modification

Alignment with other Standards

The Network Participation domain is aligned with other similar node operation standard proposals such as Liquid Collective's Node Operator Risk Standard [NORS], and Lido's Distributed Utilization of Configurations and Knowledge [DUCK] project.

Additionally, some concepts within the Resilience, Performance, and Security and Access Control align with common risk management standards such as [SOC 2] and [ISO 27001].

References

[DUCK]
"Distributed Utilization of Configurations and Knowledge", Lido. https://research.lido.fi/t/d-u-c-k-distributed-utilization-of-configurations-and-knowledge-proposal/5848
[ERC-20]
"ERC-20: Token Standard", F. Vogelsteller and V. Buterin, Ethereum Improvement Proposals 2015. https://eips.ethereum.org/EIPS/eip-20
[ISO 27001]
ISO/IEC 27001 - Information security management systems, ISO. https://www.iso.org/standard/27001
[NORS]
"Node Operator Risk Standard", Liquid Collective. https://docs.nors.global/
[RFC2119]
"Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, IETF 1997. https://www.rfc-editor.org/rfc/rfc2119.html
[RFC8174]
"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", B. Leiba, 2017. https://www.rfc-editor.org/rfc/rfc8174.html
[SOC2]
"SOC 2® - SOC for Service Organizations: Trust Services Criteria", AICPA. https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2

Document Status and Feedback

This document is the BSSC Node Operations Standard, developed by the Technical Working Group of the Blockchain Security Standard Council (BSSC Inc.).

The BSSC requests feedback on this document, which can be provided through our contact form.

The BSSC may publish a new version of this specification, or another specification, that obsoletes this version, in response to feedback received or other developments in the ecosystem.

Disclaimer of Warranty and Liability

NO WARRANTIES: THIS SPECIFICATION IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ACCURACY, COMPLETENESS AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL BSSC, ITS MEMBERS OR ITS CONTRIBUTORS BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THE SPECIFICATION.

THIRD PARTY RIGHTS: Without limiting the generality of the foregoing, BSSC ASSUMES NO RESPONSIBILITY TO COMPILE, CONFIRM, UPDATE OR MAKE PUBLIC ANY THIRD PARTY ASSERTIONS OF PATENT OR OTHER INTELLECTUAL PROPERTY RIGHTS THAT MIGHT NOW OR IN THE FUTURE BE INFRINGED BY AN IMPLEMENTATION OF THE SPECIFICATION IN ITS CURRENT, OR IN ANY FUTURE FORM. IF ANY SUCH RIGHTS ARE DESCRIBED ON THE SPECIFICATION, LICENSOR TAKES NO POSITION AS TO THE VALIDITY OR INVALIDITY OF SUCH ASSERTIONS, OR THAT ALL SUCH ASSERTIONS THAT HAVE OR MAY BE MADE ARE SO LISTED.