Platform overview

The institutional carbon-credit infrastructure.

Tokenized at the source registry, settled on-chain, retired with cryptographic proof, and reconciled continuously against off-chain holdings. Built for the firms that take carbon seriously.

The problem

Registries don't talk to each other.

Verra credits live in Verra's database. Gold Standard credits live in Gold Standard's. Puro's in Puro's. Moving credits between them, retiring against a CSRD report, or proving ownership to an auditor still means portals, screenshots, and PDFs.

Retirement is manual: log into the registry, fill a form, receive a confirmation email, attach it to your sustainability report. Hope the auditor accepts the screenshot.

Trading desks can't even price these instruments meaningfully because there's no settlement layer they trust. The market clears in OTC voice trades and trust relationships.

The solution

One settlement layer. Every registry.

Credits are locked at the source registry, mirrored on-chain as ERC-1155 batches with 1:1 backing, and continuously reconciled via a Chainlink Proof-of-Reserve oracle. If the on-chain supply ever drifts from registry holdings, the bridge auto-pauses before anyone can mint another token.

Retirement burns the ERC-1155 and mints a soulbound ERC-721 certificate. An off-chain worker closes the loop at the registry and writes the proof URL back to the certificate. One on-chain action. Full audit trail. Permanent.

Trading happens on top — CLOB, RFQ, pools (ERC-20 wrappers around eligibility rules), forwards (ERC-3525 pre-issuance offtake). Compliance-gated tokenized funds (ERC-3643) distribute to qualified institutional investors only.

Built for

Six tenants. One infrastructure.

Every action below is role-gated. A buyer sees a portfolio. A developer sees their projects. A trader sees a book. An auditor sees the world but can't change it. The platform operator (PGIM / AssetX) runs the whole thing — and white-label distribution partners run their own front-of-house on top of the same rails.

Each card below shows the status quo that persona lives with today and the specific reason this platform makes them switch. The short version: buyers come for institutional-grade carbon they can actually disclose; developers come for capital they can't get anywhere else; trading desks come for the first institutional venue in a fragmented market; auditors come because the platform makes their job possible; operators come because consolidating the back-office onto one console is the only way to actually run this kind of business; distribution partners come because building it themselves would take half a decade and $50M+ they don't want to spend.

Institutional Buyer

Asset managers, insurers, pension funds, family offices, corporate treasuries — anyone retiring carbon under a fiduciary mandate or a net-zero commitment.

Today

Carbon credits live outside your trading stack — Aladdin and Charles River don't know they exist, your custodian can't hold them, and CSRD evidence is screenshots from a registry portal.

Why they switch

Credits sit in Fireblocks / Anchorage alongside your other tokenized assets. KYC-gated tokens that satisfy compliance. Sleeves enforce your internal carbon policy. CSRD ESRS E1-7, SBTi, and TCFD report packs generate from the same on-chain data you already hold. The pitch isn't "buy carbon credits" — it's "manage your carbon book the way you manage your fixed-income book."

What they do here
  • Hold tokenized credits as ERC-1155 batches in institutional custody (Fireblocks / Anchorage)
  • Retire on-chain → soulbound certificate carrying the upstream registry proof
  • Generate CSRD / ESRS E1-7 / SBTi / TCFD packs straight from on-chain data
What you'll see in the demo

Retire 1,000 tCO2e from your portfolio. Watch the certificate appear, click into it — the registry proof URL is right there.

Open this tenant's demo

Project Developer

The supply side — forestry coalitions, biochar facilities, DAC plants, peatland restoration SPVs. The people actually producing the credits.

Today

Credits don't issue for two-to-three years after project start, but operating costs hit immediately. Existing markets only give you spot liquidity at issuance — almost nothing before.

Why they switch

