CBDC Design Pyramid Framework

• CBDC Design Pyramid is a layered framework where lower-level technical choices constrain higher-level functionalities in digital currency systems.
• The framework synthesizes variations—from three to five layers—addressing offline payments, architectural classification, and protocol stack evaluation.
• It highlights key trade-offs such as privacy vs. compliance and performance vs. assurance, clarifying dependency boundaries in CBDC design.

The CBDC Design Pyramid is a layered analytical framework for organizing the design of central bank digital currency systems so that lower-level technical or institutional choices constrain higher-level functionality. In the CBDC literature, the term does not denote a single immutable taxonomy. Rather, it appears as a family of related representations: a three-layer objective-and-countermeasure model for offline payments, a four-layer architecture model for system classification, and several five-layer extensions that incorporate protocol composition, governance, evaluation, or monetary taxonomy. Across these formulations, the common idea is that cryptographic primitives, architecture, ledger choices, access models, governance controls, and application requirements are not independent; they stand in dependency relations that can be visualized hierarchically (Guiraud et al., 11 Dec 2025, Tang et al., 10 Jul 2025, Senn et al., 17 Mar 2026).

1. Historical emergence and major formulations

The four-layer pyramid reported by Tang and Si places system architecture at the base, followed by ledger technology, access model, and application area at the apex. In that formulation, lower layers impose fundamental constraints on all upper layers, while upper layers capture more use-case-specific choices. The survey explicitly treats this as the original Auer-style pyramid and then refines it through a review of 135 papers published between 2018 and 2025 (Tang et al., 10 Jul 2025).

Later work repurposes the pyramid to emphasize different analytical objects. Guiraud et al. use a three-layer pyramid for offline payments, aligning three major objectives with design elements: Access Control Security with Cryptographic Signatures, Security against Depositor’s Misbehavior with Secure Hardware, and Privacy by Design with ZKPs & Blind Signature Schemes (Guiraud et al., 11 Dec 2025). Goodell, Toliver, and Nakib recast the pyramid as an end-to-end protocol stack running from cryptographic primitives up to regulatory governance (Goodell et al., 2021). The CEV Framework turns it into a design-and-verification workflow moving from policy priorities to consensus selection and formal validation (Jin et al., 2021). A systematization-of-knowledge paper then generalizes the idea to a layered design space of privacy-enhancing technologies, settlement architectures, infrastructure models, user-facing features, and research horizons (Senn et al., 17 Mar 2026). Finally, a taxonomy of tokenised money uses a five-layer pyramid to stack twelve monetary design dimensions from issuer and collateral to governance and user scope (Ankenbrand et al., 11 Dec 2025).

Source	Layers	Primary emphasis
(Guiraud et al., 11 Dec 2025)	3	Offline objectives and countermeasures
(Tang et al., 10 Jul 2025)	4	Architecture, ledger, access, application
(Goodell et al., 2021, Jin et al., 2021, Senn et al., 17 Mar 2026, Ankenbrand et al., 11 Dec 2025)	5	Protocol stack, evaluation, design space, or taxonomy

This plurality is analytically important. It suggests that the pyramid is best understood as a meta-structure for representing dependency, rather than as one fixed decomposition of CBDC design.

2. The three-layer offline-payments pyramid

In the offline-payments formulation, the base layer is Access Control Security, defined as protection of a user’s funds against unauthorized third-party use. The associated ITSec principle is Authenticity, and the corresponding design element is Cryptographic Signatures such as ECDSA. Every transaction statement must carry a non-repudiable digital signature tied to the sender’s private key, and signatures are verified on-device and by the recipient without any online check with the trusted authority at spend time. The paper’s authenticity invariant is

$$\mathrm{Verify}(pk_{u},\,T.message,\,T.sig)=true \Rightarrow author(T)=u,$$

with the equivalent forgery bound

