> For the complete documentation index, see [llms.txt](https://golden-shield-digital-treasury-b.gitbook.io/product-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://golden-shield-digital-treasury-b.gitbook.io/product-docs/bondtrust-protocol/cnc-public-chain.md).

# CNC Public chain

CNC’s RWA-Dedicated Blockchain Architecture

CNC is a Layer-1 blockchain purpose-built for real-world assets (RWA), providing a specialized architecture that balances performance, security, and regulatory compliance. At its core, CNC utilizes a Tendermint Byzantine Fault Tolerant consensus engine, which offers high throughput and near-instant finality for transactions. This means sovereign bond transactions on GDB’s platform can be settled in seconds with final confirmation on the first block, significantly enhancing efficiency and reducing settlement risk. On top of consensus, CNC features a **WASM-based smart contract** environment that enables complex financial logic (for tokenization, custody, etc.) to run safely on-chain. This smart contract layer allows GDB to deploy custom modules (e.g. bond issuance contracts) without modifying the base protocol, leveraging WebAssembly for secure and performant execution.

Critically, CNC’s architecture embeds compliance and identity functionalities at the chain level. It includes a Decentralized Identity (DID) system and on-chain compliance middleware to enforce KYC/AML rules natively. Every user or entity on CNC can be associated with a DID that proves their verified identity status, enabling the chain to restrict certain asset operations to authorized participants. Privacy is preserved through cryptographic techniques (including zero-knowledge proofs), ensuring that identity verification does not mean public disclosure of personal data. In addition, CNC offers an integrated RWA marketplace (the “RWA Exchange”) as a native module of its Layer-1. This on-chain exchange provides a compliant trading venue for tokenized assets, supporting seamless liquidity for RWA tokens via any standard crypto wallet. The exchange layer is aware of compliance constraints (e.g. only whitelisted investors can trade certain tokens) and ensures all trades adhere to regulatory permissions. Overall, CNC’s architecture is tailored to RWA tokenization: a fast consensus, a flexible smart contract layer, and built-in identity/compliance and exchange modules together form a robust foundation for platforms like GDB.

### GDB and CNC Layered Architecture

**GDB’s sovereign bond custody platform (GDB) is architected as an application layer on top of CNC’s core blockchain services.** Figure 1 illustrates the layered stack: the lower layers are provided by CNC (identity, custody, transaction infrastructure), while the upper layers consist of GDB-specific modules such as the BondTrust Protocol, NAV Oracle, and DvP Engine.

At the base is CNC’s **transaction layer**, comprising the blockchain ledger and Tendermint consensus. This layer provides fundamental capabilities like immutable record-keeping, asset transfer, and atomic transaction execution. All sovereign bond token transactions, once committed, are stored on-chain with full transparency and immutability. This gives GDB an auditable and tamper-proof ledger for bond custody operations. The transaction layer also supports multi-asset atomic swaps and complex transaction scripts, which GDB’s DvP (Delivery-vs-Payment) Engine can leverage to ensure that bond token deliveries and payment transfers occur simultaneously and irrevocably within single transactions.

Above the core ledger, CNC’s **identity and compliance layer** provides services that GDB taps into for regulatory needs. CNC’s DID system and KYC/AML enforcement middleware reside here. GDB does not need to build its own identity verification from scratch; instead, it utilizes CNC’s identity layer to ensure that only verified participants (e.g. eligible investors, authorized custodians) can interact with GDB’s bond tokens. For example, before a bond token (GDO) transfer is executed, the CNC middleware can automatically check that both sender and receiver addresses are associated with DIDs that have passed the required KYC checks. This on-chain middleware simplifies compliance for GDB by **baking enforcement into the infrastructure**, rather than relying solely on off-chain processes.

CNC’s **asset custody layer** is another foundational component leveraged by GDB. In the CNC model, physical assets (like sovereign bond certificates or entitlements) are held by regulated institutional custodians off-chain, while equivalent tokens are issued on-chain to represent those assets. GDB’s BondTrust Protocol interfaces with this layer: it defines how a custodian proves possession of the real bonds and then mints or releases the corresponding GDO tokens on CNC. The BondTrust module uses CNC’s built-in asset controls – for instance, requiring a custodian’s signature (a multi-signature scheme) on any token mint/burn transaction – to ensure that on-chain token supply always mirrors the actual bonds in custody. By building on CNC’s custody primitives, BondTrust maintains a one-to-one linkage between real-world bonds and their digital token representations.

Finally, at the top of the stack lie the **GDB-specific modules** (BondTrust, NAV Oracle, DvP Engine) which are implemented as smart contracts or application logic on CNC. These modules call into the lower layers as needed. For example, the NAV Oracle module utilizes CNC’s oracle framework and transaction layer to publish periodic NAV (Net Asset Value) or price data for the bonds. The CNC oracle system acts as a bridge between off-chain data (e.g. bond market prices or reference rates) and the blockchain. GDB’s NAV Oracle ingests official pricing data for the sovereign bonds (often a single source from the issuer or administrator) and posts it on-chain via CNC’s oracle mechanism, where it becomes available to smart contracts (for calculating accrued coupon interest, valuations, etc.) with cryptographic proof of authenticity. The DvP Engine, similarly, uses CNC’s transaction primitives to coordinate payment tokens (such as stablecoins) against bond token transfers in atomic swaps, achieving true delivery-versus-payment settlement on-chain. In summary, GDB’s application layer is tightly integrated with CNC’s identity, custody, and transaction services – a **layered architecture** that allows GDB to focus on business logic while relying on CNC for security, compliance, and performance.

### GDB’s Tokenization and Settlement Workflow on CNC

GDB’s sovereign bond workflow leverages various CNC services from issuance through secondary trading. The process can be broken down into key stages:

* **GDO Issuance via CNC’s Token Standard:** GDB issues **Government Debt Obligation (GDO)** tokens on the CNC chain to represent units of a sovereign bond. Each GDO issuance is initiated once a custodian has confirmed holding the corresponding bond (e.g. in a custodial account). Using CNC’s standardized token contract, the custodian (or an authorized issuer entity) mints GDO tokens that are pegged 1:1 to the underlying bond assets. CNC’s token standard supports metadata and regulatory flags, allowing GDB to encode details like ISIN, maturity date, coupon rate, and any transfer restrictions into the token at creation. The issuance transaction is recorded on-chain immutably, linking the GDO token supply to specific real-world bond assets held off-chain by the BondTrust custodial partner. This guarantees that every digital bond token is fully backed by a real sovereign bond under custody.
* **On-Chain Compliance (DID + KYC Enforcement):** Once issued, GDO tokens can only be held and transacted by approved participants, thanks to CNC’s DID-based compliance framework. Each investor or institution interacting with GDB’s platform must undergo KYC/AML verification and receive a blockchain DID attestation. The CNC middleware enforces compliance by **restricting token transfers to DID-verified addresses**. For instance, if an unverified address attempts to receive GDO tokens, the transfer will be blocked by the token’s compliance rules or the identity middleware. This ensures that secondary market trading of GDO remains within the legally permitted network of investors. The identity layer also logs compliance actions (approvals, rejections) on-chain or in audit logs, providing GDB and regulators with a transparent trail of identity checks. Furthermore, CNC’s privacy-preserving design means that while addresses are permissioned, the personal identity details of holders are not exposed publicly—only regulators or authorized parties can de-anonymize a DID if required. Thus, GDB achieves a balance between open tradability of tokens and strict adherence to sovereign bond investor eligibility rules.
* **Settlement and Secondary Trading via CNC RWA Exchange:** After issuance, investors can trade the GDO tokens on CNC’s integrated RWA Exchange module. This on-chain marketplace provides order matching and liquidity for GDO, allowing participants to buy or sell sovereign bond exposure in tokenized form. All trading is subject to the compliance checks mentioned above, and the exchange only permits trades that satisfy the token’s regulatory conditions (e.g., no cross-border transfer if restricted, no exceeding ownership limits, etc.). When a trade is executed, CNC’s fast finality ensures the token transfer and payment (in a stablecoin or digital currency) are completed atomically and cannot be reversed. The DvP Engine built into GDB’s contracts often leverages this by requiring that a matching payment is seen in the same block as the token transfer, effectively using CNC’s transaction capabilities for atomic swap. Settlement happens on-chain: for example, an investor purchasing GDO will send an agreed amount of a stablecoin (or CBDC) to the seller, and simultaneously the seller’s GDO tokens are transferred to the buyer – if either leg fails, the whole transaction aborts. This **delivery-versus-payment** process is facilitated by CNC’s ability to handle multi-asset transactions and by GDB’s smart contracts orchestrating the exchange of tokens for payment. The result is a near-instant, secure settlement of bond trades without relying on traditional T+2 clearing houses. All trade records are logged on the CNC blockchain, creating an auditable history of secondary market activity.

### GDO Lifecycle on the CNC Chain

The end-to-end lifecycle of a GDO (tokenized sovereign bond) on CNC covers several phases, from initial issuance to final redemption:

1. **Issuance:** GDB (through the BondTrust Protocol) creates GDO tokens once the real bond is deposited with a custodian. The custodian’s on-chain identity (DID) is used to authorize the minting transaction, which records the new GDO asset and links it to the bond’s identity/metadata. The issued GDO tokens are then allocated to the investor’s CNC address (or a distribution contract) as per the subscription or auction results.
2. **Holding & Transfers:** After issuance, the investor holds the GDO tokens in their wallet (which is essentially a CNC blockchain account tied to their verified DID). During the holding period, the investor can transfer or sell these tokens subject to compliance checks. CNC’s middleware continuously enforces that any recipient of a GDO transfer is on the allowed whitelist (has completed KYC) and that the transfer respects any regulatory constraints (for example, holding period or concentration limits). The blockchain’s transparent ledger records the current holder and transaction history of each GDO, allowing GDB to monitor the custody trail at all times. If the investor decides to sell before maturity, they may do so via peer-to-peer transfer or on the RWA Exchange, as described above, with immediate on-chain settlement.
3. **Coupon Accrual & Payouts:** Sovereign bonds typically pay periodic coupons (interest). GDB’s platform leverages CNC to handle coupon accruals in a traceable manner. The NAV Oracle module regularly updates on-chain data about accrued interest or NAV for the GDO tokens. For instance, at each coupon period, an oracle transaction (signed by the bond administrator or via the TSSO mechanism) can be posted to the CNC chain recording the amount of interest due per token. This data is used by smart contracts to facilitate coupon distribution. Coupon payouts can be executed on-chain: the issuer or custodian credits the investors with a stablecoin or digital cash equivalent to the coupon amount, using the CNC chain to deliver these payments to GDO holders’ addresses. Because all token holders and their holdings are known (on-chain state), GDB can automate the coupon distribution by instructing a payout contract to transfer the correct amount to each holder’s address. Each coupon payment transaction is logged immutably on CNC, providing investors and auditors with proof of payment. The combination of oracle-provided NAV data and on-chain payment assures that **coupon accrual and distribution are transparent and verifiable**. Investors can independently verify coupon transactions on the blockchain, and auditors can confirm that total paid coupons match what the bond terms dictate, thanks to CNC’s permanent record.
4. **Redemption:** Upon maturity (or an early redemption event), the GDO tokens are redeemed for the bond’s face value. In practice, GDB’s BondTrust Protocol will coordinate with the custodian and the investor to perform a **token redemption transaction**. The investor will send the GDO tokens back to the issuer (or a burn address) on the CNC chain, and simultaneously the redemption amount (principal repayment) is delivered to the investor, often as a stablecoin payment on-chain or via a linked bank transfer. The DvP Engine ensures this is atomic if done on-chain – the token burn and digital cash payment occur in one operation so that there is no settlement risk. CNC’s fast consensus finalizes the redemption within one block, and the GDO tokens are irrevocably burned (removed from circulation) to prevent any further trading. The custodian then releases the actual bond or its proceeds accordingly off-chain. After redemption, the lifecycle is complete: the CNC ledger contains the full audit trail of that bond token from issuance to redemption, including all interim transfers and coupon payments. These records (anchored by block hashes and Merkle proofs) serve as an **audit-friendly history** that GDB and regulators can review to ensure the custody and lifecycle events of the sovereign bond were handled correctly on the platform.

### CNC Capabilities Benefiting GDB

CNC’s technical capabilities directly enhance GDB’s bond platform, providing benefits in security, compliance, and interoperability:

* **Audit-Friendly Merkle Proofs:** All GDB operations on CNC are recorded in an immutable ledger, whose blocks are secured by cryptographic hashes. This enables *Merkle proof* techniques for audits – for example, GDB can prove to an auditor that a particular bond holding or transaction exists in the blockchain without revealing unrelated data. The blockchain’s transparency and immutability ensure that every token issuance, transfer, and redemption can be independently verified. The use of Merkle roots in block headers means any third party can confirm the inclusion of a record in the chain with cryptographic certainty. This auditability builds trust with regulators and clients, as the entire bond custody lifecycle is verifiable.
* **Privacy-Preserving KYC Enforcement:** CNC’s identity framework gives GDB a powerful way to enforce KYC and AML rules while preserving user privacy. Identities are linked to pseudonymous blockchain addresses via DIDs. Compliance checks (KYC/AML verifications, accreditation status, etc.) are performed off-chain by GDB or trusted partners, but the results are attested on-chain in the DID. Thereafter, CNC’s runtime enforces that only addresses with valid KYC attestation can transact GDB’s bond tokens. This *selective access control* is done without revealing personal information on the public ledger – only a flag or credential is checked. Advanced encryption and zero-knowledge techniques are employed to protect sensitive data. For GDB, this means the platform can remain compliant with securities laws (e.g. only qualified investors holding the tokens) automatically. Meanwhile, investors benefit because their personal data isn’t broadcast on-chain, and only regulatory authorities could trace an address back to an identity if necessary. This privacy-preserving compliance lowers the risk of data leaks and enhances user trust.
* **Fast Settlement via CNC’s Consensus:** The speed and finality of CNC’s Tendermint-based consensus mechanism greatly benefit GDB’s trading and settlement processes. Blocks are produced and finalized within a couple of seconds, allowing transactions to be confirmed almost instantaneously. In practical terms, an investor buying a tokenized bond via GDB will receive their tokens confirmed in their wallet within a single block, rather than waiting days as in traditional bond markets. Immediate finality also means no forking risk or rollback, which is crucial for financial transactions. GDB’s DvP Engine relies on this fast finality to perform atomic swaps of bonds against payments; both sides of a trade are settled in one block or not at all. The high throughput and quick confirmation on CNC enable GDB to handle high volumes of bond trades and coupon payments in real-time, paving the way for improved liquidity and market efficiency in what are typically illiquid sovereign debt markets.
* **Modular Middleware for Off-Chain Integration:** CNC is designed with a modular architecture (inspired by Cosmos-SDK principles) that eases integration with off-chain financial systems. For GDB, this means the blockchain can interface smoothly with existing banking, custody, and reporting systems. For instance, CNC’s oracle and cross-chain modules allow external data feeds (pricing, interest rates, FX rates) to be piped into the blockchain securely, which GDB uses for its NAV Oracle updates. Likewise, CNC’s interoperability features (APIs, SDKs, or even cross-chain bridges) enable GDB to connect its on-chain operations with off-chain processes at custodians and banks. A custodian’s internal system can trigger on-chain actions (like token issuance or freeze) via CNC’s APIs, and vice versa, ensuring the off-chain records and on-chain records remain in sync. The middleware modules can be customized or extended without hard-forking the chain, allowing GDB to adapt to new regulatory requirements or connect to new external services readily. This flexibility reduces development overhead for GDB and accelerates time-to-market for new features. In short, CNC acts as a **bridge between traditional finance and blockchain**, giving GDB the tools to integrate sovereign bond custody into the broader financial infrastructure.

### Compliance and Custody Stack Integration

The collaboration between CNC and GDB can be visualized as a **compliance and custody technology stack**. At the bottom of this stack is the CNC blockchain core, providing consensus and ledger services. Layered immediately above are CNC’s compliance and custody middleware components, which form the backbone for meeting regulatory and security requirements. This includes the DID/KYC system, regulatory rule engines, and multi-signature asset custody controls. These middleware components serve as an interface between the raw blockchain and the application logic, ensuring that any operation that GDB’s contracts perform will automatically check the necessary compliance/custody conditions (for example, verifying identities, or requiring custodian approval for certain actions). The middleware essentially encapsulates **financial regulations into code** on the chain.

Above the CNC middleware lie **GDB’s smart contracts and protocols**. These are bespoke to GDB’s sovereign bond platform – the BondTrust Protocol managing issuance/redemption, the NAV Oracle feeding data, and the DvP Engine handling atomic settlements. They are deployed on CNC’s smart contract layer and make use of CNC’s modules beneath. For instance, when BondTrust needs to mint new GDO tokens, it calls a CNC token module function which is gated by the custody middleware (ensuring a custodian’s cryptographic signature is present) and the identity middleware (ensuring the recipient is KYC-approved). Similarly, the NAV Oracle contract might accept inputs only from an address that has a special oracle DID designation, and those inputs might be further verified by CNC’s oracle module for authenticity. The GDB contracts thus **embed business logic while delegating trust enforcement to CNC’s built-in services**.

Finally, at the top of the stack are the **external interfaces** – the user-facing and institution-facing systems that interact with GDB’s platform. This includes the custodians’ interface and the investor application. Custodians, for example, might use a secure web portal or API that communicates with the BondTrust smart contract on CNC to initiate token issuances or approve redemption requests. Because CNC supports standard APIs and cryptographic authentication, a custodian’s existing custody software can be integrated to trigger on-chain events (with proper authorization) without manual intervention. Investors similarly might use a GDB web app or a standard wallet to manage their bond tokens; behind the scenes, that interface calls GDB’s smart contracts on CNC. The **stack design** ensures that at every interface – whether a custodian’s system or an investor wallet – the underlying actions pass through GDB’s contract logic and CNC’s compliance checks before finalizing on the blockchain.

In summary, CNC’s Layer-1 infrastructure and middleware provide GDB with a **turnkey compliance and custody stack**. This stack abstracts the complexities of regulatory enforcement and secure custody into the platform itself. GDB’s sovereign bond tokens benefit from institutional-grade security (with multi-signature custody and encrypted DIDs) and automatic legal compliance (with on-chain KYC and transaction controls). The tight integration means GDB can assure governments, issuers, and investors that the digitized bonds are handled with the same rigor as traditional custody systems, while also leveraging blockchain’s efficiency and transparency. By building on CNC’s architecture, GDB’s platform is able to seamlessly merge the on-chain and off-chain worlds – marrying the compliance of traditional finance with the innovation of decentralized technology.