Architecture
2 subsections
Cerulea supports two primary deployment architectures. Each has distinct validator models, governance structures, infrastructure ownership patterns, and operational characteristics.
| Dimension | Public L1 | Private Chain |
|---|---|---|
| Validator selection | Hybrid onboarding, Proof-of-Stake weighted | Enterprise-selected, fully controlled |
| Participation | Open, permissionless | Permissioned, enterprise-defined |
| Governance | Token-weighted community voting | Authority-based, role-defined |
| Infrastructure ownership | Network participants | Deploying organization |
| Data access | Public visibility | Enterprise-exclusive control |
| Compliance posture | Protocol-governed | Enterprise-configured |
| Upgrade authority | Community governance | Internal governance policy |
Runtime Engine
The Runtime Engine defines how configured systems become executable blockchain environments. Runtime behavior is versioned, every deployment is associated with a specific runtime version that encapsulates how modules behave, how governance is enforced, and how validators interact with the chain.
- WASM-based execution for smart contracts and modules
- EVM compatibility for Solidity-based contracts on Public L1
- On-chain parameter adjustments via governance
- Runtime security sandboxing to prevent unauthorized execution
- Versioned upgrade orchestration with no hard forks required
Cross-Chain and Interoperability
Cross-chain capabilities are defined during the configuration stage. Interoperability is configured, not assumed. For Private Chains, connectivity to the Public L1 is optional and must be explicitly enabled.
- Cross-chain message passing for blockchain-to-blockchain communication
- Asset bridging protocols for secure token transfers between networks
- Private Chain to Public L1 optional connectivity bridge
- Cross-chain transaction validation and finality synchronization
- Standardized cross-chain contract interfaces for compatibility