Skip to main content
Counterparty policies

Registry Terms

Version 1.1Adopted 2026-08-24 · FD-2026-08-24English (Norwegian adoption banner)MCC_Registry_Terms_v1.1.md

Adopted by founder decision FD-2026-08-24. The Board’s first meeting (GB-2026-001, 26 August 2026) took up ratification of FD-2026-08-24 as item 2 and recorded it as ratified as to substance; the resolution itself remains attested, not signed. Published verbatim from the maintained corpus — changes occur only by amendment with a version bump.

Correction notice

Correction notice, 4 September 2026 (revised the same day). The Programme publishes contact details at two domains that do not exist: mcc-credits.org and mcc-registry.org. Both return NXDOMAIN, neither has a mail exchanger, and neither has ever been reachable. Affected here: security@mcc-credits.org — the address this instrument gives an account holder for reporting a suspected credential compromise, in two places — registry@mcc-credits.org (account closure), and mcc-registry.org, twice. The instrument text is unchanged, because amending an adopted instrument is not an administrative act. Until the Board disposes of the point, the working channel for every purpose in this instrument is contact@marineconservationcredits.com or the contact page. A suspected compromise should be reported through that channel and will be treated as urgent. This notice was first served naming only mcc-credits.org; mcc-registry.org was found an hour later by searching the whole corpus rather than one folder, which is the same incomplete-search failure the Programme has now recorded seven times. The earlier notice was not wrong in what it said, and it was not complete. Further correction, 10 September 2026. This instrument also states, under Restrictions, "Cannot issue credits (MCC Board only)" and, under Capabilities, "Issue credits (upon Board approval)." No instrument in force gives the Board a role in issuance: MCC-100 cl. 0175 places that decision elsewhere. The text is unchanged, because amending an adopted instrument is not an administrative act. Until the Board disposes of the point, credit issuance requires approval by the body designated in MCC-100 cl. 0175, not the Governing Board. Recorded with the served-page factual sweep (10 September 2026). Further correction, 14 September 2026. Nine further things on the face of these Terms are wrong. (1) Art. 2.3 admits any organisation, individual or investment fund as Buyer/Holder while art. 13's liability cap remains "€[TBD] — proposed EUR 100,000... subject to Board decision" with no carve-out for death, personal injury, fraud or gross negligence, and art. 15's arbitration-seat election, incorporated from Applicant Terms art. 12.2, is offered there only to "Applicant," leaving a Buyer or Holder no seat choice. (2) Arts. 2.3, 4.3, 11.1 and 14 describe an operating secondary market and a power to liquidate a closed account "per standing instruction," with no venue, execution procedure or power of sale defined anywhere. (3) Art. 1's sole definition of "Credit" ("one tCO2e unit of blue carbon sequestered") omits two of the three credit types art. 7.1's own serial format authorises (HYB, MCU). (4) Art. 5.2 requires every retirement certificate to state "Quantity (tCO2e)" with no branch for the non-carbon MCU credit art. 7.1 authorises. (5) No article anywhere in Article 1 through Article 15 says how the Terms themselves may be amended. (6) Art. 11.1 calls the retirement fee "adopted" while headed itself "Proposed fee structure — subject to Board decision," and art. 13's liability cap and art. 15's governing law remain "[TBD]"/"proposed" in the body while the change log asserts all three were adopted under FD-2026-08-24 items B2-B5, an annex not present in the corpus. (7) Art. 5.1 promises a fraud-reversal exception to irreversibility that arts. 5.2 and 6.2 both deny exists. (8) Art. 9.1 sets the public API rate limit at 1,000 requests/day; MCC-800 v1.1 art. 78 sets the same limit at 100 requests/minute (144,000/day). (9) Art. 6.1(6) resolves a duplicate issuance against another crediting programme by MCC unilaterally deciding "which programme legitimately issued (typically first-to-issue wins)," with no joint-determination mechanism and no jurisdiction over the other programme's decision. The text is unchanged, because amending an adopted instrument is not an administrative act. Each of these nine points governs until the Board disposes of it. Recorded with the A5 served-instrument cross-reference (14 September 2026) for the Governing Board of 23 September 2026.

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:

  1. Legal entity name and registration number (or individual name + national ID)
  2. Beneficial ownership information (if entity; disclose >10% shareholders)
  3. Primary contact (name, email, phone)
  4. Business address (physical, not PO Box)
  5. 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:

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

Recipient Acceptance:

  1. MCC notifies recipient (email)
  2. Recipient reviews transfer offer
  3. Recipient accepts or rejects (7-day window)
  4. 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:

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

Registry Processing:

  1. Validates credit ownership (owner matches account holder)
  2. Validates credit status (must be ACTIVE)
  3. Locks credit status (RETIRED, immutable)
  4. Generates retirement certificate
  5. Records retirement date and owner
  6. 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:

  1. 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

  2. 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)

  3. 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

  4. 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

  5. Voluntary (applicant/owner requests cancellation)

    • Example: Project developer discovers methodological issue, voluntarily requests cancellation
    • Correction: Cancel at requester's election
    • Timeline: Per request

  6. 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:

  1. Account holder requests closure (email: registry@mcc-credits.org)
  2. MCC verifies request (reply to email address on file)
  3. Account closed (within 5 business days)
  4. 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.