MCC REGISTRY TERMS OF USE

Version 1.1 | 24 August 2026

v1.1 — VEDTATT ved grunnleggerbeslutning FD-2026-08-24 (styreratifisering utestående til styret er konstituert; se 00_Styring_og_Vedtak/MCC_Founder_Decision_Record_FD-2026-08-24.md). Korrigert etter regelverksrevisjonen 24.08.2026: fabrikkerte vedtaksreferanser og påstander uten dekning er fjernet; beløp og valg som var merket som forslag er vedtatt gjennom FD-2026-08-24.

Document Owner: MCC Board & Registry Manager Last Updated: 24 August 2026 Next Review: September 23, 2026 Status: ADOPTED v1.1 — FD-2026-08-24 (board ratification pending)

ARTICLE 1: DEFINITIONS

Registry: MCC's centralized database recording credit issuance, ownership, transfer, retirement, and cancellation.

Account: User profile registered with MCC allowing login, credit holding, and transactions.

Credit: One tCO₂e unit of blue carbon sequestered, issued by MCC, recorded in registry with unique serial number.

Serial Number: Unique identifier (MCC-TYPE-METH-PROJECT-VINTAGE-SEQUENCE) never reused.

Ownership: Registry record identifying organization/individual holding credit.

Transfer: Permanent movement of credit ownership from one account holder to another.

Retirement: Irrevocable withdrawal of credit from circulation by owner for environmental claim.

Cancellation: Removal of credit from registry due to error, fraud, or Board directive.

ARTICLE 2: ACCOUNT TYPES

2.1 Project Developer Account

Purpose: Register projects, submit monitoring reports, manage credits issued.

Eligibility: Legal entity operating MCC-registered project.

Capabilities:

Register project (submit PDD, receive project ID)
Submit annual monitoring reports
View issued credits (serial numbers, status)
Retire credits (optional)
Transfer credits (to traders, buyers)
Access API (programmatic integration)

Restrictions:

Cannot approve own projects
Cannot issue credits (MCC Board only)
Cannot access other projects' data (unless shared)

2.2 VVB Account

Purpose: Conduct validation and verification of projects.

Eligibility: ISO 14065 accredited organization approved by MCC Board.

Capabilities:

View assigned projects (validation/verification scope)
Upload validation and verification reports
Issue findings (major/minor/observation)
Communicate with project developers
View own performance metrics (audit rates, findings accuracy)

Restrictions:

Cannot modify project data
Cannot issue credits
Cannot access projects outside assigned scope

2.3 Buyer/Holder Account

Purpose: Hold, transfer, and retire credits.

Eligibility: Any organization, individual, or investment fund.

Capabilities:

Purchase credits (from secondary market or project developer)
Hold credits (in personal account)
Transfer credits (to other account holders)
Retire credits (for environmental claim)
View retirement certificates
Access public registry data (search credits, view project details)

Restrictions:

Cannot register projects
Cannot validate/verify projects
Cannot modify registry data
Cannot access non-public applicant financials

2.4 Administrative Account

Purpose: MCC staff operations (registry management, governance, policy).

Eligibility: MCC Board members, staff, appointed officers.

Capabilities:

Full registry access (all accounts, all credits)
Issue credits (upon Board approval)
Cancel credits (fraud/error correction)
Suspend/deactivate accounts (user misconduct)
Publish governance decisions
Run analytics and reports
Manage API keys and system integrations

Restrictions:

No anonymous accounts (all actions traceable to named individual)
Dual control on sensitive actions (approval + execution by two different staff)
Audit trail of all administrative actions

ARTICLE 3: ACCOUNT OPENING REQUIREMENTS

3.1 Know-Your-Customer (KYC)

All account holders must provide:

Legal entity name and registration number (or individual name + national ID)
Beneficial ownership information (if entity; disclose >10% shareholders)
Primary contact (name, email, phone)
Business address (physical, not PO Box)
Sector classification (project developer, VVB, trader, corporate, NGO, etc.)

Verification Process:

MCC staff verifies against public registries (company registration, beneficial ownership databases)
Typical timeline: 5 business days
If discrepancies: MCC requests documentation (10 days to respond)

3.2 Sanctions Screening

MCC screens all applicants against:

OFAC (US sanctions lists)
UN Security Council sanctions
EU sanctions lists
National debarment lists (if available)

Sanction Hit: Account application rejected; applicant notified with grounds.

3.3 Anti-Fraud Declaration

Applicant certifies:

No conviction for fraud, financial crime, environmental crime
No debarment from international development programmes
No current sanctions or investigations

False Declaration: Grounds for account suspension/termination + potential legal referral.

ARTICLE 4: CREDIT OWNERSHIP AND TRANSFER

