Utility

This page details the high-level architecture and technical implementation of Canopy's decentralized security solution and offers a comprehensive explanation of this recursive system.

Architecture

Every Canopy chain comes pre-built with Security Root functionality: The ability to provide security for multiple external blockchains (Nested-Chains) simultaneously.

This is accomplished by allowing Root-Chain Validators to organize in subsets called Committees. Within each Committee, Validators opt-in to restake their collateral on the Root-Chain to perform Consensus (BFT) on behalf of the Nested-Chain.

A Nested Chain’s Security Root is where its Validators are registered and bonded with staked collateral.

Validators registered in a Committee run a full instance of the Nested-Chain software, which includes its own consensus rules, block timing, and execution environment, entirely independent from the Root-Chain.

⇪ The Nested Chain software may be built from the Canopy template, and is configured with their Validator_Private_Key for consistent identity across chains.

This design positions the Nested Chain as a fully independent network from the start — without the Cold Start problem of L1s.

Nested Chain instances connect over dedicated P2P channels, where BFT consensus is executed ➛ using the Root-Chain Validator's economic collateral only for as long as it’s designated as the security source.

The result: Nested-Chains gain strong security guarantees without becoming dependent on the Root Chain, meaning the Security Root is just a pluggable Validator provider to the Nested Chain.

---

Nested-Chains continue to operate under this security model throughout their incubation phase — steadily maturing at their own pace, becoming economically secure, growing their ecosystem, and improving decentralization.

⇨ Importantly, the Nested-Chain is able to switch Security Roots at any time, executing a governance transaction which triggers a Root-Chain switch. This enables a Nested-Chain to achieve full independence by changing itself as its own Security Root.

If the Nested-Chain is built with the Canopy template, it too is able to have Nested-Chains, at which point the recursive lifecycle starts again.

Nested Chains

At its core, a Committee is simply an on-chain coordination of trustless Validators running specific software. This flexibility allows for multiple flavors of Nested Chains, including:

• New utility blockchains tailored for specific applications.

• Consensus-driven decentralized oracles that aggregate and validate external data (such as the state of another blockchain or some DePIN application).

• On-the-fly horizontal scaling for a subset of functionality or state (sharding)

To qualify as a Nested Chain for the Canopy protocol, a chain must satisfy the following interface:

message NestedChainInterface {
    // receive validator updates from the Root-Chain via Websocket connection
    UpdateValidators(v Validators)
    // execute a consensus instance in order to produce a certificate result
    // send the certificate result to the Root-Chain using the RPC
    ExecuteQuorum() CertificateResult
    // change the source of the validator set
    UpdateSecurityRoot(rootChainId uint64, websocketURL string)
} 

message Validator {
  // the public key that is used to validate signatures from the operator
  bytes public_key = 1;
  // the weight of this node's vote, typically 1 to 1 matched to staked tokens
  uint64 voting_power = 2;
  // the p2p tcp address of the validator node
  string net_address = 3;
}

message CertificateResult {
  // the recipients who are rewarded based on the quorum decision
  // specifically who the committee agreed to reward from the committee pool
  RewardRecipients reward_recipients = 1;
  // the recipients who are penalized (slashed) by quorum decision
  // specifically who the committee agreed to slash due to evidence of bad behavior
  SlashRecipients slash_recipients = 2;
  // OPTIONAL: contains information regarding the 'buying side' of sell orders
  // including actions like 'buy/reserve order' or 'close/complete order'
  Orders orders = 3;
  // OPTIONAL: contains block information to allow provide Checkpoint-as-a-Service
  Checkpoint checkpoint = 4;
  // tombstone a committee by quorum decision
  bool retired = 5;
}

Default Implementation

The default implementation of a Nested Chain is the Canopy go client. Builders simply fork and clone the software to have a fully functional Nested-Chain out of the box.

Developers may modify the template as needed, like changing State Machine logic to add new utility, or updating NestBFT to use Proof-of-Work instead of Proof-of-Age.

The template comes pre-packaged with L0 functionality, enabling a recursive architecture where Nested-Chains may have Nested-Chains.

---

By default, Canopy Nested-Chains connect to the Root-Chain via web-sockets.

This connection enables the Nested-Chain to subscribe to critical information from the Root Chain like Validator updates.

message RootChainInfo {
  // root_chain_id: the chain id of the root chain
  uint64 root_chain_id = 1;
  // height: the block height of the root chain
  uint64 height = 2;
  // the current validator set
  ConsensusValidators validator_set = 3;
  // the selected delegate/pseudo-validator who receives rewards
  LotteryWinner lottery_winner = 4;
  // the swap order book from the 'root chain' for the 'nested chain'
  OrderBook orders = 5;
}

The connection to the Root-Chain can be 'trustless' by utilizing proofs of inclusion from the CanoTrie. For simplicity, the default implementation assumes the Nested-Chains has access to a Root-Chain full-node.

Once connected to the Root-Chain, the Nested-Chain functions like a typical blockchain — syncing, validating, and executing transactions — with one key distinction: its validator set is sourced externally.

If Validator updates are received from the Root-Chain in the middle of executing an instance of NestBFT, the process resets consensus but maintains Locks for BFT safety.

Decentralized Oracles

Nested-Chains may also be implemented as consensus-driven decentralized oracles — enabling many interesting use-cases.

Example 1: Permissionless Token Swaps to Bitcoin

The Canopy community wants token swaps to Bitcoin without requiring Bitcoin to make any changes to their software.

The Canopy community build a Nested-Chain that requires the Committee to come to consensus on the state of finalized Bitcoin data by using a local full-node or light client:

1. A Sell Orders (Ask) is created on Canopy - their CNPY is transferred to the Escrow Pool of the Committee.

2. A Bitcoin participant self-send an BTC transaction - embedding an intent to buy this order in the sigscript field.

3. The Committee witnesses the lock by reading the Bitcoin blockchain, coming to a +⅔ quorum agreement, and locks the SellOrder on the Root-Chain via the CertificateResultTx

4. Seeing the lock, the buyer sends BTC directly to the seller’s BTCReceiveAddress.

5. The Committee witnesses the BTC transfer, comes to another +⅔ quorum, and releases the seller’s CNPY on the Canopy to the buyer’s RootChainAddress.

Example 2: Validator Quality of Service for Cosmos

The community of a Cosmos chain decides that too many invalid transactions are being included in the block, but they don't want to make any changes to their software.

Canopy patrons build a Nested-Chain that requires the Committee to come to consensus on finalized Cosmos data by using a local full-node or light client:

1. A Validator on Cosmos creates the next block with no invalid transactions

2. The Committee witnesses this behavior by reading the external blockchain, coming to a +⅔ quorum agreement, and embeds the Validator as a reward recipient in the CertificateResultTx.

3. The Validator is able to claim those funds using the same SECP256K1 public key the validator uses on Cosmos, binding their identity across chains.

Incentives

Nested-Chains pay for Consensus services using their native cryptocurrency. Each time a new block is produced, the Validator who produced the block is rewarded.

Most Nested Chains are predicted to be auto-subsidized by the native cryptocurrency of their Root Chain. Thus, Validators performing Consensus services for the Nested-Chain are paid in the native currency of both the Nested-Chain and the Root-Chain.

Patrons of the Nested-Chain may further subsidize the Committee on either the Root-Chain or the Nested-Chain via a manual Subsidize Transaction.