Two unlocks. First, institutional buyers you can't otherwise reach — PGIM's distribution network is fundamentally different from a Verra account-holder list. Second, forwards (ERC-3525) let you monetize credits before issuance: lock in a $180/tonne strike with a buyer 18 months ahead of delivery, take 50% upfront, finance the project. The operational layer is the price of admission; the developer financing story is what makes you switch.

What they do here
  • Submit projects through a vetted intake pipeline (PDD, methodology, geographic boundary, MRV)
  • Request tokenization once credits are issued at the registry
  • Sell forward tranches (ERC-3525) — pre-issuance offtake against future deliveries
What you'll see in the demo

Submit a new project, request 5,000 tonnes for tokenization, watch it move into the operator's queue.

Open this tenant's demo

Trading Desk

Buy-side prop desks and standalone market makers — specialists who care about microstructure, not portfolio NAV.

Today

Existing on-chain carbon markets are retail-grade — order books too thin, counterparties unscreened, settlement finality unclear, no path into the firm's main trading stack. Most desks have looked and walked away.

Why they switch

First institutional-grade carbon venue: allowlisted KYC'd counterparties, T+0 on-chain DvP settlement for OTC, RFQ that mirrors what you already use for OTC bonds and FX, real depth-of-book on standardized contracts, and Sylvera / BeZero / CCP ratings embedded in the trading interface — see a credit's quality without leaving the screen. For prop desks, structural alpha from fragmented quality pricing; for market makers, a clean venue to make markets in size.

What they do here
  • CLOB + RFQ workflows over tokenized credits, with hotkeys and cancel-all panic buttons
  • Cross-pool subscriptions and redemptions (ERC-20 wrappers around eligibility-rule baskets)
  • Forward-market participation: split / merge / transfer of ERC-3525 tranches
  • Lot-level cost basis with FIFO / LIFO / specific-ID accounting; FIX-style blotter export
What you'll see in the demo

Place a limit order on the Atlantic Forest REDD+ book. Fills against a maker. ERC-1155 transfers settle.

Open this tenant's demo

Auditor / Regulator

External assurance firms verifying CSRD / SBTi disclosure, regulators inspecting platform conduct, internal audit at PGIM and partner firms.

Today

Auditing carbon claims is forensic work — retirements scattered across registries with inconsistent APIs, evidence in PDFs and screenshots, no single immutable record of chain-of-custody from issuance to retirement.

Why they switch

The audit job becomes mechanical instead of forensic: live reconciliation matches every token's on-chain supply to registry holdings, every retirement links to its underlying serial numbers and registry retirement statement, every privileged action (mints, freezes, force-transfers, role grants) is logged with Safe transaction evidence, and a Live Invariants panel shows whether the platform's core guarantees currently hold. Turns "carbon claims are unauditable" into "carbon claims have a richer audit trail than most TradFi assets."

What they do here
  • Read-only access to reconciliation, retirements, mints, role assignments, and event log
  • Cryptographic verification of audit packs (SHA-256 hash recompute)
  • Live Invariants panel — see whether the platform's guarantees currently hold
  • Annotate records during investigation (internal-only)
What you'll see in the demo

Pull up the daily reconciliation dashboard. Verify the audit pack integrity hash. Drill into any retirement.

Open this tenant's demo

PGIM / AssetX (Platform Operator)

The master tenant. Bridge operators, compliance officers, smart-contract admins, treasury, product. Not customers of the platform — they are the platform.

Today

The alternative is stitching together Verra account portals, Fireblocks dashboards, Etherscan tabs, manual Safe transactions, ad-hoc fee spreadsheets, and email threads for KYC reviews.

Why they switch

Consolidated operating console for the entire business: bridge ops queue replaces a dozen registry portals, compliance gates every freeze and force-transfer through proper multi-sig with court-order doc capture, smart-contract panel surfaces every upgrade and role grant with timelock visibility, treasury tracks every basis point across six fee streams, BI dashboard answers "is this business working?", and the distribution-partner panel onboards a private bank as a white-label tenant without engineering involvement. If this surface is sloppy, the rest is a marketing site.

