中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC088
A digital-renminbi wallet screen does not tell you which database, validation process or settlement component sits behind it. The currency unit, the institution responsible for a balance and the technology used by a particular infrastructure component are different facts.
The opposite shortcut is also unsafe: describing centralised management does not prove that no component uses blockchain. Official descriptions of e-CNY have distinguished different layers and have evolved over time.
This lesson is an architecture-inference workshop, checked on 12 October 2026. It does not advise readers to open a wallet, make a payment, select a provider or treat a financial service as available to them. Its purpose is to decide which technical conclusions a piece of evidence actually supports.
Choose your reading route
In this guide
- 1. Separate the questions before choosing a technology label
- 2. Read the 2021 architecture description at its own scope
- 3. Account for the later framework without turning it into a universal network claim
- 4. Card A: a screen shows renminbi and a QR code
- 5. Card B: the liability is described, but the ledger is not
- 6. Card C: several operators do not imply public validation
- 7. Card D: a programmable feature does not identify an execution environment
- 8. Card E: one blockchain component is real evidence, but its boundary matters
- 9. Settlement language does not reveal a block format
- 10. Build a five-column architecture note
- 11. Check seven common conclusions
- 12. Misconceptions worth correcting carefully
- 13. Exercises with explained answers
- 14. Frequently asked questions
- 15. Sources and further reading
- Read sections 1–3 for the layer questions and dated official context.
- Work through the evidence cards in sections 4–8.
- Use sections 9–10 to write a precise architecture conclusion.
- Finish with the inference exercises and answers.
Back to contents · Next section
1. Separate the questions before choosing a technology label
A useful payment-system description has several columns.
The monetary column identifies the unit and the relevant liability or claim. The operating column identifies institutions responsible for services. The interface column describes what a user sees or presents. The settlement column identifies what event completes the relevant transfer. The technology column describes storage, validation and communication mechanisms.
A fact in one column does not automatically fill the others. A balance denominated in renminbi does not identify a consensus algorithm. A bank logo does not reveal whether a particular back-end component uses a conventional database or a distributed ledger.
A system can also have more than one technical component. A retail interface, an inter-institutional reconciliation service and a cross-border platform need not share a single implementation.
The question “Is it blockchain?” is therefore often underspecified. A better question is: which component, performing which task, at which date, under whose rules?
Back to contents · Next section
2. Read the 2021 architecture description at its own scope
At the PBOC’s 16 July 2021 briefing on the e-CNY whitepaper, the technical explanation distinguished a centralised transaction layer from an issuance-layer unified distributed ledger built using consortium-chain technology.
That historical description already defeats two oversimplifications: it was not a statement that every component was a public blockchain, and it was not a statement that the entire system used no blockchain.
The source describes a particular stage and set of layers. It should not be stretched into a complete inventory of every component operating in 2026. PBOC 2021 briefing
The date in the page’s body is important. A later-looking path in an official website’s URL is not a reason to relabel the briefing as a new technical announcement.
For this lesson, we use only the layer distinction. We do not carry the briefing’s earlier monetary and wallet descriptions forward as timeless facts.
Back to contents · Next section
3. Account for the later framework without turning it into a universal network claim
In an article dated 29 December 2025, authored by PBOC Deputy Governor Lu Lei, the discussion of the framework starting in 2026 identifies customers’ digital-renminbi balances in commercial-bank wallets as account-based commercial-bank liabilities.
The article also describes a hybrid approach combining account-based arrangements with blockchain uses in specified settings, including infrastructure associated with the digital-renminbi international operating centre.
This is an authored primary account, republished from Financial News. We are citing that article, not claiming to have reproduced the full Action Plan itself. Lu Lei’s authored article
The scoped liability statement should not be expanded into a claim about every possible wallet category. Likewise, mentioning a blockchain application in one setting does not establish that every retail transaction follows that same path.
The broader e-CNY introduction discusses the monetary and institutional background. This lesson instead asks how to avoid an unsupported jump from one layer’s evidence to another. Digital Yuan, e-CNY and the New Money Infrastructure
Back to contents · Next section
4. Card A: a screen shows renminbi and a QR code
Imagine a fictional research screenshot. It shows an amount denominated in renminbi, a wallet interface and a QR code. No back-end architecture specification is supplied.
The screenshot supports a description of the displayed unit and interface. It does not identify a blockchain, a block producer, a validation membership policy or a consensus threshold.
A QR code can carry information for an application to interpret. The visible square pattern is not a miniature proof of the database architecture behind the application.
The same interface observation is logically compatible with different back-end designs. If more than one design could produce the observation, the observation alone cannot uniquely identify one of them.
This card is not a claim that a particular e-CNY interface is misleading. It is a deliberately limited evidence packet. The missing information is a source about the relevant component and its actual operation.
A good answer says “architecture not established by this screenshot”, rather than guessing from the visual style.
Back to contents · Next section
5. Card B: the liability is described, but the ledger is not
A second fictional research card contains a dated statement identifying the institution responsible for a particular account-based balance. It says nothing about the database engine or consensus protocol.
This is monetary and institutional evidence. It can be important without being an architecture diagram.
A liability can be recorded through different technical arrangements. Knowing who owes a balance does not, by logic alone, tell us whether storage is centralised, replicated or organised through a particular distributed-ledger design.
This does not make technical architecture irrelevant to reliability. It means that the architecture needs its own evidence.
When reading the later official discussion, preserve the commercial-bank-wallet category instead of reducing it to “all digital money is the same kind of liability”. Then preserve the separate technology question instead of assuming the accounting description answers it.
The mistake to avoid is crossing two boundaries at once: from a specified wallet category to every wallet, and from a liability description to a universal implementation.
Back to contents · Next section
6. Card C: several operators do not imply public validation
A third card names several authorised operating institutions. It describes their service responsibilities but does not say that anyone may join the validation process.
The supported conclusion concerns participating institutions in the stated role. It does not establish permissionless block production or public access to every transaction record.
An operating institution can provide a wallet service, customer support or another function without that role being identical to the role of a validator in a public-chain protocol.
Even if a component uses several organisations to maintain a ledger, the conditions for joining and the permitted actions still need to be specified. “Several participants” is not equivalent to “any participant”.
Counting institutional names also does not reveal the number of independent technical implementations, hosting providers or failure domains. Those are further questions.
This card helps readers separate an organisational diagram from a protocol membership rule. Both can matter, but neither should impersonate the other.
Back to contents · Next section
7. Card D: a programmable feature does not identify an execution environment
A fourth card says that a payment-related service supports a conditional or programmable feature. It does not identify the execution engine, programming language, deployment permissions or validation process.
The phrase “smart contract” does not by itself prove that the feature runs on Ethereum, uses the EVM or permits arbitrary public deployment.
To justify those conclusions, a source would need to identify the actual platform and the relevant conditions. A familiar technical term is not a substitute for those details.
The same caution applies to a demonstration. Seeing a condition trigger an action can establish behaviour in that demonstration. It does not expose every component that produced the result.
A useful architecture question is therefore specific: where is the condition evaluated, who controls the code, which state is authoritative and what evidence shows completion?
This workshop does not answer those questions for an unnamed real service. It explains why the evidence card has not answered them.
Back to contents · Next section
8. Card E: one blockchain component is real evidence, but its boundary matters
Now give the reader a stronger fictional card: an authenticated component specification states that a named reconciliation service uses a permissioned distributed ledger. Its participating organisations and task are identified.
This is evidence about that service. Unlike the screenshot, it actually supplies a technology claim.
However, it does not prove that the user interface, every retail transfer and all external payment connections run on the same ledger. Extending the conclusion requires evidence about those connections.
The 2021 briefing’s layer distinction is a real reminder of this problem. A statement about one layer should retain that layer in the reader’s summary.
The later authored discussion also requires attention to the identified setting. A component associated with an international infrastructure cannot automatically be substituted for the path of every domestic retail transaction.
The correct response to stronger evidence is not to ignore it. It is to state its supported scope accurately: the named component uses the stated technology for the identified task.
Back to contents · Next section
9. Settlement language does not reveal a block format
A fifth kind of observation concerns completion: a source states that a payment or transfer has reached a specified settlement condition.
That is not automatically evidence of a public blockchain confirmation count, a block height or a particular finality algorithm. Those are mechanism-specific concepts requiring their own description.
In a fictional research note, “completed according to the service’s supplied settlement rule” can be a defensible statement while “finalised by the public network’s validators” remains unsupported.
The reader should ask what event was observed, which institution or protocol recognises it and what further conditions remain. A screen label without the underlying rule may not even establish the settlement claim fully.
This distinction also prevents vocabulary from drifting across systems. A term that has a precise meaning in one protocol should not be imported into another merely because both move digital records.
No real payment is being assessed here. The exercise is about the kind of evidence needed to move from a status description to a claim about its mechanism.
Back to contents · Next section
10. Build a five-column architecture note
For each evidence item, write the component and date first. Then place its supported facts into the relevant columns:
- Monetary unit and liability category.
- Operating institution and responsibility.
- Interface or user interaction.
- Settlement event or completion rule.
- Ledger technology, validation rules and participation conditions.
Leave unknown cells unknown. A complete-looking table filled by assumptions is worse than a partial table that accurately reflects the source.
Suppose the fictional packet contains only the screenshot from Card A and the liability statement from Card B. The interface and specified liability cells have some evidence. The consensus mechanism remains blank.
Add the authenticated component specification from Card E, and one named service’s technology cell can be filled. That still does not justify copying it into every component’s row.
Finally, add a dated historical source. It creates a time-bounded row, not an automatic replacement for all current rows.
This method makes architecture inference reproducible. Another reader can see whether the conclusion came from the source or from the analyst’s expectations.
Back to contents · Next section
11. Check seven common conclusions
Consider these invented claims about the evidence cards.
First: “The screenshot contains a QR code, so the payment must use blockchain.” Not established. The interface does not identify the back end.
Second: “A named bank is responsible for the specified balance, so no component can use a distributed ledger.” Not established. Institutional responsibility does not exclude that technology.
Third: “Several operating institutions are named, so anyone can become a validator.” Not established. Participation rules have not been supplied.
Fourth: “The service has a smart-contract feature, so it must use the EVM.” Not established. The execution environment is unspecified.
Fifth: “The authenticated specification identifies a permissioned ledger for the named reconciliation component.” Supported, under the card’s explicit authenticity and scope assumptions.
Sixth: “That component proves every retail payment uses the same ledger.” Not established. The relationship to every payment path is missing.
Seventh: “A historical architecture description should retain its source date and layer.” Supported as the required reading discipline; it prevents the source from being expanded beyond what it describes.
The result is not a claim that the unsupported architectures are impossible. It is a finding that these particular observations do not prove them.
Back to contents · Next section
12. Misconceptions worth correcting carefully
“Digital” means “blockchain”.
Digital describes representation or processing in a broad sense. A specific ledger design needs more evidence.
“Centralised management” means “no distributed component anywhere”.
Management authority and data-processing architecture are separate dimensions. The official layer descriptions should be read at their stated scope.
“Blockchain use” means “cryptocurrency equivalence”.
A technical component does not by itself determine monetary status, institutional liabilities or permission to provide a service. Those facts need separate sources.
“The old description and new description cannot both be useful”.
They can describe different dates, categories or layers. Preserve those boundaries before deciding whether there is a genuine conflict.
“A source mentions the Action Plan, so I have read the full Action Plan”.
No. An authored explanation of a plan and the plan’s complete operative text are different source objects. Accurate attribution should say which was actually consulted.
The goal is precision, not a new slogan claiming that one technology is always present or always absent.
Back to contents · Next section
13. Exercises with explained answers
Exercise 1: The wallet image
The only evidence is a wallet screenshot. What architecture conclusion is justified?
None beyond the supplied interface observation. The ledger and validation mechanism remain unestablished.
Exercise 2: A dated liability statement
A statement concerns commercial-bank wallets under the later framework. Can it be applied without qualification to every wallet category?
No. Preserve the category and date. Other categories require their own evidence.
Exercise 3: The operator list
A source identifies several service operators. Does this establish public validation access?
No. Operating responsibilities and validation participation are different facts.
Exercise 4: A real component specification
A named service’s authenticated specification says it uses a permissioned ledger. Should the reader ignore it because the wider system has centralised management?
No. Record the supported component-level fact. Centralised management does not cancel the specific evidence.
Exercise 5: The expanded conclusion
Can that component-level fact be reported as “all transactions use this exact ledger”?
Not without evidence linking all those transactions to that component and mechanism.
Exercise 6: Historical scope
A 2021 source describes two layers. What should a 2026 article preserve?
The source date, the named layers and the limited claim being used. It should not present the historical description as an exhaustive current inventory.
Exercise 7: Programmability
A conditional payment feature is demonstrated. Does that identify a programming language or public deployment permission?
No. Those details remain unknown unless separately supplied.
Exercise 8: Two unsupported opposites
If neither “all components use blockchain” nor “no component uses blockchain” is established by a screenshot, must one be chosen?
No. The correct answer can be that the evidence is insufficient for either universal claim.
Back to contents · Next section
14. Frequently asked questions
Is e-CNY simply another name for a public cryptocurrency?
That conclusion does not follow. Its monetary and institutional framework must be distinguished from the use of a technology component.
Did the 2021 official briefing say that blockchain was absent everywhere?
No. Its technical explanation distinguished a centralised transaction layer and an issuance-layer consortium-chain ledger.
Does the later framework make every wallet identical?
The scoped statement discussed here concerns commercial-bank wallets. The lesson does not generalise it to all possible categories.
Why avoid a one-word answer?
Because the object may contain several layers. A one-word answer can erase the most important evidence.
Is this a payment guide?
No. It is a technical reading exercise and makes no recommendation about opening or using a financial service.
Back to contents · Next section
15. Sources and further reading
Sources checked on 12 October 2026. The research screenshots, component card and inference tests are invented teaching examples.
- PBOC briefing on the e-CNY whitepaper: 16 July 2021; historical transaction-layer and issuance-layer distinction.
- Lu Lei, “守正创新 稳步发展数字人民币”: authored article dated 29 December 2025, republished from Financial News; later framework and hybrid-architecture context. This citation is to the article, not the full Action Plan.
- Digital Yuan, e-CNY and the New Money Infrastructure: broader monetary and institutional background.
- Alipay, WeChat Pay, QR Codes and the Mobile Payments Economy: broader interface and payment-infrastructure background.
Read the layer, date and role before guessing the network. The strongest conclusion is the one that matches the evidence, even when that leaves some of the architecture unspecified.