Permissionless Layer 2

Expanded Definition

A permissionless layer 2 is an execution and scaling network that sits above a base blockchain and allows any participant to interact with it without pre-approval. In practice, the term is used to describe systems that reduce congestion and fees while still relying on the base chain for settlement, dispute resolution, or shared security assumptions.

Definitions vary across vendors and protocol communities on whether a layer 2 is “permissionless” because anyone can submit transactions, anyone can run infrastructure, or anyone can deploy applications. That distinction matters in NHI security because the operational identity model may still be gated even when the network itself is open. For example, a protocol can be permissionless at the user layer while requiring tightly controlled operator keys, sequencer access, bridge admin rights, or contract upgrade roles. The clearest reference point for security expectations remains the broader control logic in OWASP Non-Human Identity Top 10, which maps directly to how infrastructure identities should be constrained and monitored.

In NHI and IAM terms, the term is less about marketing openness and more about who can create, sign, relay, upgrade, or administer actions that move value. The most common misapplication is treating public user access as equivalent to public operational access, which occurs when teams overlook privileged automation, validator roles, and bridge credentials.

Examples and Use Cases

Implementing permissionless layer 2 infrastructure rigorously often introduces governance overhead, requiring organisations to weigh open participation against tighter control of privileged paths and upgrade surfaces.

• A rollup lets any wallet submit transactions, but the sequencer is still operated through a small set of privileged service identities that must be rotated and monitored.
• A bridge contract accepts deposits from the public, yet the admin key that can pause or upgrade it represents a high-value NHI that should be governed like any other production secret.
• A validator or prover set is open for participation, but node automation, signing keys, and API credentials still require lifecycle controls and auditability.
• A protocol team publishes open documentation and code, but deployment pipelines and contract ownership remain restricted to a controlled set of NHI-backed approvals.
• Operational patterns in incidents such as the Microsoft SAS Key Breach show how exposed credentials can turn infrastructure openness into unintended access, even when the platform itself is designed for broad use.

For identity governance, the relevant question is not whether the chain is open, but whether the privileged execution path is discoverable, protected, and revocable. That is why the NHI risk patterns described in Ultimate Guide to NHIs — Key Challenges and Risks apply directly to permissionless systems that depend on secrets, automation, and administrative roles.

Why It Matters in NHI Security

Permissionless layer 2 environments compress the boundary between open network participation and privileged machine action. That creates a familiar NHI failure mode: teams focus on public onboarding, while overlooking service accounts, relayer credentials, treasury keys, and contract ownership. When those identities are over-permissioned or poorly rotated, the blast radius can extend from a single application to the entire network control plane.

This matters because NHI compromise is not rare in real-world operations. NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. Those patterns are especially dangerous in permissionless layer 2 systems where one compromised NHI can alter settlement flows, drain bridge funds, or disrupt upgrades. The control expectations align with NIST SP 800-53 Rev 5 Security and Privacy Controls, particularly around access enforcement, least privilege, and audit logging.

Organisations typically encounter the operational cost only after a bridge exploit, sequencer outage, or key exposure, at which point permissionless layer 2 becomes an incident response and identity recovery problem rather than an architecture choice.

Related resources from NHI Mgmt Group

• When does an independent monitoring layer make sense for Oracle governance?
• When does an independent control layer add more value than native controls?
• How can IAM teams reduce blind spots in multi-layer API architectures?
• Independent Monitoring Layer