What they do here
  • Bridge ops: verify registry locks, sign attestations, submit mints via multi-sig
  • Compliance: KYC review, freezes, force-transfers, sanctions-hit response
  • Smart-contract admin: upgrades, role grants, emergency pauses — all timelock-gated
  • Treasury: track six fee streams; distribution: onboard white-label tenants
What you'll see in the demo

Inject drift through the admin panel. Watch the bridge auto-pause. Unpause via the multi-sig flow.

Open this tenant's demo

Distribution Partner

White-label tenants — private banks, insurers, asset managers offering tokenized carbon to their own clients without building the infrastructure.

Today

Building this in-house is 18 months and $50M+ of engineering, legal, and registry-partnership work that doesn't differentiate your private bank or insurance franchise.

Why they switch

A complete carbon product you can brand as your own: clients see your logo and your domain, but the registry bridge, smart contracts, KYC infrastructure, and reporting engine are PGIM's. Custom pool offerings, jurisdictional rules, and fee schedule per tenant. Pay a revenue share on the volume your client base generates; skip the build cost. For PGIM, this is the leverage layer — every white-label tenant is an embedded distribution channel that scales the business without scaling the headcount.

What they do here
  • Run a branded carbon product on PGIM's infrastructure — your domain, your logo
  • Configure your own pool offerings, jurisdictional eligibility rules, and fee schedule
  • Onboard your client base; PGIM handles the bridge, contracts, KYC, and reporting
What you'll see in the demo

Watch the operator onboard a white-label tenant. Same platform, different brand surface, isolated tenancy.

The flow

From registry, to chain, to retirement.

Every credit on the platform makes the same trip. The infrastructure doesn't care which registry it came from — every adapter speaks the same EAS attestation schema.

01

Lock at registry

Credits move into the platform's account at Verra / Gold Standard / Puro. The off-chain registry holds them in immobilization.

02

Attest + mint

Our trusted attestor signs an EAS attestation. The bridge mints a 1:1 ERC-1155 batch to the buyer's wallet.

03

Trade or pool

Buyers hold, trade on the CLOB / RFQ desk, or deposit into eligibility-rule pools (ERC-20 wrappers).

04

Retire and certify

Retirement burns the ERC-1155 and mints a soulbound ERC-721 certificate. The registry-sync worker retires the upstream credits and writes the proof URL back.

About this demo

What's real, and what's simulated.

Real
  • The chain. Polygon mainnet. Every transaction you see is verifiable on Polygonscan.
  • The contracts. All 11 contracts (registry, bridge, batch token, retirement, certificate, oracle, pools, forwards, compliance wrapper) deployed and operational.
  • The attestations. Signed against the canonical Ethereum Attestation Service contract. The trusted attestor key is held by the platform.
  • The retirements + certificates. On-chain ERC-1155 burn → soulbound ERC-721 mint → registry-sync close-loop. End-to-end.
Simulated
  • The registries. A “Sandbox Registry” service stands in for Verra / Gold Standard / Puro. Same API shape; mock inventory of fake projects. The on-chain stack genuinely can't tell the difference — the bridge only verifies the attestation, not the registry behind it.
  • The payment token. A platform-deployed mock USDC contract. Mintable freely by demo accounts.
  • The KYC / compliance approvals. Pre-approved for the demo wallet. Real onboarding lives behind the wizard at /onboarding.
  • Time. Daily reconciliation runs every 60 seconds. Multi-sig timelocks compressed for demo cadence.
The point. Everything the platform itself does is real. The pieces being simulated are the ones that need partnership signatures, not engineering — and the moment those partnerships close, the same code points at real Verra instead of mock Verra. No rewrite.
Ready

Open the demo.

Six tenants. One infrastructure. About nine minutes start to finish. Every transaction lives on Polygon mainnet.

Demo build · Polygon mainnet · Sandbox Registry mode