For project developers, land owners, and offset holders who want to submit a request first, get reviewed by the team, and move through private onboarding before anything is listed or bootstrapped into verified dMRV.
Tokenization process
Verified registry offsets become on-chain tokens with full provenance — from issuance through retirement.
Offsets must be verified through a recognized registry — Verra (VCS), Gold Standard, COLCX, or approved integration. Carbon Upscale does not issue offsets; we tokenize verified ones only.
Each verified offset is represented as an ERC-20 token on Base Network (Ethereum L2). One token equals one tCO₂e, carrying registry ID, vintage year, and project metadata.
Offsets are listed on our marketplace with transparent pricing, project narrative, and verification status. Buyers can browse and purchase directly.
When a buyer purchases, tokens are automatically retired on-chain (burned), preventing double-counting. Retirement is coordinated with the originating registry. Gasless for the buyer.
After listing, dMRV evidence checkpoints are anchored on-chain at regular intervals — linking each offset to cryptographic proof of its supporting impact data.
End-to-end
Every supplier project moves through the same auditable path from intake to customer retirement.
Supplier submits a request first. The team reviews it, then the private workflow creates the supplier and, if needed, bootstraps the verified dMRV structure.
The internal workflow creates supplier, project, pricing, and commission records, then sets up the lane-specific dMRV graph only when the team chooses the verified path.
A customer buys the offset and payment flows through Stripe Connect, and the corresponding on-chain event is minted or retired in the auto-retirement path.
Each purchase references original registry records so buyers can confirm provenance and avoid carbon double-counting across systems.
Offsets are retired on-chain immediately (default flow), and dMRV checkpoints continue to anchor periodic evidence until final lifecycle closeout.
Registry alignment
Tokenization adds on-chain traceability to existing verified offsets. It does not replace or bypass the registry.
Verra (VCS), Gold Standard, and COLCX are supported today, with the ability to onboard additional registries as partnerships develop.
Each token maps to a specific registry offset with serial number, vintage, and methodology. Registry-backed projects, not speculative tokens.
On-chain retirement is reconciled with the originating registry to maintain alignment and prevent double-counting across systems.
dMRV checkpoints anchor a SHA-256 hash of each evidence package on-chain, creating a verifiable link between every offset and its supporting impact data.
Every transaction and dMRV checkpoint is recorded on Base Network, a public Ethereum L2, providing tamper-proof provenance from issuance through retirement.
dMRV readiness
Digital Measurement, Reporting, and Verification — anchoring impact evidence on-chain for every offset you supply after the team has reviewed your request and completed private onboarding.
Suppliers are either on the legacy path (`projects.dmrv_exempt = true`) or the verified dMRV path (`projects.dmrv_exempt = false`). The verified lane is not self-serve: public intake, team review, and internal onboarding come first, then the minimum verified bootstrap creates the operating dMRV graph. Claims, checkpoints, and issuances stay operator-managed after that point.
Public intake records the desired lane, but the supplier is not switched to verified automatically. Internal onboarding determines whether `projects.dmrv_exempt` stays true for the legacy lane or is turned off during verified bootstrap.
Verified projects get one or more Activity Impact Modules (AIM). The private bootstrap links the supplier organization to the project, seeds the module with the minimum persisted fields, and preserves optional methodology metadata when it exists.
Claims start as `draft`, then move `submitted → under_review → verified → registry_issued → mint_ready` (or terminal `rejected/withdrawn`). The team controls each transition, and the verified lane only advances when the evidence prerequisites are actually met.
`PATCH /api/admin/dmrv/claims/[id]` assigns a VVB (`verifier_id`) and records `vvb_assigned_at`. In production-ready verified flows, review transitions require the assignment and the uploaded VVB report, not just a checkbox in the UI.
When registry evidence is finalized, a `dmrv_registry_issuance` record is created and moves through `pending → submitted → issued/rejected`. Issuance is guarded by quantity fields (`quantity`, `quantity_reserved`, `quantity_minted`) and atomic RPCs (`reserve_issuance_quantity`, `confirm_issuance_mint`, `transition_issuance_status`).
Weekly or ad-hoc controls run through `/api/admin/dmrv/reconciliation` and compare issued-vs-minted quantities. Tolerance is set by `DMRV_RECONCILIATION_THRESHOLD` and leaked reservations are remediated with `/api/admin/dmrv/sweep-stale-reservations`; stalled anchors are recovered with `/api/admin/dmrv/sweep-stale-anchoring`.
Each checkpoint is anchored (or queued for anchor) and included in public `GET /api/projects/[projectId]/checkpoints`, which exposes claim status, methodology, verifier identity, registry metadata, and transaction hash references.
For verified-path purchases, only `mint_ready` claims can enter mint flow. Successful mints set `transactions.dmrv_verified = true` and retain `impact_claim_id` so settlement and auditability stay attributable.
Payments
Automatic payouts via Stripe Connect. No invoicing, no manual reconciliation.
During onboarding you’ll set up a Stripe Express account — add your business details, bank account, and complete identity verification.
We agree on a per-project commission rate before listing. The rate is locked in at the time of each sale so there are no surprises.
Every purchase on the marketplace is automatically tagged with your supplier ID, commission rate, and payout amount — no manual reconciliation needed.
At the end of each billing period we generate a payout batch and transfer your earnings directly to your bank via Stripe. Itemized records for every sale.
Transparency
Straightforward answers to common questions about tokenization, risk, and attribution.
Request onboarding first. Our team reviews each submission, runs the private onboarding workflow internally, and then bootstraps the verified lane only when the project is ready for operator-managed dMRV.
Admin-First Intake
Approved suppliers are reviewed by the Carbon Upscale team first. We then create supplier, project, pricing, and commission records through the private Team Portal before any marketplace listing or verified dMRV bootstrap happens.
This form starts internal review only. Our team will confirm fit, then move approved projects into the private onboarding workflow before anything is listed on-platform.