Somnia

Validators Can Stuck Forever: If the protocol’s minNodes constraint prevents the committee size from reaching zero, a final validator could become permanently locked in the set, unable to exit or withdraw stake — leaving funds stranded indefinitely if the network ceases operation.

Emergency Risk: The protocol contains multiple emergency and admin-only functions granting owners significant control, including forcibly removing validators, altering staking parameters, and upgrading core contracts. This centralization creates a high governance risk where misuse or compromise of admin keys could disrupt or seize protocol operations.

Single Points of Failure and Control: The project is fully or partially centralized, introducing single points of failure and control. This centralization can lead to vulnerabilities in decision-making and operational processes, making the system more susceptible to targeted attacks or manipulation.

Administrative Key Control Risk: The digital contract architecture relies on administrative keys for critical operations. Centralized control over these keys presents a significant security risk, as compromise or misuse can lead to unauthorized actions or loss of funds.

Flexibility and Risk in Contract Upgrade: The project's contracts are upgradable, allowing the administrator to update the contract logic at any time. While this provides flexibility in addressing issues and evolving the project, it also introduces risks if upgrade processes are not properly managed or secured, potentially allowing for unauthorized changes that could compromise the project's integrity and security.

Single Points of Failure and Control: The project is fully or partially centralized, introducing single points of failure and control. This centralization can lead to vulnerabilities in decision-making and operational processes, making the system more susceptible to targeted attacks or manipulation.

Absence of Time-lock Mechanisms for Critical Operations: Without time-locks on critical operations, there is no buffer to review or revert potentially harmful actions, increasing the risk of rapid exploitation and irreversible changes.

Address Zero as Privileged Super-Admin: The protocol grants critical administrative privileges to address(0) during initialization, including DEFAULT_ADMIN_ROLE and NODE_CALLER_ROLE This unconventional design creates trust assumptions around a non-executable address and restricts legitimate administrative operations to require complex workarounds, while creating potential attack vectors if the privilege model is misunderstood or circumvented.

Epoch Transition Manipulation Risk: The three-phase epoch system (CURRENT → NEXT → FUTURE) relies entirely on internal contract calls without external validation, timing constraints, or decentralized triggers. This design allows entities capable of triggering epoch transitions to manipulate when validator committees rotate and rewards are distributed, potentially disrupting normal committee rotation patterns or favoring specific validators.

Role Privilege Escalation Pathways: The role system creates multiple pathways for privilege escalation through DEFAULT_ADMIN_ROLE ability to grant any role and DEVELOPMENT_ADMIN override capabilities in the custom grantRole() function. The system lacks role hierarchy limits, separation of duties for sensitive role assignments, allowing compromised admin accounts to rapidly expand their privileges.

Economic Parameter Manipulation Through Staking Controls: The protocol allows validators to self-set delegation rates up to 100% while providing admin accounts multiple pathways to create stakes on behalf of others via nodeCallerStakeAndJoinCommittee() and addStakers(). This combination enables privileged accounts to establish favorable economic arrangements or manipulate committee composition through strategic stake allocation without market-based constraints.

Off-chain Consensus to On-chain Execution Verification Gap: The protocol describes requiring 2/3 of committee nodes to sign enshrined transactions, yet the on-chain OnlyNode modifier only verifies msg.sender address(this) without validating that the required consensus threshold was actually achieved. This creates a critical gap where transactions appearing to originate from the contract itself are automatically trusted without cryptographic proof that 2/3 of validators actually agreed to execute them, potentially allowing unauthorized execution of critical functions.

Node Implementation Dependency Risk: Critical protocol operations depend entirely on off-chain node software to "craft transactions" that appear to originate from address(this) or address(0). This architecture creates a single point of failure where vulnerabilities, bugs, or malicious modifications in the node implementation could compromise the entire protocol's security model. The system lacks on-chain validation mechanisms to verify the integrity or authenticity of these crafted transactions, making it dependent on the security of external software components.

Consensus Threshold Enforcement Failure: While the protocol claims to require 2/3 consensus for critical operations, there is no on-chain mechanism to verify this threshold was met before executing functions like finaliseEpoch() or moveToNextEpoch(). The system relies entirely on off-chain coordination and trust that nodes will only sign transactions when appropriate consensus is reached, but provides no cryptographic proof or verification that prevents execution with insufficient consensus or fraudulent signature aggregation.