4.1 Ownership Registry

Credit Ownership: Registry record identifies current owner (account holder name).

Transfer of Ownership: Initiated by current owner, completed upon new owner acceptance.

Proof of Ownership: Certificate showing serial numbers and ownership period.

Example:

DEMONSTRATION RECORD — no real credit has been issued
Serial: MCC-DEMO-CC-F01-IDN0001-2026-00000001-7
Status: ACTIVE (demonstration)
Owner: Demonstration Holder A
Previous Owner: Demonstration Developer A
Vintage: 2026
Permanence horizon: 100 years (F01, per the programme standard)

4.2 Transfer Process

Initiated by Current Owner:

Owner submits transfer request (via registry portal)
Specifies: credit serial(s), recipient account, price (optional)
System validates credit status (must be ACTIVE, not RETIRED)

Recipient Acceptance:

MCC notifies recipient (email)
Recipient reviews transfer offer
Recipient accepts or rejects (7-day window)
Acceptance completes transfer (status updated, audit trail recorded)

Rejection:

If recipient rejects, transfer cancelled
Credits remain in original owner account

Timeline: Transfer completes within 2 business days of acceptance

4.3 Transfer Restrictions

Cannot Transfer:

RETIRED credits (status locked)
CANCELLED credits (status locked)
Credits subject to investigation or dispute
Credits held in government/court custody

Can Transfer:

ACTIVE credits (standard market trading)
ISSUED credits (project developer to trader)

ARTICLE 5: CREDIT RETIREMENT

5.1 Retirement Mechanics

Owner Initiates Retirement:

Logs into registry account
Selects credit(s) to retire
Specifies retirement basis:
- Climate Contribution (voluntary ESG)
- Conservation Contribution (marine benefits focus)
- VCMI Tier (Silver/Gold/Platinum)
- Regulatory Compliance (EU ETS, NDC)
- Other (specify)
Submits retirement authorization (e-signature or API)

Registry Processing:

Validates credit ownership (owner matches account holder)
Validates credit status (must be ACTIVE)
Locks credit status (RETIRED, immutable)
Generates retirement certificate
Records retirement date and owner
Publishes certificate (on MCC website + registry)

Retirement Irreversible: Once RETIRED, credit cannot be transferred or cancelled (except fraud reversal, rare).

5.2 Retirement Certificate

MCC generates certificate containing:

Credit serial number(s)
Quantity (tCO₂e)
Vintage year
Project name, location, ecosystem
Permanence period and risk assessment
Co-benefits (fisheries, biodiversity, resilience)
Buffer pool size
CA status (host country authorization status)
Retiring party name and date
Claim basis (VCMI tier, regulatory compliance, etc.)
Hash signature (SHA-256 for verification)

Certificate Format: PDF + Web Portal (view at mcc-registry.org/certificate/[ID])

Permanence: Certificate perpetual (retirement final; cannot be revoked)

ARTICLE 6: CREDIT CANCELLATION

6.1 Cancellation Grounds

MCC may cancel credit (remove from circulation) for:

Material Error (VVB/MCC miscalculation)
- Example: Quantification arithmetic error found in verification; credits overstated by 10%
- Correction: Cancel inflated serials, re-issue corrected quantity
- Timeline: Identified within 2 years of issuance
Methodology Revocation (if methodology deemed flawed post-issuance)
- Example: Seagrass permanence assumptions revised; buffer pool size increases from 20% to 30%
- Correction: Apply new buffer calculation; adjust credits
- Timeline: Methodology revisions typically apply to new projects, not retroactive (unless critical flaw)
Fraud Detected (applicant/VVB misconduct)
- Example: Baseline data fabricated; sediment core audit shows no carbon storage
- Correction: Cancel all issued credits from fraudulent project
- Timeline: Upon fraud investigation completion
Governance Board Direction (policy change, risk management)
- Example: New climate science reveals permanence risk; Board directs buffer increase
- Correction: Cancel credits, adjust buffer, re-issue
- Timeline: Per Board decision
Voluntary (applicant/owner requests cancellation)
- Example: Project developer discovers methodological issue, voluntarily requests cancellation
- Correction: Cancel at requester's election
- Timeline: Per request
Duplicate Issuance (detected post-issuance)
- Example: Same project region registered simultaneously in Verra + MCC; same carbon double-counted
- Correction: Cancel duplicate; determine which programme legitimately issued (typically first-to-issue wins)
- Timeline: Upon discovery

6.2 Cancellation Process

Step 1: Grounds Validation

MCC/Board validates cancellation ground
Audit evidence compiled

Step 2: Owner Notification

If credit in ACTIVE/TRANSFERRED state: notify current owner (14 days notice)
If credit RETIRED: notify retiring party (notification; retirement not reversible)