$$\Pr[\mathrm{Verify}(pk_{u'},T'.msg,T'.sig)=true]\le \epsilon_1(n).$$

In the paper’s summary mapping, this is: Access Control Security $\rightarrow$ Authenticity $\rightarrow$ Cryptographic Signatures (Guiraud et al., 11 Dec 2025).

The middle layer is Security against Depositor’s Misbehavior, defined as preservation of the integrity of an environment, potentially the wallet, against misbehavior of its owner, including double-spending. The associated ITSec principles are Integrity & Authenticity, and the design element is Secure Hardware. Sensitive wallet logic is embedded inside a tamper-resistant secure hardware module such as a Smartcard Secure Element or TEE; monotonic counters or secure one-way state transitions are enforced; hardware attestation proofs may accompany transactions; and later detection on reconnection can be used to identify and blacklist the offender. The formal state-integrity requirement is expressed as

$S(t+1)=f(S(t),\,T_t),$

with a hardware-enforced counter satisfying

$c(t+1)=c(t)+1,$

so that replay or roll-back produces a non-matching counter and is rejected. Guiraud et al. make the central conclusion that the integrity of a user’s wallet and the prevention of double-spending race attacks should be addressed through the adoption and integration of secure hardware within a CBDC system (Guiraud et al., 11 Dec 2025).

The top layer is Privacy by Design, defined as embedding anonymity, unlinkability, non-traceability, and confidentiality into the architecture. The associated ITSec principle is Confidentiality, and the design elements are Zero-Knowledge Proofs & Blind Signature Schemes. Blind signatures are used at issuance so that the trusted authority cannot link tokens to the withdrawing user, while ZKPs are used on each offline spend to prove validity without revealing amounts, identities, or serial numbers. The paper gives a zero-knowledge condition

$$\exists \ \mathrm{Simulator}\ S \text{ such that } \{S(x)\}\equiv \{(\pi,\,View_{Verifier}(x,w))\},$$

and an unlinkability bound

$$\left|\Pr[Adv \gg \pi_1 \gg same\ user \gg]-\Pr[Adv \gg \pi_2 \gg same\ user \gg]\right| \le \epsilon_2(n).$$

The inter-layer narrative is explicit. Authenticity is a prerequisite for both Integrity and non-repudiation of privacy-preserving proofs; secure hardware replaces the online trusted authority for integrity during offline operation but introduces hardware vendors as trust anchors; and privacy mechanisms can be attached either directly to the signature layer or run inside secure hardware. The paper therefore presents the offline pyramid not merely as an ordering of goals, but as a map of interference, dependence, and cost propagation (Guiraud et al., 11 Dec 2025).

3. The four-layer architectural pyramid

Tang and Si refine the CBDC Design Pyramid into four vertically stacked layers: Foundational (System Architecture), Core (Ledger Technology), Interface (Access Model), and Application (Use Cases). Their abstract design vector is

$D_i=(A_i,L_i,M_i,P_i),$

where

$$A \in \{direct, indirect, hybrid\}, \quad L \in \{CLT, DLT, hybrid\}, \quad M \in \{account, token, hybrid\}, \quad P \in \{retail, wholesale, hybrid\}.$$

This formalization makes the pyramid a compact classification space for CBDC instances (Tang et al., 10 Jul 2025).

At the Foundational layer, the focus is on who runs the system and how data and state are distributed. The survey distinguishes One-tier (Direct), Two-tier (Indirect/Hybrid), and five state-distribution models: Centralized, Leaderless, Macro-partitioned, Micro-partitioned, and Direct (cash-like). Two-tier architecture is described as scalable, preserving the commercial bank role, and common in 92 % of pilots (Tang et al., 10 Jul 2025).

At the Core layer, the record-keeping mechanism is classified as Centralized Ledger Technology (CLT), Distributed Ledger Technology (DLT), or Hybrid CLT + DLT. Permissioned systems such as Hyperledger, Corda, and Besu are contrasted with permissionless chains, which are said to be less common due to sovereignty concerns. Consensus mechanisms such as Proof of Authority, Notary Service, and PBFT/Practical BFT are favored for finality and efficiency. The survey also places privacy and auditability primitives at this layer, including the Pedersen commitment

$$\Pr[\mathrm{Verify}(pk_{u'},T'.msg,T'.sig)=true]\le \epsilon_1(n).$$0

where $$\Pr[\mathrm{Verify}(pk_{u'},T'.msg,T'.sig)=true]\le \epsilon_1(n).$$1 is a secret value and $$\Pr[\mathrm{Verify}(pk_{u'},T'.msg,T'.sig)=true]\le \epsilon_1(n).$$2 is a random blinding factor. It also gives an informal UTXO-set model,

$$\Pr[\mathrm{Verify}(pk_{u'},T'.msg,T'.sig)=true]\le \epsilon_1(n).$$3

with each $$\Pr[\mathrm{Verify}(pk_{u'},T'.msg,T'.sig)=true]\le \epsilon_1(n).$$4 spendable once, thereby enforcing double-spend protection offline (Tang et al., 10 Jul 2025).

At the Interface layer, the survey distinguishes Account-based, Token-based, and Hybrid access. Account-based systems rely on on-chain identities and strong AML; token-based systems emphasize offline enablement, local signature checks, and user-controlled private keys; hybrid systems combine account layers for high-value or wholesale use with UTXO-style layers for retail privacy. This layer also includes custodial vs. non-custodial wallets, biometric/social recovery, single-tier vs. multi-tier login levels, and programmability via APIs or smart contracts (Tang et al., 10 Jul 2025).

At the Application layer, the survey distinguishes Retail, Wholesale, and Hybrid scenarios, together with domestic versus cross-border coverage. Its comparative analysis of 26 CBDC projects reports that the most common configuration consists of a two-tier architecture, DLT, and a token-based access model, while application domains show no dominant trend. The same study reports 65 % DLT-based, 23 % hybrid, and 12 % CLT ledgers; >50 % token-based, 23 % account, and 23 % hybrid access models; and 42 % retail only, 19 % wholesale only, and 39 % hybrid applications. Examples include Helvetia III, Platypus, and E-CNY (Tang et al., 10 Jul 2025).

This version of the pyramid is primarily classificatory. It is less concerned with proving a specific security objective than with showing how architectural and application choices co-vary in the existing CBDC landscape.

4. Protocol-stack and evaluation variants

The pyramid becomes more concrete in protocol-stack proposals. Goodell, Toliver, and Nakib describe a five-layer arrangement consisting of Base Cryptographic Primitives, Digital Asset / State, Consensus / Settlement, Wallet Interface, and Regulatory Governance. At the bottom are asymmetric key pairs, blind-signature blinding and unblinding functions $$\Pr[\mathrm{Verify}(pk_{u'},T'.msg,T'.sig)=true]\le \epsilon_1(n).$$5 and $$\Pr[\mathrm{Verify}(pk_{u'},T'.msg,T'.sig)=true]\le \epsilon_1(n).$$6, collision-resistant hashing $$\Pr[\mathrm{Verify}(pk_{u'},T'.msg,T'.sig)=true]\le \epsilon_1(n).$$7, and issuer signatures $$\Pr[\mathrm{Verify}(pk_{u'},T'.msg,T'.sig)=true]\le \epsilon_1(n).$$8. Their blind-signature correctness condition is

$$\Pr[\mathrm{Verify}(pk_{u'},T'.msg,T'.sig)=true]\le \epsilon_1(n).$$9

Above that, the token is represented as a USO asset with a state history $\rightarrow$0, where

$\rightarrow$1

and the relay provides a proof of provenance

$\rightarrow$2

At settlement, the proposal separates an Integrity-DLT for relay commitments from a Monitoring-DLT for issuance and redemption, while maintaining the minting invariant

$\rightarrow$3

At the top, regulated institutions act as minters and sinks, enforcing AML/KYC at the on- and off-ramps without observing the interior chain of peer-to-peer transfers (Goodell et al., 2021).

A different five-layer reinterpretation appears in the CEV Framework, where the pyramid runs from Policy & Feature Prioritization down through High-Level Operating Architecture, Consensus Evaluation, Detailed Technical Components, and Verification & Iteration. The policy layer introduces weights

$\rightarrow$4

These weights feed a modular consensus score. For each feature $\rightarrow$5,

$\rightarrow$6

and the overall utility is

$\rightarrow$7

The framework then combines consensus selection with operating-architecture patterns such as Two-Tier + Virtual IDs and Three-Tier + Neutral Processor, and validates the result through formal proofs and empirical experiments. The paper gives example impact scores of approximately $\rightarrow$8 for a wholesale network and $\rightarrow$9 for retail shards, while emphasizing that consensus algorithms cannot achieve all system features simultaneously and that operating architectures are used to compensate for weak spots (Jin et al., 2021).

These two variants show that the pyramid can function either as a protocol decomposition or as a design workflow. In both cases, the hierarchy expresses where trade-offs are introduced and where they may be compensated.

5. Broader design-space and monetary-taxonomy interpretations

The systematization-of-knowledge literature extends the pyramid upward into open design space. One five-layer version places Cryptographic Primitives and PETs at the base, followed by System Architecture and Settlement Protocols, Network and Infrastructure Considerations, User-Facing Features and Compliance, and an apex of Post-Quantum Security and Future Research Directions. This work identifies four canonical design patterns: Global State Update, Local State Update, Transfer Digital Coin, and Burn-and-Create. The patterns differ in whether global information is positive or negative, whether integrity depends on total order or no total order, and whether visibility is public, permissioned, or limited to nullifiers or spent-coin lists. The paper explicitly notes that only Transfer Digital Coin and some Local State Update designs support true offline or one-time offline modes, and that “Prevent double-spend” architectures rely on trusted hardware whereas “Detect and sanction” designs rely on retrospective nullifier checks (Senn et al., 17 Mar 2026).

The same paper frames infrastructure trade-offs in terms of synchrony, distributed control, communication patterns, sharding, and data growth. It also identifies research gaps: post-quantum security, offline payments, composable PETs, usable exact-change protocols, performance benchmarking, interoperable identity infrastructures, and scalability via sharding and concurrent execution. It further states that although classic E-Cash and PayOff show feasibility, no full implementation exists for offline payments (Senn et al., 17 Mar 2026).

A different broadening occurs in the twelve-dimension taxonomy of tokenised money. There, the pyramid is organized as Foundation—Issuer Type, Denomination, Underlying Collateral; Infrastructure—Access Model, Token Integration, Programmability; Stability & Value Assurance—Peg/Stability Mechanism, Redemption Fungibility, Redemption Value; Governance & Controls—Issuance, Functional Controls; and User—the target group of retail, wholesale, or both. The paper does not provide formal mathematical formulas for these dimensions. Its purpose is instead to clarify how heterogeneous forms of tokenised money, including CBDCs, differ in issuer structure, collateralisation, stability mechanisms, governance, and technological embedding (Ankenbrand et al., 11 Dec 2025).

Taken together, these broader interpretations show that the CBDC Design Pyramid has expanded from a systems-classification device into a general framework for relating cryptography, network design, monetary structure, and policy controls.

6. Interdependencies, misconceptions, and unresolved tensions

A recurrent theme across the literature is that a pyramid layer is not merely a convenient label; it is a dependency boundary. In the offline-payments model, Layer 1 authenticity is a prerequisite for Layer 2 integrity and for the non-repudiation of Layer 3 privacy-preserving proofs. In the architectural survey, system architecture constrains ledger choice, which constrains access models and application scope. In protocol-stack proposals, cryptographic and state-layer decisions determine settlement possibilities, wallet behavior, and regulatory visibility. This suggests that upper-layer properties such as privacy, offline usability, or programmability cannot be evaluated in isolation from lower-layer trust assumptions (Guiraud et al., 11 Dec 2025, Tang et al., 10 Jul 2025, Goodell et al., 2021).

One common misconception is that the CBDC Design Pyramid denotes a single canonical four-layer diagram. The literature instead uses the pyramid to model different objects: objectives, architectural classes, complete protocol stacks, evaluation workflows, and monetary taxonomies. Another misconception is that privacy belongs only to the top of the pyramid. The cited works show the opposite: privacy outcomes depend on signatures, nullifier structures, commitments, wallet key management, hardware trust, access models, and gateway governance, not merely on the addition of a PET at the final stage (Guiraud et al., 11 Dec 2025, Senn et al., 17 Mar 2026).

The central unresolved tensions are likewise consistent across papers. Performance vs. assurance appears when heavier ZKPs increase proof sizes and proving time, or when stronger hardware increases deployment cost and lifecycle complexity. Privacy vs. compliance appears when auditable anonymity, tiered KYC, dynamic virtual IDs, or threshold-based privacy revocation are introduced to reconcile secrecy with oversight. Offline resilience vs. trust minimization appears when secure hardware prevents double-spending locally but introduces hardware manufacturers and firmware as critical trust anchors, whereas detect-and-sanction schemes avoid some hardware assumptions but require retrospective checks and tolerate temporary ambiguity (Guiraud et al., 11 Dec 2025, Jin et al., 2021, Senn et al., 17 Mar 2026).

The forward-looking agenda therefore converges on several themes: cross-border CBDC ecosystems, offline resilience & inclusion, scalability & performance, privacy vs. compliance, post-quantum readiness, programmability & policy automation, and holistic ecosystems involving banks, non-bank financial institutions, monetary transmission, and macro-financial stability (Tang et al., 10 Jul 2025). The pyramid remains useful precisely because it does not eliminate these tensions; it locates them.