Security Model

Whitepaper

Security Model

The Cerulea security model operates across three distinct layers: architectural, contractual, and cryptographic. Of these, the architectural layer is the most consequential. Architecture cannot be overridden by a policy change, a contractual amendment, or a compromised employee. The design choices described here are not promises. They are the way the system is built.

Architectural Isolation

Private Chain deployments run on isolated infrastructure. This is not a logical separation enforced by access control lists. It is a physical separation. A customer's private chain does not share validator nodes, execution environments, or chain state with any other tenant or with Cerulea Public L1.

The specific guarantees this produces:

  • No shared validator keys across any two deployments
  • No shared execution environment between any two private chains
  • No shared state between a private chain and the public chain
  • A compromised node on one deployment cannot read or affect another customer's chain
Cross-tenant data access is not a misconfiguration risk in Cerulea. It is an architectural impossibility. There is no pathway, authorised or otherwise, by which one tenant's deployment can access another's chain state.

The Metering Layer

The only operational touchpoint between Cerulea's systems and a customer's private chain after deployment is the metering layer. What metering nodes observe is precisely defined and does not change based on deployment tier or contract terms.

Metering nodes observe
  • Block height
  • Block hash
  • Block timestamp
  • Transaction count per block
Metering nodes do not observe
  • Transaction payloads or contents
  • Wallet addresses involved in transactions
  • Smart contract state or stored data
  • Any application-layer data
The metering layer is a billing heartbeat. It confirms the chain is running and counts billable activity. It has no visibility into what those transactions contain. This is a technical constraint built into the metering node design, not a policy commitment subject to future revision.

Validator Key Sovereignty

Validator keys are generated and transferred to the customer at deployment. Cerulea's ongoing operational systems do not require access to validator private keys after this point. There is no workflow within Cerulea's operations that requires the platform to hold or use a customer's validator private key.

For enterprise buyers with a formal requirement for zero-knowledge key ceremonies, this can be arranged as part of the deployment process. The standard deployment flow transfers keys securely. The zero-knowledge variant adds a structured ceremony in which Cerulea personnel have no visibility into the keys at any stage of generation or transfer.

Network Exposure Model

Standard private chain deployments are internet-facing with defined access controls. The default configuration includes:

  • Protected RPC and API endpoints requiring authentication
  • Node-to-node gossip traffic restricted to a defined, customer-controlled peer set
  • API key and IP allowlist controls on all RPC access points
  • Customer-configurable network exposure boundaries

VPN-isolated deployments and private network peering via AWS PrivateLink or Azure Private Link are available for deployments with stricter network isolation requirements. These configurations are handled as custom deployment scope. Organisations that require full network air-gapping or private peering should raise this in the scoping conversation rather than assuming it is included in a standard deployment.

Operational vs. Data Control Boundary

Cerulea manages
  • Deployment orchestration
  • Upgrade management
  • Monitoring surface provisioning
  • Lifecycle control tooling
  • Metering telemetry (block-level only)
Enterprise owns
  • Transaction execution and state
  • Smart contract state
  • Validator key management
  • All enterprise data within the deployed system
  • Network exposure and API access policy
Cerulea does not read transaction payloads, access smart contract state, or control enterprise validator keys. This boundary is enforced architecturally, not by policy.

Compliance Compatibility

Cerulea is framework-agnostic by design. The architecture is built around the technical controls that major compliance frameworks require, without holding certifications against any specific framework at this stage. The structural controls in place are compatible with the technical requirements of GDPR, SOC 2, and ISO 27001:

  • Data isolation at the infrastructure level, not only at the access control level
  • Defined and auditable data boundaries between Cerulea and the enterprise
  • Role-based access control for permissioned participation
  • Immutable audit trails for all governance actions and configuration changes
  • Enterprise-defined compliance rule enforcement at the module level
  • Cross-border governance adaptability for multi-jurisdiction deployments
Cerulea provides the structural controls through which organisations can implement and enforce their own compliance requirements. Cerulea does not provide legal compliance certifications and does not currently hold certifications against any of the frameworks listed above.

Threat Model

The Cerulea architecture is explicitly designed to resist the following attack profiles:

Cross-Tenant Access
Isolated infrastructure with no shared state means an attacker who compromises one deployment cannot read or affect any other customer's chain. There is no shared layer to pivot through.
Unauthorized Chain Manipulation
The DCF consensus mechanism requires validator quorum for any state change. A single compromised validator node cannot rewrite chain state. Quorum requirements are configurable but enforced at the protocol level.
API Abuse
All RPC and REST endpoints require authentication. IP allowlisting and API key controls limit the exposure surface. Unauthenticated access to chain internals is not available in the default configuration.