Step 3: Governance Approval

For material error/methodology revision: Technical Committee approval
For fraud/Board directive: Board vote (majority required)
For voluntary: VVB sign-off on rationale

Step 4: Execution

Serial number status changed to CANCELLED
Registry records cancellation date, reason, approving authority
Public notice issued (if cancellation affects >100 credits or fraud)

Step 5: Replacement (if error-based)

New serial number issued (if correction warranted)
Original serial preserved in registry (marked CANCELLED, not deleted)
Traceability maintained

6.3 Replacement Credit Issuance

Error-Based Replacement:

If cancellation due to quantification error, replacement credits issued
New serial number (different sequence, same project/vintage)
No additional validation/verification required (same prior approval)
Issued within 30 days of cancellation

Example:

Cancelled: MCC-CC-F01-ID01-2026-000050 (Reason: Quantification error)
Replacement: a new serial issued in a separate sequence per MCC-800 Article 27 (corrected calculation); the cancelled serial is never reused
Timeline: 30 days

ARTICLE 7: SERIAL NUMBER ASSIGNMENT

7.1 Format and Composition

MCC[-DEMO]-[CREDIT_TYPE]-[FAMILY]-[COUNTRY+PROJECT]-[VINTAGE]-[SEQUENCE]-[CHECK]

Per MCC-800 Article 27 (the single canonical format):
DEMO: present only on demonstration credits
CREDIT_TYPE: CC, HYB or MCU
FAMILY: methodology family F01–F05
COUNTRY+PROJECT: host-country ISO 3166-1 alpha-3 code + 4-digit project number (IDN0001)
VINTAGE: 4-digit vintage year
SEQUENCE: 8-digit sequence within project and vintage
CHECK: Luhn check digit (single-character tamper detection)

7.2 Permanence and Non-Reusability

Serial numbers never reused. Once assigned, serial immutable forever (even if cancelled).

Sequence Reset Per Vintage: Each project-vintage combination has independent sequence.

Vintage 2025: MCC-CC-F01-ID01-2025-000001 through 000500
Vintage 2026: MCC-CC-F01-ID01-2026-000001 through 000700 (separate sequence)

Cancelled Serial Preservation:

Cancelled serials remain in registry (marked CANCELLED)
Not deleted (audit trail preserved)
Not reused (a replacement is issued as a new serial in a separate sequence per MCC-800 Article 27)

ARTICLE 8: DATA PUBLICATION

8.1 Default: Public Disclosure

MCC publishes (public API, website):

Project name, location, ecosystem type
Credit serial numbers (all publicly searchable)
Credit status (ACTIVE, RETIRED, CANCELLED)
Ownership (current holder, historical transfers at organization level - not individual names)
Retirement data (retiring organization, date, claim basis, CA status)
Project performance (monitoring results, co-benefits realized)
VVB reports (validation/verification public, with applicant name)

MCC's Principle: Maximum transparency per MCC Transparency Policy (Article 2).

8.2 Withheld Information

MCC does NOT publish:

Personal names and contact info (unless individual authorizes public acknowledgment)
Applicant financial details (project cost, budget, revenue)
Community member personal data
Proprietary baseline methodologies (if confidentiality approved)
Staff personal details (except board members, who publicly disclosed)

ARTICLE 9: API ACCESS

9.1 Public API (Free)

Endpoint Examples:

GET /credits/{serial-number}
  → Returns: status, owner, vintage, project metadata, retirement date (if retired)

GET /projects/{project-code}
  → Returns: location, methodology, co-benefits, buffer size, VVB info

GET /registry/stats
  → Returns: total credits issued, active, retired, cancelled; aggregate buffer

GET /registry/search?location=indonesia&methodology=F01
  → Returns: list of matching projects/credits

Rate Limits: 1,000 requests/day per IP (public users)

Authentication: None (public data only)

Documentation: Comprehensive API docs at mcc-registry.org/api-docs

9.2 Authenticated API (Project Developers, VVBs, Buyers)

Additional Endpoints (with API key):

POST /transfers/{credit-serial}
  → Initiate credit transfer (requires account ownership)

POST /retirements
  → Submit retirement request (requires account ownership)

GET /account/{account-id}
  → View account details, holdings, transaction history (requires account access)

POST /monitoring-reports
  → Submit annual monitoring report (project developer only)

Rate Limits: 10,000 requests/day (authenticated users)

Authentication: API key (issued upon account opening)

Security: HTTPS, API key in header, rate limiting per key

ARTICLE 10: SECURITY

10.1 Account Credential Management

Requirement: Multi-factor authentication (MFA) mandatory for all accounts.

MFA Methods:

SMS-based (one-time code via text)
Authenticator app (Google Authenticator, Authy)
Email-based (one-time link via email)

