PCS POL 002 Digital Representation Tokenisation and Trading Policy_v1.2

Document Control

Document identification

• Document code: PCS-RG-002

• Title: Digital Representation, Tokenisation and Trading Policy

• Scope: Rules governing digital representation of PCS credits, tokenisation, fractionalisation, trading controls, and registry supremacy

• Crediting outcome: Not applicable (governance policy)

Version history and change log

Table DC-1. Revision history

Version	Date	Status	Summary of changes	Prepared by	Approved by
v1.2	TBD	Draft	Draft release for public consultation; alignment with PCS registry controls	PCS	TBD
v1.0	TBD	Draft	Initial internal draft (superseded by v1.2 draft)	PCS	TBD

Superseded versions

No approved superseded versions. Earlier draft iterations are internal working copies only.

Governance note on versioning and archiving

Only the latest approved version of this Policy shall be used. Superseded versions shall be archived and retained for traceability and audit purposes. Printed or downloaded copies are uncontrolled; stakeholders must refer to the PCS-published version as the authoritative current version.

Chapter 1 - Community summary

1.1 What this Policy is

This Policy explains how PCS allows digital representations of PCS credits (including tokenisation and trading) while keeping the PCS Registry as the single authoritative record. It is designed to prevent double counting, misleading claims, and supply inflation while enabling credible digital tools for transparency and market access.

1.2 Why this matters

Tokenisation can improve transparency and trading efficiency, but it can also create serious integrity risks if tokens are created without a one-to-one link to real issued credits, or if tokens are marketed with claims that the registry does not support. This Policy sets hard rules to keep digital representations aligned with registry reality.

1.3 Who this applies to

Actor	Why they are covered
PCS Registry / Secretariat	Approves tokenisation pathways, maintains reconciliation, enforces pauses and freezes when required.
Project Developers / Account Holders	May request tokenisation and must comply with labelling, transfer, and retirement rules.
Token service providers (issuers, smart contract operators)	Must use PCS-approved contracts and follow reconciliation and security controls.
Marketplaces / exchanges / trading venues	Must enforce PCS restrictions, display mandatory disclosures, and prevent prohibited listings.
Data platforms / public dashboards	Must display registry supremacy and current status; must not misrepresent labels or eligibility.

1.4 What you can do vs what you cannot do

Allowed (if PCS-approved)	Not allowed (always prohibited)
Tokenise issued, unretired credits as one-to-one backed tokens where PCS can continuously reconcile supply to registry balances.	Mint tokens that are not backed by issued PCS credits in the PCS Registry (including pre-issuance tokens or forward “credit tokens”).
Issue retirement proof tokens only after registry retirement occurs.	Market tokens as “authorized/ITMO/CA-confirmed/CORSIA-eligible” unless the underlying registry units carry those labels.
Trade only through PCS-approved contracts/venues that enforce pauses, freezes, and label restrictions.	Create fractional tokens if the registry does not recognize fractional holdings and rounding rules.
Display PCS linkage metadata and registry supremacy statements in token metadata and user interfaces.	Represent token ownership as overriding registry status, suspensions, cancellations, or enforcement holds.

1.5 Common scenarios

1

Scenario: Tokenising a newly issued batch

A developer wants to tokenise a newly issued batch of PCS credits.

Outcome: Allowed only if the batch is issued, unretired, not under hold, and PCS can maintain continuous reconciliation between registry balances and on-chain supply.

2

Scenario: Listing PCS-linked tokens as “Article 6 authorized”

A platform wants to list PCS-linked tokens and advertise them as “Article 6 authorized”.

Outcome: Not allowed unless the underlying registry units are labelled as authorized and the claim aligns with PCS rules for Article 6 and claims/labelling.

3

Scenario: Buyer retires tokens and wants an NFT as proof

A buyer retires tokens and wants an NFT as proof.

Outcome: Retirement proof tokens are allowed only after registry retirement is recorded; tokens representing unretired credits must be burned or permanently locked in the retirement flow.

4

Scenario: Underlying credits suspended or cancelled after tokens are circulating

Underlying credits are suspended or cancelled after tokens are circulating.

Outcome: PCS may freeze, lock, or burn corresponding tokens to keep alignment with the registry, and publish corrected records where required.

1.6 What happens if you break the rules

Breach type	Typical PCS response
Unauthorized minting or supply inflation	Immediate freeze/lock, contract pause, enforcement action, and public notice where needed.
Misleading claims or labels	Correction orders, delisting requirement, suspension of access, sanctions, and potential cancellation of units if integrity is compromised.
Failure to reconcile supply to registry	Suspension of tokenisation approvals and mandatory remediation; PCS may require burning/locking to restore one-to-one alignment.
Security failure or fraud event	Contract pause, incident response, remediation plan, and escalation to enforcement procedures.

Chapter 2 - Purpose

This Policy defines how PCS permits the digital representation, tokenisation, fractionalisation and trading of PCS carbon credits using distributed ledger technology (DLT), while maintaining environmental integrity, preventing double counting and misrepresentation, and ensuring that the PCS Registry remains the authoritative record.

Chapter 3 - Scope

