# Cambrian Introduction Cambrian is a comprehensive SDK designed to accelerate the development of Node Consensus Networks (NCNs) and Actively Validated Services (AVS) in the Solana ecosystem. Our platform significantly reduces the complexity and time required to build and deploy off-chain computation services with verifiable trust. # Why Cambrian? Building NCNs traditionally requires extensive development time, deep technical expertise, and complex infrastructure management. Developers need to implement consensus mechanisms, establish secure communication channels, and manage distributed storage—all while ensuring robust security and reliability. Cambrian SDK addresses these challenges by providing: * Battle-tested Building Blocks: Pre-built modules for consensus, gossip protocol, and storage * Streamlined Development: Reduce development time from months to days * Developer-First Experience: Focus on your core logic instead of infrastructure complexity * End-to-End Toolkit: From local testing to mainnet deployment # Key Features * Quick Start Templates: Scaffold your NCN project in minutes * Local Development Environment: Test and debug your implementation locally * Deployment Wizard: Guided process for Solana devnet and mainnet deployment * Built-in Monitoring: Track your NCN performance after deployment * Comprehensive Documentation: Step-by-step guides and best practices # Use Cases Cambrian SDK enables rapid development of various off-chain computation services: * AI Oracles and Agents * Zero-Knowledge Co-processors * Trusted Execution Environment (TEE) Services * Cross-chain Communication Networks * Custom Validation Networks # Current Status Cambrian currently supports NCN development for Jito Restaking, with planned expansion to support additional restaking protocols in the Solana ecosystem. Our active developer community and regular updates ensure you're always working with the latest features and security improvements. # Support Join our developer community: * Technical Support: * Developer Chat: * Updates: Let's build the future of decentralized computation together! # Jito Restaking and Vault Program Documentation ## Overview The **Jito Restaking and Vault Programs** manage the relationships between vaults, NCNs (Node Consensus Networks), and operators. The Vault Program is responsible for handling deposits, tokenized stake, and delegation, while the Restaking Program facilitates the interactions between NCNs, operators, and vaults. This documentation provides an in-depth look at the components and interactions between these entities, as represented by the following diagrams. ## 1. Vault Program and Restaking Program Interaction {% @mermaid/diagram content="flowchart LR ``` classDef main fill:#AAA,stroke:#333,stroke-width:2px; classDef ticket fill:#595,stroke:#333,stroke-width:1px,font-size:10; subgraph Vault Program Vault(Vault):::main VaultNcnTicket([VaultNcnTicket]):::ticket end subgraph Restaking Program NCN(NCN):::main NcnVaultTicket([NcnVaultTicket]):::ticket end %% Vault Program Links Vault -->|Creates| VaultNcnTicket VaultNcnTicket -->|Activated through warmup| NCN VaultNcnTicket -.->|Deactivated through cooldown| NCN %% Restaking Program Links NCN -->|Creates| NcnVaultTicket NcnVaultTicket ---> |Links| Vault" %} ``` ### Explanation * The **Vault Program** creates `VaultNcnTicket` to signify its support for an NCN. * The **VaultNcnTicket** undergoes a warmup process to activate and a cooldown process to deactivate. * The **Restaking Program** creates `NcnVaultTicket` to formalize the link between an NCN and a vault. ## 2. NCN and Operator Mutual Opt-in Process {% @mermaid/diagram content="flowchart LR ``` classDef main fill:#AAA,stroke:#333,stroke-width:2px; classDef ticket fill:#595,stroke:#333,stroke-width:1px,font-size:10; subgraph Restaking Program NCN[NCN]:::main Operator[Operator]:::main NcnOperatorState[NcnOperatorState]:::ticket end NCN -->|Registers| NcnOperatorState Operator -->|Opts in| NcnOperatorState NcnOperatorState -->|Mutual opt-in| Operator" %} ``` ### Explanation * The **NCN** registers an `NcnOperatorState` account to track opt-ins. * The **Operator** opts into the NCN, signifying agreement. * Both entities must mutually opt-in to establish a valid state. ## 3. Vault Delegation to Operators {% @mermaid/diagram content="flowchart LR ``` classDef main fill:#AAA,stroke:#333,stroke-width:2px; classDef ticket fill:#595,stroke:#333,stroke-width:1px,font-size:10; subgraph Vault Program Vault[Vault]:::main VaultOperatorDelegation[VaultOperatorDelegation]:::ticket end subgraph Restaking Program Operator[Operator]:::main OperatorVaultTicket[OperatorVaultTicket]:::ticket end %% Vault Program Links Vault -->|Creates| VaultOperatorDelegation VaultOperatorDelegation -->|Delegates stake| Operator %% Restaking Program Links Operator -->|Creates| OperatorVaultTicket OperatorVaultTicket -->|Links| Vault %%%% Cross-Program Links Vault -.->|Opts in| Operator Vault -.->|Delegates stake to| Operator" %} ``` ### Explanation * The **Vault Program** creates `VaultOperatorDelegation` to delegate stake to an operator. * The **Restaking Program** creates `OperatorVaultTicket` to formalize the connection. * The vault must explicitly opt-in to the operator before delegation occurs. # Proof-of-Authority (PoA) Program Documentation ## Overview The PoA (Proof-of-Authority) Program is a Solana-based smart contract that allows registered Jito operators to execute specific on-chain instructions known as *proposals*. The execution of these proposals is subject to certain conditions, primarily that: 1. The signer must be a **Jito operator** registered in an **NCN** (Node Coordination Network) linked to the PoA state. 2. The operator must have a sufficient amount of delegated **stake**. 3. The proposal can only be executed once *enough* operators (as defined by the `threshold` in the `PoAState` account) have approved it. This program is tightly integrated with the **Jito Restaking Program** and the **Vault Program**, ensuring that only valid, staked operators can authorize execution. ## Architecture {% @mermaid/diagram content="flowchart BT ``` classDef main fill:#AAA,stroke:#333,stroke-width:2px; classDef ticket fill:#595,stroke:#333,stroke-width:1px,font-size:10; classDef function fill:#FFD700,stroke:#333,stroke-width:2px, font-weight:bold; classDef check fill:#FF6347,stroke:#333,stroke-width:1px,font-size:10; classDef storage fill:#87CEFA,stroke:#333,stroke-width:1px,font-size:10; subgraph Restaking Program NCN[NCN]:::main Operator[Operator]:::main NcnOperatorState[NcnOperatorState]:::ticket end subgraph Vault Program Vault[Vault]:::main VaultOperatorDelegation[VaultOperatorDelegation]:::ticket end subgraph PoA Program PoAState[PoAState]:::main HandleProposal([handle_proposal]):::function end ``` %% Vault Program Links Vault -->|Delegates stake| VaultOperatorDelegation VaultOperatorDelegation -->|Tracks delegation| Operator %% Restaking Program Links NCN -->|Registers| NcnOperatorState Operator -->|Opts in| NcnOperatorState %% Cross-Program Links Vault -.-> |Referenced supported token in| PoAState NCN -.-> |Referenced in| PoAState %% Jito Account Verification inside handle\_proposal HandleProposal -.->|Checks Delegation| VaultOperatorDelegation HandleProposal -.->|Checks Operator in NCN| NcnOperatorState HandleProposal -.->|Checks Vault & Operator| Vault HandleProposal -.->|Checks PoA threshold| PoAState" %} ## PoA State Account The `PoAState` account holds the configuration parameters that define how the PoA program operates. It includes: * `threshold` → The minimum number of operators required to approve a proposal before execution. * `admin` → The administrator of the PoA program. * `ncn` → The associated **NCN** that determines valid operators. * `supported_token` → The token that must be **staked** by operators to gain execution rights. * `stake_threshold` → The **minimum stake** required for an operator to participate in PoA. ## Proposal Execution Workflow 1. **Operator Calls `handle_proposal`** * The Jito operator initiates execution by calling `handle_proposal`. 2. **Verification Process:** * The program verifies that: * The **operator is registered** in the relevant NCN (`NcnOperatorState`). * The **operator has enough delegated stake** (`VaultOperatorDelegation`). * The **vault and operator match expected values**. * The **operator is part of the PoA program**. 3. **Tracking Approvals:** * The proposal remains **pending execution** until *enough* operators (determined by `threshold`) approve it. * Each operator approval is tracked. 4. **Proposal Execution:** * Once the required number of approvals is reached, the proposal is executed. * The execution may involve calling various Solana instructions. This ensures that no single operator has unilateral control, reinforcing decentralization and security. # Cambrian CLI ## Prerequisites * node.js >= 22.0.0 * docker >= 20.0.0 ## Installing Cambrian utility ``` npm i --global @cambrianone/camb-client@latest ``` ## Initialization {% @mermaid/diagram content="flowchart TB subgraph Offchain avs\[AVS] ``` subgraph Operators operator1[Operator1] operator2[Operator2] operator3[Operator3] end end subgraph Onchain poa[Cambrian PoA program] oracle[Cambrian Oracle program] jito-restaking[Jito Restaking program] jito-vault[Jito Vault program] end cli["Cambrian CLI utility"] cli --> |1.1 Scaffolds AVS| avs cli --> |1.2 Scaffolds Operators| Operators cli --> |1.3 Initializes PoA and operators onchain| Onchain" %} ``` ### Scaffold AVS and initialize PoA onchain ```bash camb init -t avs ``` Explaining wizard: * `Enter AVS IP address to bind to` - provide an IP address to bind to, it should be reachable from all the operators * `Enter AVS HTTP port to bind to` - provide an HTTP port to bind to, it should be reachable from all the operators * `Enter AVS WS port to bind to` - provide a WebSockers port to bind to, it should be reachable from all the operators * `Enter admin private key or press enter to generate a new one` - admin private key / keypair as array of `uint8` or as base58-encoded string * `Enter Solana API URL or press enter to use default` - Solana JSON RPC endpoint * `Enter Solana API WS URL or press enter to use default` - Solana WebSockets endpoint * `Enter Cambrian Consensus Program name or press enter to generate a new one` - string identifier (name) of the Cambrian Consensus Program (CCP) instance (aka PoA name) * `Enter proposal storage key or press enter to generate a new one` - unique string key for the proposal storage * `Enter storage space` - common oracle storage space, in bytes * `Enter consensus threshold` - The minimum number of operators required to approve a proposal before execution * `Enter stake threshold` - The **minimum stake** required for an operator to participate in CCP ### List installed AVS instances ```bash camb avs list ``` ### Start AVS: ```bash camb avs run -u ``` AVS is stated for: * Distributing payload between the operators * Checking vault state and it's updating when needed (once in an epoch) ### Scaffold operators and initialize them onchain #### Scaffolding operators Before scaffolding the operators make sure instance of AVS is already running. ```bash camb init -t operator camb init -t operator camb init -t operator ``` Explaining wizard: * `Enter AVS HTTP URL` - AVS HTTP endpoint * `Enter AVS WS URL` - AVS WebSockets endpoint After initialization of AVS and operators you can optionally add an external service to run it alongside with AVS or operator instances: ```bash camb manage add-external -n -p -i [-e ] ``` This command will create a boilerplate section for external service in AVS/operator docker-compose file. You can customize it later. ## Running components {% @mermaid/diagram content="flowchart TB subgraph Offchain avs\[AVS] ``` subgraph Operators operator1[Operator1] operator2[Operator2] operator3[Operator3] end end subgraph Onchain poa[Cambrian PoA program] oracle[Cambrian Oracle program] jito-restaking[Jito Restaking program] jito-vault[Jito Vault program] end cli["Cambrian CLI utility"] cli --> |2.1 Starts AVS| avs cli --> |2.2 Starts Operators| Operators " %} ``` ### List installed operator nodes (outputs voter public keys) ```bash camb operator list -a ``` ### Start operators: ```bash camb operator run -u ``` Each operator waits for the command from the AVS to store data to oracle storage and execute the proposal. ## Executing proposal {% @mermaid/diagram content="flowchart TB subgraph Offchain avs\[AVS] ``` subgraph Operators operator1[Operator1] operator2[Operator2] operator3[Operator3] payload-container1([Payload Container]) payload-container2([Payload Container]) payload-container3([Payload Container]) end end subgraph Onchain poa[Cambrian PoA program] oracle[Cambrian Oracle program] jito-restaking[Jito Restaking program] jito-vault[Jito Vault program] end cli["Cambrian CLI utility"] cli --> |3.1 Sends name of payload container image to AVS| avs avs --> |3.2 Broadcasts name of payload container image to Operators| Operators operator1 --> |3.3 Starts container| payload-container1 payload-container1 --> |3.4 Returns oracle data and proposal instructions| operator1 operator2 --> |3.3 Starts container| payload-container2 payload-container2 --> |3.4 Returns oracle data and proposal instructions| operator2 operator3 --> |3.3 Starts container| payload-container3 payload-container3 --> |3.4 Returns oracle data and proposal instructions| operator3 Operators --> |3.5 Store data to oracle storage| oracle Operators --> |3.6 Send proposal instructions| poa" %} ``` ### Running payload Payload container holds data for oracle storage and execution instructions for the proposal. Container receives a parameter (in `CAMB_MVP` environment variable) serialized as JSON-object. It's type is: ```typescript type TPayloadInput = { executorPDA?: string; apiUrl?: string; extraSigners?: Array; poaName: string; proposalStorageKey: string; } ``` `extraSigners` represents an optional array of serialized private keys used for signing transaction. Container should write a JSON-stringified object.\ It's type is: ```typescript type TPayloadOutput = { proposalInstructions: Array<{ accounts: Array<{ address: string; role: 0 | 1 | 2 | 3 }>, data: string; programAddress: string; }>; storagePayload: | { encoding: 'utf-8'; data: string } | { encoding: 'bytes'; data: number[] } | { encoding: 'base58'; data: string } | { encoding: 'base64'; data: string }; } ``` where proposal instructions `data` is base58-serialized data (or array of uint8) buffer and account `role` is the following enum: ```typescript enum AccountRole { // Bitflag guide: is signer ⌄⌄ is writable WRITABLE_SIGNER = /* 3 */ 0b11, READONLY_SIGNER = /* 2 */ 0b10, WRITABLE = /* 1 */ 0b01, READONLY = /* 0 */ 0b00, } ``` This type could be represented as JSON-schema: ```json { "$schema": "http://json-schema.org/draft-07/schema#", "title": "TPayloadOutput", "type": "object", "properties": { "proposalInstructions": { "type": "array", "items": { "type": "object", "properties": { "accounts": { "type": "array", "items": { "type": "object", "properties": { "address": { "type": "string", "description": "Account address" }, "role": { "type": "integer", "enum": [0, 1, 2, 3], "description": "Account role as bitflag (is signer | is writable)\n\n0 (0b00): READONLY\n1 (0b01): WRITABLE\n2 (0b10): READONLY_SIGNER\n3 (0b11): WRITABLE_SIGNER" } }, "required": ["address", "role"], "additionalProperties": false }, "description": "Array of accounts involved in the instruction" }, "data": { "type": "string", "description": "Instruction data as base58 encoded string" }, "programAddress": { "type": "string", "description": "Program address for the instruction" } }, "required": ["accounts", "data", "programAddress"], "additionalProperties": false }, "description": "Array of proposal instructions" } }, "storagePayload": { "oneOf": [ { "type": "object", "properties": { "encoding": { "const": "utf-8" }, "data": { "type": "string" } }, "required": ["encoding", "data"], "additionalProperties": false }, { "type": "object", "properties": { "encoding": { "const": "bytes" }, "data": { "type": "array", "items": { "type": "number" } } }, "required": ["encoding", "data"], "additionalProperties": false }, { "type": "object", "properties": { "encoding": { "const": "base58" }, "data": { "type": "string" } }, "required": ["encoding", "data"], "additionalProperties": false }, { "type": "object", "properties": { "encoding": { "const": "base64" }, "data": { "type": "string" } }, "required": ["encoding", "data"], "additionalProperties": false } ] }, "required": ["proposalInstructions", "storagePayload"], "additionalProperties": false } ``` Example of running payload container: ```bash $ docker run --rm -e CAMB_INPUT='{"poaName": "test", "proposalStorageKey": "test"}' check-oracle | jq . { "proposalInstructions": [ { "programAddress": "ECb6jyKXDTE8NjVjsKgNpjSjcv4h2E7JQ42yKqWihBQE", "accounts": [ { "address": "Qrszp1YM5zEW38JgHPMQVedeZ3A14HmaanB3z65d8Ps", "role": 1 }, { "address": "ExLXdCbiXhdmRw3MzmNFGPexCgSuoRpC3YTnGQ6dNekP", "role": 0 }, { "address": "Sysvar1nstructions1111111111111111111111111", "role": 0 }, { "address": "ECb6jyKXDTE8NjVjsKgNpjSjcv4h2E7JQ42yKqWihBQE", "role": 0 } ], "data": "EmqjS8fy7HCvpUiTJqJxGB" } ], "storagePayload": { "encoding": "utf-8", "data": "Local time: 1746009154987" } } ``` ### Build payload container image ```bash git clone https://github.com/cambrianone/payload-images cd ./payload-images/check-oracle docker build -t payload-check-oracle . ``` ### Run payload Send image name of payload container from the previous step (`payload-check-oracle`) to the AVS instance ```bash camb payload run-container -a -p [period in seconds] payload-check-oracle ``` * AVS broadcasts payload container image name to running operators * Operators run payload containers * Payload containers return data to store in oracle storage and proposal instructions * Operators invoke `store_to_storage` instruction in PoA program to store data in oracle storage * Operators invoke `handle_proposal` instruction in PoA program with proposal instructions # Abstract General principles and background of Cambrian ### Monolithic vs modular architecture Modular versus integrated is perhaps the most debated topic in the field of distributed system design today. This approach can be compared to the implementation of monolithic and microservice architecture in system design. In microservice architecture the code is divided into separate modules, each function has a separate service. Each software component is designed for a specific function and developers can use separate technology stacks for each service and separate microservices to support separate operations. Also, each service can be deployed, scaled and updated independently, enabling continuous integration and continuous delivery (CI/CD), which is also applicable to the modular architecture that Cambrian's approach enables.
It can be debated as to whether in the long term the modular approach or the integrated one emerge dominant, what’s clear is that in the foreseeable future they coexist. As curious builders, we often wonder whether there are learnings Solana can take from Ethereum and vice-versa. ### Why there is a need to launch Cambrian Few deny the fact that both Ethereum and Solana house capable, independent-thinking devs and researchers. Thus, beyond tribalism, it makes sense to question why they work on the areas they do. Ethereum, after all, started as the world’s super computer. However, even a super computer can’t power a single popular web service, let alone a decentralized network. Memory accesses and bandwidth bottlenecks make sharded designs more efficient for large-scale applications. This became crystal clear with the recent congestion on Solana. Even then, the current upper limit of 12m CUs only allows 4 popular apps to exist simultaneously before hitting the 48m block limit. There are diminishing returns to what can be achieved w more hardware. Increasing the number of cores doesn’t linearly increase parallelizability. New compute networks like, AI projects , onchain games may prefer Solana’s practicality-first approach but might want to use new design patterns like the coprocessors. We believe modularity is the key to composability. Cambrian gives applications the flexibility they deserve. It strengthens $SOL's position as an Internet money and allows us to combine vertical scaling with horizontal computing and data segmentation. ### **Bootstrapping security of decentralized networks** A range of new sectors including zero-knowledge cryptography, dePIN, artificial intelligence and machine learning have been gaining momentum over the past year. However, all these technologies require professional players (relayers / validators / proovers) who solve tasks specialized for these projects. And we are facing one of the key limitations for the growth of the ecosystem – bootstrapping new middleware networks. Launching new networks is one of the key and difficult tasks in the development of any on-chain project. Why? Every network is facing the “[cold start problem](https://breadcrumb.vc/when-networks-meet-saas-f4307bf3b296)”: gaining users makes the product more useful and sustainable both for validators and other users. But on day 0, there are no paying users on the network and, accordingly, there is no utility for validators. And if there are no reliable validators, then users do not have trust in such a network. This chicken-egg problem usually has been solved by incentivizing early network participants. *`The basic idea is: Early on during the bootstrapping phase when network effects haven’t kicked in, provide users with financial utility via token rewards to make up for the lack of native utility.`*` ``- Chris Dixon (`[`a16z`](https://a16zcrypto.com/posts/article/the-web3-playbook-using-token-incentives-to-bootstrap-new-networks/)`)`
**Cons of low-trust middleware which creates barriers for innovations:**\ \- Middleware: high cost of capital\ \- dApps: low trust model\ \- SOL: low-trusted dApps lower trust in Solana ecosystem, security standards are not unanimous **Pros of sharing trust with SOL:**\ \- Middleware: zero-margin cost of capital, no bottleneck\ \- dApps: higher core trust from SOL holders and stakers\ \- SOL: value alignment from new innovations contributing back value to SOL ecosystem and holders It may seem that the problem is solved. However, early-stage networks’ token is extremely volatile by nature and has weak distribution which makes such networks easy targets for attacks. Another problem that projects are facing during the early distribution period is the death spiral; when a drop in the price of a token reduces the interest of users & validators, making the network less secure and, as a result, even less interesting for participants. An option is launching a curated model ([progressive decentralization playbook](https://variant.fund/articles/progressive-decentralization-a-playbook-for-building/)), though it also has its own drawbacks: often such decisions lead to the fact that the network remains locked in the hands of the team, never achieving the required level of decentralization. # What is Cambrian Cambrian’s idea of a modular security layer was inspired by Eigenlayer’s success in the Ethereum ecosystem. However, despite the ideological similarity, the architecture of the solution is fundamentally different due to the different nature of the Solana blockchain from Ethereum: 1. Completely different stack: it is impossible to make compatible EVM and SVM applications. Though there is a solution to run EVM bytecode on top of SVM (see [Neon](https://neonevm.org/)’s implementation for details), it does not allow you to use the full capabilities of the Solana blockchain. 2. Solana uses parallel processing in contrast to consecutive Ethereum’s execution, which makes the transaction lifecycle quite different. These differences should be taken into account when designing consensus and slashing mechanisms in different AVS use cases. 3. Different block building mechanics require different approaches to providing and validating data. 4. Solana offers a vertical approach with a high TPS, in contrast to the rollup-centric model of Ethereum. As a result, completely different use cases are relevant (for example, those focused on HFT trading infrastructure). It is also worth noting the benefit that the entire Solana ecosystem receives from the presence of a modular security layer: dApps leverage trust from consensus layer to construct services for their end users. The equation is simple: simplification of bootstrapping security leads to more innovations for the ecosystem overall, more innovation leads to more users, which in turn builds more trust.
Cambrian creates a novel market for decentralized trust based on the existing Solana consensus turning the capital used for network security into an asset that can be used for other modular networks and middlewares. The model incorporates a restaking mechanism, offering enhanced fee-generating opportunities for both validators and SOL holders. This approach aims to improve features and security of the networks and enrich engagement and financial incentives within the Solana chain. # What is Restaking ### Why restaking may be necessary As we mentioned in the previous Abstract section, one of the prerequisites for the emergence of restaking is Bootstrapping security of decentralised networks. Normally, if a developer has an idea for some smart contract application, he can run it on top of Ethereum, Solana and other large blockchain networks and L2, observe the usage, modify and scale further. But in this case, it's all about consensus mechanisms, which are hard-coded at the L1/L2 level. You can try to find an L1/L2 that fits certain requirements, but there is a problem of Core devs supporting the technology, its security in terms of economic security, fragmentation of solutions and liquidity. As a result, if a developer needs some special mechanics and consensus mechanism - he comes to the point that he needs to start his own L1. And launching own L1 means that the creator needs to create own token, attract node operators and incentivise them to stay in the chain and cover costs, build own ecosystem to increase economic incentives. In the end, we come again to a fragmentation of liquidity and technical solutions, with different proprietary technologies and mechanisms, of which there are already so many, and many of which are being left behind by the rapid development of Web3. In addition, bootstrapping and attracting new projects and liquidity is becoming more difficult as Ethereum, Solana and other L1s develop, which have a lot of credibility due to the large amount of staked funds and validators among other things. Therefore, this all leads to the idea of delegating economic security to increase the flexibility, customization, protection and reliability of the consensus.
# Solana General Overview Solana is a blockchain built for mass adoption. It's a high performance network that is utilized for a range of use cases, including finance, NFTs, payments, and gaming. Solana operates as a single global state machine, and is open, interoperable and decentralized. Solana is an open source project implementing a new, high-performance, permissionless blockchain. ### Why Solana? It is possible for a centralized database to process 710,000 transactions per second on a standard gigabit network if the transactions are, on average, no more than 176 bytes. A centralized database can also replicate itself and maintain high availability without significantly compromising that transaction rate using the distributed system technique known as Optimistic Concurrency Control [\[H.T.Kung, J.T.Robinson (1981)\]](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.65.4735). And Solana demonstrates that these same theoretical limits apply just as well to blockchain on an adversarial network. The key ingredient? Finding a way to share time when nodes cannot rely upon one another. Furthermore, the architecture supports safe, concurrent execution of programs authored in general-purpose programming languages such as C or Rust. ### What is a Solana Cluster? A cluster is a set of computers that work together and can be viewed from the outside as a single system. A Solana cluster is a set of independently owned computers working together (and sometimes against each other) to verify the output of untrusted, user-submitted programs. A Solana cluster can be utilized any time a user wants to preserve an immutable record of events in time or programmatic interpretations of those events. One use is to track which of the computers did meaningful work to keep the cluster running. Another use might be to track the possession of real-world assets. In each case, the cluster produces a record of events called the ledger. It will be preserved for the lifetime of the cluster. As long as someone somewhere in the world maintains a copy of the ledger, the output of its programs (which may contain a record of who possesses what) will forever be reproducible, independent of the organization that launched it. ### What are SOLs? A SOL is the name of Solana's native token, which can be passed to nodes in a Solana cluster in exchange for running an on-chain program or validating its output. The system may perform micro-payments of fractional SOLs, which are called *lamports*. They are named in honor of Solana's biggest technical influence, [Leslie Lamport](https://en.wikipedia.org/wiki/Leslie_Lamport). A lamport has a value of 0.000000001 SOL. You can explore Solana's operating principles and architecture in more detail and granularity in the documentation: # Usecases At Cambrian, we believe in use cases for the mass market and healthy organic co-evolution. However, with the continuous growth in activity and user base, there's a constant need for additional functionality and the ability to scale rapidly. Scaling Solana with the modular shared security approach, in our opinion, is the most optimal way to retain or directly delegate users and liquidity within Solana itself as well as for the impetus for a new round of crypto industry evolution with the emergence of technologies, mechanics and usage scenarios that were previously unavailable. At the current moment of web3 development, we can distinguish the following usecases: * **General decentralized networks:** oracles, network keepers, automation. * **Coprocessors:** Decentralized and economically efficient AI output through economic security, private database information retrieval, zk-coprocessors through verification marketplaces, DeFi circuit breakers * **Creating narrow use cases to suit the needs of individual customers:** for example, this could be running Middleware with specific requirements such as the ability to partially encrypt transactions and smart contracts with separation into public and private parts. This could be applicable for financial applications, creating MEV-resistance, and even for gaming (creating fog of war, card games). * **DePin:** Bootstrapping validation networks for complex DePIN infrastructure for usecases with any types of computations, which significantly reduces the cost of creating your own chain and may allow you to compete more effectively with web2 projects in this area.. * **Cryptography:** Threshold FHE, MPC, TEE committees - this opens up a wide range of possibilities, including the creation of permissioned bridges with economically secure validator sets. * **MEV Management:** Auction, private RPCs, conditional trades
Thus, Cambrian uniquely enables DAs, shared sequencers, social/gaming appchains and DePIN networks to bootstrap their economic security through SOL restakers. It attempts to not compromise Solana security by ensuring that slashable events remain uncorrelated and independent. In addition, we would like to mention that a shared modular security model from Cambrian could accelerate a lot of appchain specific use cases by helping to bootstrap validation networks for [Solana Permissioned Environments](https://solana.com/news/solana-permissioned-environments-spe-introduction). # Cambrian Architecture and Workflow Cambrian's general principles of organisation, components and workflow ### General Cambrian Architecture At a basic level, the Cambrian architecture consists of several smart-contracts and modules that manage the interactions between protocol participants to ensure smooth and seamless operation.
* **PoolManager** — part that works with user’s assets, tokens whitelist, mint and burn cSOL, deposit and withdrawal funds. * **WorkerManager** — part that manager system workers (node operators), enrols and delists them. The workers or nodes make up the AVS * **AVSManager** — part that manages AVS enrollment and exit, as well as their accounting. * **StakingManager** — staking implementation, it’s also the first part of a slashing system, that coordinates stake and determines what should be slashed. There is also a module for slashing as part of StakingManager. The principles of how slashing works are described in the "AVS Overview" section ### Cambrian participants and components: * **Operators** are those who manage Solana nodes and related nodes in Cambrian and offer their services to AVS developers where different products can be run. Operators are somewhat similar to validators, but instead of validating blocks on an independent blockchain network, they validate and maintain actively validated services (AVS) that represent different types of services. For providing capacity for AVS, they receive rewards from the protocols. * **Restakers** - they can both delegate directly to SOL operators for restaking, and can restake LSTs such as mSOL, scnSOL, jSOL and others * **AVS** - Actively Validated Services that are verified by operators and used as the basis for Middleware, which developers can configure to their needs. * **Middleware** are services/applications/protocols running on top of individual AVSes. Middleware developers pay fees to operators to maintain the infrastructure (more about this in the section "AVS Reward Model"). * **Endusers** - users, which can be individuals, organisations or applications that use products (Middlewares) built on top of AVSes. * **Workers** - Workers is another name for the operators of the individual nodes or clusters that make up the AVS for running Middleware and whose behaviour logic is managed by the WorkerManager. ### Main workflow: Firstly, users (stakers), workers, and AVSs register in the system, depositing their funds into specific accounts through PoolManager and WorkerManager, linking AVS nodes with Solana nodes, completing the initial system setup. Then, suppose AVS node operators receive messages instructing them to perform a certain amount of work for a particular AVS. In that case, they can participate in the validation of that AVS depending on the proposed conditions. Similar to servers in AWS, AVS nodes can be of various general-purpose types depending on power, memory, bandwidth, and geographical location, as well as offering specific features like increased RAM, GPU, and storage volume. After initialization, the following processes occur within Cambrian: * It checks if the necessary number of nodes with the required power from workers (operators) with the specified token amount in restaking is available. * It checks if the given AVS has enough collateral contributions to pay for its work and ensure good behavior. * If both verification steps are successful, Cambrian schedules the workload for the workers. * After all workers complete their workload, Cambrian verifies the result using the consensus mechanism. * If the answer is satisfactory, it is passed on-chain. Those employees (operators), who gave normal results and perform their work smoothly and in good faith, receive rewards depending on the proposed conditions. And those workers (operators) who could not perform their work well (low uptime, unscrupulous behaviour) get slashing (more about this in the "Slashing" section). Thus, this process appears fairly straightforward, but it is the core that enables the restaking process to function and forms a novel market for shared security. ### Middleware: Middleware is a term that refers to a layer or complex of technology software to enable interoperability between different applications, systems, components. Currently, many dApps rely on additional services that Solana Validators and the Solana Virtual Machine (SVM) cannot provide directly. These required components are known as Middleware. Overall trust in these services is inextricably linked to trust in Middleware.
Middleware can be represented by the services and usecases we discuss in the "Usecases" section: data availability, coprocessors, FHE, TEE, MEV management, oracles, sidechains, threshold cryptography schemes etc. And there may be new usecases that have not even been invented yet. Middleware is software that runs on AVS and Cambrian. That is, depending on the angle of view, Middleware can be either Cambrian, which powers the AVSs, or the AVSs themselves, which powers the dApps. # PoolManager Idea behind the PoolManager is that we hold user’s funds (both SOL and SPL tokens) inside the system on a special account, which is also used for getting staking rewards. Each user/token pair has a unique account for holding funds.
We try to limit Cambrian from exposure to risky assets that could disrupt stability and so there is a separate Mint Validator contract — a whitelisting contract that will allow or disallow certain tokens from being put into the system. In the future we may have those on a per-user basis, but for now it is common for all users.
And TokenManager as part of PoolManager is used to deposit and withdraw free funds into user’s accounts. Since those funds are not staked they can be withdrawn immediately. All the staking rewards also go to this account so they can be staked or withdrawn later on.
When a user deposits funds into Cambrian, PoolManager mint them our token (LRT) cSOL, which will later be burned at the moment when user withdraws restaking assets.
# WorkerManager The WorkerManager manages enrolment and exit of workers for the network. Also it manages their accounts, which, much like user’s accounts, are unique for each pair of worker/token (or worker/SOL). Workers are the operators of the individual nodes that make up the AVS to run Middleware.
Workers are units that carry on computations needed by AVS. To operate it needs stake — this can be either the operator's own funds, which it restakes directly, and assets from other users entrusted to it (delegated). Workers can not manage those funds, they are there as a token of trust from users. If a worker behaves maliciously (e.g. submits bad data or fails his covenant in any other way) thos funds get slashed, partially or fully, depending on severity of the failure. \ Of course workers can not exit WorkerManager immediately, they should finish all their work and wait for all their stake to be returned, and only after that they can exit the network (AVS). As this process is quite delicate and requires a careful approach - we work through and model different options to choose the best one. # AVSManager Looking much like WorkerManager, this smart contract manages everything around AVS. It handles enrollment and exit and manages AVS accounts. As a PoolManager and WorkerManager, AVSManager has a unique account for AVS/token pair. AVS need accounts to hold funds that will be paid to workers for their work, so before any work can be scheduled for this AVS. If the amount is sufficient, then the work can be scheduled and executed. Further, different payment options and models for AVS will be introduced to increase flexibility and customisability.
In the current implementation, the conditions for delegating AVS work are quite simple and are as follows: * Number of workers with minimum stake is more or equal to minimum workers * AVS has enough funds on its accounts to pay for the services (number of workers used \* fee) # StakingManager Staking manager is responsible for staking, withdrawing and slashing users funds. It uses AVS slashers if needed. AVS also decides if the workers' stake should be slashed and marks them so. Stakers put their stake into worker’s corresponding accounts, separate one for each token accepted. We surely do remember how many stake which user did put into the account for withdrawal purposes. For now all tokens have the same withdrawal timeout, but probably we should do it per token. If a worker (node) is marked as slashed, funds in its accounts can be burned. Worker is then evicted from the system or reduce his income. For more information about the slashing process, see the Slashing section.
The difference with PoolManager is that PoolManager is responsible for whitelisting assets, minting and burning cSOL, depositing and withdrawing free funds, while StakingManager is directly responsible for asset staking and slashing. **Note:** cSOL is not an LRT or LST, and it is implemented in such a way that it will not be traded anywhere. The cSOL is a wrapped SOL that is needed to enable the SOL to function as an SPL token within Cambrian to interact with Solana Accounts and Programm. # AVS Overview Security sharing has a large number of use cases, as shown above. At the same time, Cambrian democratizes the creation of new services on top of the Solana blockchain - making it easier to create secure services, which could contribute to the development of the Solana ecosystem. At the same time, we consider Cambrian as a system that allows you to quickly and safely lift services on Solana. A good analogy in this regard is Amazon Web Services. At the dawn of web2, creating highly loaded systems required large capital and human resources: it was necessary to create the right server infrastructure, think about its scaling, fault tolerance, etc. This required long months of development, as well as investment in server infrastructure. With the development of AWS, it became possible to do this literally in a couple of clicks, since AWS offered all the necessary components "out of the box" and by combining these building blocks you can easily implement the necessary functionality. This revolutionized the time-to-market and cost of building high-load systems, which led to an explosion in the number of applications on AWS and the creation of an entire ecosystem. Similarly, Cambrian is working on creating the necessary building blocks to implement AVS, some of which are immutable while others are interchangeable and composable. These components and processes include: * Connecting staking funds to a specific validator or validator cluster via a private key. * Orchestration mechanisms between various services and components. * The ability to choose and utilize different consensus algorithms and mechanisms (HotStuff, PoA, Pol (PoC), PoWeight, RAFT, Tangaroa, QBFT, IBFT, and others) along with governance models (including threshold signatures) depending on the specific product require-ments. For example, in permissioned solutions, there may be a central regulator with the authority to override, edit, or delete records as necessary. A consortium governance approach with different threshold values or a fully public consensus algorithm could also be applied. * Customizable slashing parameters and reward distributions. * Mechanisms for dynamically adjusting fee structures based on Middleware parameters: required machine power for AVS; requirements for Solana validator history and stake; the ability or restriction for a validator to participate in other AVS; specifics of tasks performed in AVS (DA, bridge with zk, decentralized sequencer, blockchain, and other use cases). * Staking diversification rules: the number of\ AVS in which a Solana validator can stake and validate, in conjunction with permissions granted by the AVS themselves for validator admission. # Validator Key Sharing How operator validators are paired with AVS nodes One of the key aspects of Cambrian's infrastructure is the ability to launch additional machines for AVS validation alongside the primary Solana node using a single private key. Cambrian's implementation will resemble DVT and will comprise the following com-ponents: * Shamir's secret sharing - Validators (main node and AVS) use BLS keys. Individual BLS "key shares" can be combined into a single aggregated key (signature). The private key for a validator is the combined BLS signature of each node (Solana node and AVS nodes) in the validator cluster. * Distributed Key Generation (DKG) - A cryptographic process that generates key shares and is used to distribute shares of an existing or new validator key between Cambrian nodes (Solana node and AVS nodes). * Multiparty Computation (MPC) - the full validator key is generated in secret using multiparty computation. The full key can be known to the validator if it keeps control of both the Solana node and AVS nodes. Or the key may not be known to any operator if there are multiple individuals in the AVS cluster, but there is one common Solana node - they will only know their part of the key (their "share"). * The next component in the case of DVT is a consensus protocol that governs the relationship of nodes in individual clusters - the consensus protocol selects one node as the initiator of a block. It passes the block to other nodes in the cluster who add their key shares to the common signature. In the case of Cambrian, this separate consensus mechanism can be implemented within AVS if there are multiple individuals in the cluster. * Mechanism of calculation and distribution of rewards between different AVS of one validator depending on its stability of work, distribution conditions from AVS themselves. This may also require an atomic swap or wrapped token mechanism, as different AVSs may have different token standards depending on the VM used. # Quorum and Consensus for AVSes Types of quorum and consensus mechanisms for flexibly customising different ways of using AVS Currently, there is a wide range of consensus types tailored for various purposes, ranging from public blockchains to conditionally centralized blockchains with leaders. The challenge arises when a project is launched on a public blockchain network, as the existing consensus mechanisms may not be suitable. This necessitates additional costs to develop proprietary solutions or requires adherence to a common consensus mechanism by connecting with other nodes, as seen in the case of subnetworks. For instance, in financial applications integrated with web2, a consensus with a leader or extended administrator rights may be necessary. In the case of bridge creation, a closed consensus with 100% agreement or a mandatory threshold of 70-80%, as seen in implementations using Intel SGX with an administrator key and 6-8 nodes, might be required. Con-versely, for initiatives like AVS, aimed at providing infrastructure for DePin, a lower threshold for signatures might be necessary due to the peculiarities of router connections, which could have poor connectivity and significant delays. Therefore, basing on Cambrian AVS developers can implement various consensus types. Since the validator is expected to operate on a Pos basis, we are considering only Pos-based consensus algorithms to be implemented in the future for different use cases: * **PoH (Proof of History):** Implemented in Solana, PoH is one of the primary reasons for Solana's high speed and scalability. It helps reduce node loads when processing blocks. The concept behind PoH is that the order of events is as crucial as the events themselves in a blockchain network, and proving the order of events is necessary to maintain network in-tegrity. PoH utilizes a Verifiable Delay Function (VDF) to generate a timestamp for each block in the blockchain. * **PoA (Proof of Authority):** Validators assert their real identities, which are established within the PoA consensus model. Network managers assess the trustworthiness of potential validators, and besides staking, the validator's reputation also plays a role in this scenario. This mechanism is partially centralized due to the involvement of network managers and may be applicable to semi-closed systems where the participation of third-party validators is permissible under certain conditions. * **QBFT:** Recommended for enterprise-level consensus protocols for private networks, QBFT involves validators taking turns to create the next block. Before inserting a block into the chain, the vast majority (more than or equal to 2/3) of validators must first sign the block. * **Pol (Proof of Importance):** Utilized to determine which network participants (nodes) have the right to add a block to the blockchain. It allows for the assignment of specific conditions for AVS valida-tors, such as: - Stake size and balance in the account.\ Frequency of interaction of a specific account with other participants in the network. - Quality of connection to the network at a given moment. Such an algorithm may be applicable, for example, to DePin, where different devices may have varying characteristics and connectivity quality depending on their lo-cation. * **PoC (Proof of Capacity):** Assumes that miners need to prove they have sufficient storage space for data. It involves generating all possible hashes on the hard drive, and the more hard drive space a miner has, the higher the chance of obtaining the correct hash combination and winning a block reward.\ This mechanism can be adapted to serve as an analog for DAC (Data Availability Committee) for decentralized confirmation of validators' ability to accept the necessary amount of data for storage. Addition-ally, PoC can be modified as a PoWeights mechanism, which weighs its users based on their available data volume. * **Raft:** This consensus algorithm employs a leader and requires a network to have at least 51 * **Tangaroa:** Combines Byzantine fault tolerance with the security, activity, simplicity, and clarity of Raft. Typically consisting of 3-5 systems in a clus-ter, it allows for the failure of up to 1/2 of the nodes with the concept of "randomization when selecting leadership." * **HotStuff:** A Byzantine fault-tolerant mechanism based on leaders. It resembles PBFT but introduces a new stage to solve the hidden block problem. HotStuff employs a threshold signature scheme. All nodes do not directly send signed voting messages; instead, they first send their votes to the leader. The leader then aggregates all signatures before publishing them to other nodes. Such aggregation reduces signature verification time. # AVS Reward Model Since Cambrian's modular structure allows for the deployment of protocols with varying orientations (from public to private solutions) and completely different usage models, as well as different requirements for validators, it is evident that a fixed percentage reward model for all projects is not suitable. Addi-tionally, in some cases, a fixed percentage, such as 10%, may exert too much influence on tokenomics depending on its design, and corporate permissioned solutions with their own set of validators and AVS may require the absence of tokens altogether. Therefore, the most rational solution would be to continue Cambrian's modular approach and, in the case of the Reward Model for different restaker incentive mechanisms, Cambrian plans to implement various strategies that can offer more flexibility for developers, restakers, and AVS users: * Fixed reward rate with a choice of fixed percentage by AVS: applicable in cases where, for example, the protocol receives a fixed income from users for using the protocol. * Floating percentage rate: may be applicable for tokenomics with decreasing emission over time, in gaming projects, and protocols with governance to-kens. * Ability to create complex models where a portion of user fees goes to developers besides AVS: applicable in cases where multiple applications can be launched on top of AVS. * Absence of rewards: this can be useful for corporate solutions that do not require their own token and support AVS cluster infrastructure using Cambrian with their own funds. In this case, it can allow for the formation of a stable Inflow for Cambrian itself by providing ready-made AVS-as-a-Service infrastructure solution packages for corporate clients. The mechanics of Reward Models and their modeling will be discussed in more detail in a separate document titled "Cambrian Rewards Models." # Slashing General overview of the slashing mechanisms in Cambrian ### Why Cambrian needs slashing Cryptoeconomic security defines the costs that an attacker must pay to cause a protocol to lose its desired security property. This is called the "cost of corruption". System has strong security when the CoC far exceeds any potential profit from corruption. Cryptoeconomic security contrasts with systems that provide security guarantees based on majority trust, which are only valid if at least a threshold percentage of operators are altruistic and will act honestly. The main idea of Cambrian is to provide cryptoeconomic security through various mechanisms that entail a high cost of corruption. Cambrian ensures it by implementing different slashing mechanisms for participants. If a staker who restakes to Cambrian is proven to have behaved improperly while opting-in in AVS, then that staker's SOL will be slashed and frozen. This means this validator will be prohibited from further participation in providing services in AVS. Slashing rules are defined in the slashing contract within the AVS chain. Let's now look at what these slashing rules might be. In Cambrian, each ABC can independently implement the rules of slashing, however, it will also be possible to use ready-made building blocks for custom implementation of slashing. ### Incorrect attestations Obviously, it will be good for the network if the stake is diversified enough between different nodes, so that no single node exceeds a certain threshold. This makes the service resistant to errors or attacks by a single validator. Thresholds and diversification rules are described in a separate module inside Cambrian. However, multiple validators may attempt to start a coordinated attack. This is where anti-correlation penalties come into play: the idea is that if a validator does something bad, the penalty will be higher if more validators make a mistake around the same time. In other words, you are punished for correlated failures. The anti-correlation penalty curve itself is specified when creating the AVS. Obviously, it will be good for the network if the stake is diversified enough between different nodes, so that no single node exceeds a certain threshold. This makes the service resistant to errors or attacks by a single validator. Thresholds and diversification rules are described in a separate module inside Cambrian. However, multiple validators may attempt to start a coordinated attack. This is where anti-correlation penalties come into play: the idea is that if a validator does something bad, the penalty will be higher if more validators make a mistake around the same time. In other words, you are punished for correlated failures. The anti-correlation penalty curve itself is specified when creating the AVS. ### Inactivity Another reason why a validator can fail is being of-fline. In most validation services, it also makes sense to give a penalty for this, but its mechanism is dif-ferent. If one small validator fails, this is not a big risk for the system, so the penalty is small. However, the situation becomes completely different when the amount of stake close to the thrashhold (and the corresponding validators) are offline. In this case, the viability of the service is jeopardized. To solve such problems, there are rules for increasing the fine depending on the downtime. ### Mathematical formalisation You can read more about the mathematical formalisation of the slashing mechanism in the document "Cambrian: Restaking SOL to Enable Shared Security on Solana v0.1" in section 10 "Mathematical Formalisation": # Operators Guideline Coming soon. # Restaking Guidelines Coming soon # AVS Developers Guidelines Coming soon. # Tools to work with Cambrian Later in this section, various tools for working with Cambrian and monitoring AVS will be collected, such as SDK, explorer, various dashboards, ready-made templates and much more. # Cambrian Ecosystem Coming soon. # Links & Contacts * Site: * Twitter: * Discord: * Substack: * Documentation: * TG channel: * TG chat: [https://t.me/cambrian\_one](https://t.me/cambrianchat) # Risks The same staker can restake in a different set of AVS. Accordingly, if a set of stakers matches in different AVS, this leads to the fact that the profit from corruption in this group of stakers is summed up as the profit from corruption of each AVS, while the total amount of stake that validators risk remains the same. This makes the system cryptoeconomically in-secure. Even in the more general case, when the set of stakers in different AVS is only partially the same, there is a possible risk of cascading failure, where an attack on one AVS can lead to slashing of a group of validators, which reduces the security of other AVS in which this group of stakers were also validators and makes the attack possible on them. # Audits Coming soon.