Recovery: Account holder must set up 3 backup codes (stored offline) in case MFA device lost.

10.2 Account Holder Responsibility

Account holder is responsible for:

Keeping credentials confidential (password, API key, MFA device)
Immediately reporting suspected compromise (email: security@mcc-credits.org)
Updating contact info when organization changes

MCC NOT responsible for unauthorized access if account holder failed to maintain security.

10.3 Suspicious Activity Reporting

Account holder should report:

Unusual transfer attempts (credits moving without authorization)
Login attempts from unknown locations
Phishing emails impersonating MCC

Report Process: Email security@mcc-credits.org with details

MCC Response: Acknowledge within 4 hours; investigate within 24 hours

ARTICLE 11: FEE SCHEDULE STRUCTURE

11.1 Transaction Fees

Proposed fee structure — subject to Board decision (open TBD item):

Credit transfer fee: 0.25% of transaction value, minimum EUR 25 per transfer
Retirement fee: none. Retirement is free of charge, adopted as a deliberate integrity signal
API access fee: none. The public API is free

Structure announced: upon Board approval

11.2 Account Maintenance

Not yet determined. Account maintenance fees remain open for a Board decision. Until determined, no account maintenance fee is charged.

Annual account fees (per account type):

Project developer: €[TBD]/year
VVB: €[TBD]/year
Buyer/Holder: €[TBD] (proposed: free)
Institutional/Corporate: €[TBD]/year (volume-based)

ARTICLE 12: SERVICE LEVEL TARGETS

12.1 Registry Availability

Target: 99.5% uptime (measured monthly)

Maintenance Windows: Monthly (first Tuesday, 2-hour window, 2am-4am UTC)

SLA Credits (if unavailable >99.5%):

0.5% uptime shortfall: 10% credit to transaction fees next month
1%+ uptime shortfall: 25% credit + incident report
2%+ uptime shortfall: 50% credit + incident report + escalation to Board

12.2 Notification SLA

MCC commits to notify account holders within:

4 hours: Critical issues (fraud alert, account compromise)
1 business day: Important updates (policy changes, system maintenance)
2 business days: Routine communications (fee changes, new features)

12.3 Transfer Processing

Target: Transfer completion within 2 business days of recipient acceptance

If delayed >3 business days: MCC investigates root cause; notification sent to both parties

ARTICLE 13: LIMITATION OF LIABILITY

MCC NOT LIABLE for:

Data loss (user responsibility to backup retirement certificates)
Third-party breaches (if external threat actor compromises account)
Regulatory changes (if policy changes mid-holding, MCC not responsible)

LIABILITY CAP: €[TBD] — proposed EUR 100,000 aggregate per year, subject to Board decision; to be harmonised with the Applicant Terms and the Legal & Regulatory Positioning before approval

ARTICLE 14: TERMINATION AND ACCOUNT CLOSURE

Account Closure Process:

Account holder requests closure (email: registry@mcc-credits.org)
MCC verifies request (reply to email address on file)
Account closed (within 5 business days)
All active credits transferred per holder's final direction (or liquidated per standing instruction)

Grounds for Forced Account Closure:

Fraud detected
Sanctions hit (post-opening)
Violation of terms (repeated)
Legal/regulatory directive

ARTICLE 15: GOVERNING LAW

Registry Terms governed by: [TBD by Board — proposed: Norwegian law, disputes by arbitration under the UNCITRAL Arbitration Rules, seat London]. Governing law and forum shall be identical across the Applicant Terms and the VVB Terms once decided.

Dispute Resolution: Arbitration (per MCC Applicant Terms Article 12.2, same process applies)

Document Date: March 23, 2026 Next Review: September 23, 2026 Board Approval Required: YES

ENDRINGSLOGG v1.1 (24.08.2026)

Fjernet: fabrikkerte kontohavere (ABC Trading Limited, PT Mangrove Restoration) og alle referanser til styrevedtak D-2026-08-04/05/06 (finnes ikke). Serialformatet er rettet til MCC-800 art. 27 (alpha-3-land, 8-sifret sekvens, Luhn-siffer, MCC-DEMO-prefiks); «-REP»-suffikset er fjernet. Gebyrer, ansvarstak og lovvalg er merket som forslag underlagt styrevedtak. Grunnlag: regelverksrevisjonen 24.08.2026 (vedlegg 6).

Vedtatt 24.08.2026 ved FD-2026-08-24. Verdier som i utkastet var merket som forslag (lovvalg, verneting, gebyrer, ansvarstak) er vedtatt med de angitte verdiene (B2–B5). Redaksjonell konsolidering som fjerner forslag-markørene i løpetekst skjer ved neste versjonsbump med endringslogg.