What the governing body should require for crypto-asset and blockchain governance oversight

Authority disclaimer. This page is an executive narrative. It does not establish requirements; the linked corpus governs. It is provided to support understanding, discussion, and decision-making by the governing body and accountable executive leadership (board, ELT, or senior management, as applicable). It creates no obligation, control, or assurance by itself. Its publication approval is an editorial act only and confers no authority over any corpus document. Where it differs from a corpus document, the corpus document prevails.

Crypto-asset and blockchain activity concentrates several governance exposures at once: assets that can be irreversibly lost if keys are mishandled, stable-value tokens whose holders rely on a backing the organization must actually hold, disclosures that carry legal liability, and third-party providers and smart-contract code the organization does not fully control. The governing body's oversight question is not whether the organization uses crypto-assets, but whether it can require, and see in evidence, that each activity was classified and approved before it began, that client and reserve assets are safeguarded, that holders are properly disclosed to, that providers and code dependencies are vetted, and that all of it is inventoried and kept current. Each of those expectations maps to a specific control in the crypto corpus that an executive can ask to see.

• The crypto-asset governance framework is the dependency of the rest of the domain: it sets classification-before-activity and an activity-approval gate as the precondition for the other controls, requiring a crypto-asset to be classified and the activity approved before it is issued, offered, custodied, traded, or otherwise used.
• The digital-asset custody standard makes a contribution to safekeeping: segregation of client from proprietary assets, wallet tiering, split-knowledge and dual-control key custody, and a register of positions.
• The reserve and prudential standard makes a contribution to holder protection where the organization issues an asset-referenced token, or a significant e-money token under Article 58: reserve constitution and coverage of the claim, legal and operational segregation, the redemption right, and the recovery and redemption plans.
• The white-paper content and disclosure standard makes a contribution to holder disclosure: it governs the white-paper document across the asset classes and the disclosure-linked rights and liabilities.
• The service-provider vetting standard is a prevention control against engaging an unauthorized or unfit provider: its legal-identity-and-authorization gate is a mandatory stop where a required authorization is missing or an identity does not match.
• The crypto-asset inventory register is the evidence for the classification, approval, and inventory controls: the authoritative record of assets held, wallets and custody, platforms, and deployed contracts.

Two further controls round out the domain: the smart-contract and oracle risk standard is a prevention control for smart-contract deployment and oracle risk, and the regulatory-submission standard makes a contribution to the organization's authorization and ongoing regulatory submissions. For an organization in scope of the EU regime, the MiCA implementation annex makes a contribution to the applicability determination, as a navigation aid rather than a required layer.

• Require classification and approval before activity, not after. The corpus makes classification the first control; oversight that accepts "we will classify it later" stops before the corpus starts.
• Expect evidence, not assurances. The inventory register, the reserve audit result, the register of positions, and the provider authorization record are evidence classes; a control the organization cannot evidence is not demonstrably operating.
• Third-party custody does not remove the organization's controls. Engaging a third-party custodian does not lift the provider-vetting gate or the custody standard's requirements; both still apply.
• Asset-referenced tokens carry a distinct prudential burden. For an asset-referenced token, or a significant e-money token under Article 58, reserve backing, redemption, and the recovery and redemption plans are a separate control set from client-asset custody; an organization in both positions runs both.
• Regime status is fact-dependent and the organization's own. The classification and which obligations attach are the organization's determination; the annex is navigation, not a legal conclusion.

• The crypto-asset inventory, recording each asset's classification and activity-approval status and date.
• The register of positions and the custody-arrangement evidence, showing client-from-proprietary segregation and key-custody controls.
• For any asset-referenced token issued (or significant e-money token under Article 58), the reserve composition and the independent reserve-audit result, and the redemption and recovery/redemption-plan evidence.
• The white-paper record, where one is required for the asset, and its notification, approval, or publication evidence.
• The provider authorization and vetting record for each engaged crypto-asset service provider, and the smart-contract deployment and change-governance record for each deployed contract.

This page is a non-normative executive narrative that creates no compliance by itself; the linked corpus documents govern, and where this page and a corpus document differ, the corpus document prevails. It routes to the corpus rather than reproducing its values: the specific thresholds, coverage ratios, retention periods, audit and notification clocks, key-management assurance levels, and classification definitions live in the linked standards and are not restated here. Whether a given obligation attaches, and under which regime, is the organization's own fact-dependent determination.