This Policy applies to: (a) project-level Genesis NFTs; (b) tokenised representations of issued but unretired PCS carbon credits (Active Credit Tokens); (c) tokenised representations of retired PCS carbon credits (Retirement Proof Tokens/NFTs); and (d) any PCS-approved mechanisms for fractionalisation and trading of tokenised credits.

Chapter 4 - Principle of Registry Supremacy

The PCS Registry is the single authoritative record for the legal existence, status, ownership, issuance, transfer and retirement of PCS carbon credits. Tokens and NFTs are digital representations that must be reconciled to registry records at all times. Where any discrepancy exists between on-chain representations and the PCS Registry, the PCS Registry prevails.

Chapter 5 - Token types and permitted representations

PCS recognises the following token categories.

Token category	Definition
Genesis Project NFT	A single NFT representing a registered PCS project as a whole, for transparency and attribution.
Active Credit Tokens (ACTs)	Fungible tokens representing issued, unretired and transferable PCS carbon credits recorded in the PCS Registry.
Fractional Active Credit Tokens (FACTs)	Fungible tokens representing fractional interests in issued, unretired and transferable PCS carbon credits, where the PCS Registry recognises fractional holdings.
Retirement Proof Tokens/NFTs	Tokens or NFTs representing proof of retirement for specified quantities of PCS credits after registry retirement has occurred.

Chapter 6 - Preconditions for tokenising unretired credits

PCS shall only permit ACTs/FACTs where: (a) the underlying credits are issued in the PCS Registry and are not suspended, cancelled or voided; (b) the project and credit batch meet any applicable eligibility and labelling conditions; (c) PCS can maintain continuous reconciliation between token supply and registry balances; and (d) tokenisation does not create a new claim category beyond what the Registry records.

Chapter 7 - Fractionalisation rules

Where fractionalisation is enabled, PCS shall define the minimum tradable unit and rounding rules. The PCS Registry shall recognise fractional holdings such that the sum of all fractions equals the total underlying credit quantity. Fractionalisation shall not permit the creation of additional credits beyond the underlying issued quantity.

Chapter 8 - Trading and transfer controls

Trading of ACTs/FACTs may occur only through PCS-approved smart contracts and/or approved venues that enforce programme controls. PCS shall implement controls to prevent double spending, unauthorised minting, and transfers from accounts that are suspended or subject to enforcement holds. PCS may impose restrictions on transfers for specific labels, and such restrictions shall be enforced both in the Registry and on-chain where feasible.

Chapter 9 - Minting, burning, retirement and reconciliation

Control	Requirement
Minting	ACTs/FACTs shall be minted only when the corresponding credits are issued and available in the PCS Registry.
Burning/locking on retirement	Where a token holder retires credits, corresponding ACTs/FACTs shall be burned or permanently locked, and the Registry retirement record shall be created.
Continuous reconciliation	PCS shall maintain a mechanism ensuring total on-chain token supply equals underlying registry balances (net of retired, cancelled or voided amounts).
Audit trail and linkage	PCS shall retain immutable linkage between token identifiers/transactions and registry identifiers (project ID, batch, vintage, quantity, status, retirement record).

Chapter 10 - Labels, claims and disclosures

Claims associated with tokenised credits shall comply with PCS claims and labelling rules. Marketing language shall not imply properties not recorded in the PCS Registry. Tokens shall not be labelled or marketed as authorised, ITMO, CA-confirmed or CORSIA-eligible unless the underlying credits are labelled as such in the PCS Registry. User interfaces and token metadata shall state that the PCS Registry is authoritative and that token ownership is subject to programme rules, suspensions and enforcement actions.

Chapter 11 - Legal and compliance controls

PCS requires compliance with applicable laws and regulations, including sanctions, anti-money laundering (AML) and counter-terrorist financing (CTF) requirements where relevant. Participants engaging in token trading may be subject to KYC/AML checks depending on jurisdiction and platform design. PCS does not provide legal advice on whether tokens constitute financial instruments; participants must obtain independent legal advice as appropriate.

Chapter 12 - Smart contract governance and security

All smart contracts used for minting, transfers, fractionalisation, burning/locking and retirement proofs shall be subject to internal review, access control, change control, and appropriate security testing. PCS shall maintain the ability to pause contracts and/or restrict transfers in response to integrity, security, fraud or legal risk, consistent with due process and enforcement procedures.

Chapter 13 - Integrity actions: suspensions, cancellations and voiding

If underlying credits are suspended, cancelled or voided, PCS may impose corresponding on-chain restrictions (freeze/lock/burn) to ensure alignment with the Registry. Where cancellation or voiding affects token holders, PCS shall follow due process and publish corrected records where required.

Chapter 14 - Interoperability and external display

Where tokens are displayed on external platforms, PCS shall require clear, persistent disclosures regarding registry supremacy, status changes, and that token value or utility may be affected by programme actions.

Chapter 15 - Enforcement

Misuse of tokenised credits or associated claims may result in corrective actions, suspensions, revocation of access, public notices, and other sanctions under PCS enforcement procedures.

Chapter 16 - Records and retention

PCS shall retain tokenisation approvals, contract versions, reconciliation records, and linkage records for at least 10 years.

Chapter 17 - Revisions

This Policy shall be reviewed and revised through PCS programme change control procedures.