V19 · Carbon

1. This volume — two instruments, one owner

Settlement told you how many megawatt-hours the plant produced. This volume is about what those megawatt-hours mean as certificates and as emissions: who may claim them, how they are issued in an external registry, and how the money for them rides an invoice.

The platform is a mirror, not a registry. It accrues what should exist from FINAL settlement, records what zaRECs or I-REC actually issued, and refuses a claim that would count the same megawatt-hour twice. A wrong invoice can be credit-noted. A published green claim cannot be unpublished.

Where this is taught. The volumes certificates ride on — V8 · Settlement. The documents certificate money rides on — V15 · Billing. Come back here when the question is “who owns this REC, and what may I say about it?”

The two instruments

They are never mixed. A REC is not a carbon credit. Reporting that your plant avoided tonnes is not the same as holding a tradable offset.

Three rooms, one journey

The organisation sidebar group Carbon holds three rooms. They are different jobs. Think of them as a workshop with three benches: one measures the tax year, one is the shop where you buy and sell, and one is the cupboard that keeps the certificates and the paper trail.

Tax appears only when the organisation has a carbon participant profile. Market and Certificates are on the sidebar for every organisation seat.

flowchart LR
  A[Measure the year in Tax] --> B[Buy or sell in Market]
  B --> C[Hold and prove in Certificates]
  C --> D[Retire for a claim or surrender for tax]
  D --> A

The same certificate can pass through all three rooms. Buying it in Market does not retire it. Holding it in Certificates does not reduce the tax. Each room says what is still missing.

How this volume is ordered

Chapters 2–8 explain the instruments, the lifecycle, and the rules that stop one megawatt-hour being claimed twice. Chapter 9 is the Certificates room as it is laid out now. Chapters 10–11 put prices in contracts and on invoices. Chapters 12–13 are the emissions statement, opened from Certificates → Claims & reporting. Chapters 14–15 are offset projects. Chapter 19 is the portfolio inside Certificates. Chapter 20 is the Market room. Chapter 21 is the registry pipeline. Chapters 16–18 and 22–23 close with a worked year, the reference card, and a worked trade.

Follow along. Seat: OffTaker C (offtaker_c@webill.net, password supersecret). Path: Organisation → Carbon → Certificates. You should see the heading From issued asset to supported claim, an Issuance & reporting month control, and the tabs Overview, Portfolio, Registry pipeline, and Claims & reporting. A generator seat also sees Origination.

2. RECs and carbon — what they are, and the one-MWh-one-owner rule

The offtaker’s problem is a sentence in next year’s report: this site ran on renewable electricity. That sentence is only true if a certificate for those megawatt-hours is retired in their name, and nobody else is saying the same thing about the same electrons.

Three things people conflate

1. A REC is a certificate that 1 MWh of renewable electricity was generated. Retiring it is how you make a market-based Scope 2 claim.
2. A carbon credit is a verified tonne of avoided or removed emissions. Most generator sites never mint one. Eligibility is recorded as data; the platform never infers it from the plant type.
3. Avoided-emissions reporting is arithmetic on a statement (renewable MWh × a published factor). It is not a credit. It does not travel. It does not zero anyone’s Scope 2.

The one-MWh-one-owner rule

At any moment a megawatt-hour is claimed by exactly one party, or by none. If the REC was sold unbundled, the energy buyer cannot zero their market-based Scope 2 with it. If a registered project issued a credit on the same generation, the same party cannot also retire a REC on it.

The five conservation rules that enforce this are in §08. The write-time guard is on the allocation action, not on the screen.

3. Where certificates come from — FINAL settlement, whole units, carry

The IPP’s problem is: settlement just closed the month at 1,247.3 MWh. How many certificates exist?

Whole units only. A certificate is an integer. The platform floors the FINAL metered generation (plus last month’s leftover fraction) to whole megawatt-hours and carries the remainder. That carry is the seller’s property — it is not rounded away.

June FINAL supply     1,247.3 MWh
May carry                 0.8 MWh
                        ───────
Total                 1,248.1 MWh
Certificates issued       1,248
Carry into July           0.1 MWh

Conservation: Σ certificates × 1 MWh + carry == Σ settled generation to the watt-hour. If that identity ever fails, a certificate leaked.

What does not accrue

• Provisional, draft, disputed or reversed periods contribute nothing.
• A site whose every PPA has REC terms disabled produces no batch — absence, not a zero row.
• Carbon credits are not accrued from generation. They exist only when a verifier issues against a registered project (§14).

The monthly worker

WB.Carbon.Workers.CertificateRunner runs at 04:45 on the 1st, after chain reconciliation (04:00) and statements (04:30), before the issuer (05:00). A batch accrued at 04:45 cannot be invoiced at 05:00 — a human has not confirmed it. Certificate money rides a later month’s issuer run. That is correct, not a latency bug.

If the month is re-settled and the batch is still ACCRUED or REVIEWED, the worker rebuilds it. Once it is SUBMITTED or ISSUED, a variance is recorded and the issued batch is left alone.

Where this is taught. FINAL vs provisional — V8.

4. The certificate lifecycle — states, who confirms what

The registry officer’s problem is: the platform thinks 1,248 certificates exist, but zaRECs has not issued them yet. What may you claim in the meantime?

Nothing that looks like issuance. The batch starts ACCRUED — a prediction from FINAL settlement. A human confirms it (REVIEWED), submits it to the registry (SUBMITTED), then records issuance with a serial range, an issue date, and a hashed evidence file (ISSUED). Only then may it be allocated.

:BLOCKCHAIN as a registry is a valid contract term and a valid account, but issuance is refused (registry_mechanics_undefined). Empty source_refs (no settlement lineage) is also refused.

The Desk never invents a serial. You paste what the registry printed.

5. Allocations and bundling — delivered MWh, retained inventory

The IPP’s problem after issuance: who gets how many certificates?

Bundled PPAs take certificates in proportion to delivered MWh that month (largest-remainder so the parts sum exactly to the issued quantity). Unbundled PPAs take none — the energy buyer bought electrons, not the green claim. Whatever is left is a first-class retained row for the generator, not the absence of a row.

The preview is hashed. Confirming a stale preview is refused. Writing an allocation that would make Σ allocations > issued is refused at the action (over_allocated), not in the UI.

Priced allocations queue for the next issuer run. Unpriced ones do not become invoice lines.

Where this is taught. Bundling as a contract term — V7 §4 and §10.

6. Registries and evidence — zaRECs, I-REC, hashed documents

There is no registry API in this version. You file in zaRECs or I-REC (or record that a blockchain account exists), then you upload or paste the confirmation. The platform hashes it into the same artifact store billing uses. A retirement without that artifact is refused.

Each organisation needs a registry account (account ref, optional device registration, status). Submitting a batch without an active account is a desk warning (registry_account_missing). Issuance still requires the serial and the hash.

CS2 (registry mechanics) is an open research spike. The interim position is manual-first. When an API lands, the evidence row stays — it is the audit trail either way.

7. Retirement and claims — what your auditor will ask for

Holding a certificate is not claiming it. Retirement is the event: a quantity, a purpose (scope2_claim, tax period, voluntary), a claim period, a beneficiary, a hashed registry certificate, a timestamp.

The Claims tab is that register. Over-retiring an allocation is refused (over_retired). The auditor’s pack is the claim row plus the traceability report.

A 12-month advisory flag on holdings is not expiry. Registries have their own rules; the flag exists so last year’s certificates do not sit unretired into the next reporting year by accident.

8. Non-double-counting — five rules and the traceability report

A published claim that counts the same megawatt-hour twice is the failure mode this volume exists to prevent. Five rules, callable as a report, and two of them also sit on writes:

1. Σ allocations ≤ issued (write-time).
2. Market-based coverage ≤ retirements (holding is not claiming).
3. Unbundled energy contributes zero covered MWh.
4. Trader conservation: certificates in = certificates out + Δinventory.
5. REC vs credit exclusivity on the same MWh for the same party.

The traceability report walks allocation → batch → settlement period → intervals. A broken source_refs chain is reported as unresolvable at the named hop, never as a shorter clean-looking chain. Download it from a claim as PDF.

Where this is taught. The seller warranty in the contract — V7 §4.

9. The Certificate Desk — /org/certificates

You need one place that answers three questions: what do I hold, what is blocked, and what do I do next? That place is Certificates.

Open Carbon → Certificates. The page title is Certificates. The heading is From issued asset to supported claim. The sentence under it says the portfolio is live, and the month selector controls issuance and reporting.

Follow along. Seat: OffTaker C. Path: Carbon → Certificates. You should see four tiles on Overview, then three cards labelled 01 · Originate or acquire, 02 · Prove & hold, and 03 · Retire & report.

The month is not the portfolio

The control is labelled Issuance & reporting month. The arrows beside it move one month at a time. Changing the month changes REC issuance, allocation, the emissions statement, and the Green Statement download. It does not freeze the cupboard of lots. Lots you hold today stay on Portfolio whichever month you pick.

Green Statement PDF and CSV sit at the top right. They download the statement for the selected month (GET /org/certificates/green-statement.pdf?month=YYYY-MM and the matching .csv). If that month has no statement, both controls are present and disabled, with the hint No Green Statement for this month. A disabled button is not a zero statement.

If a cross-check has flagged a holding, a red banner CAD Trust: double-count suspect appears above the month. Listing and retirement stay blocked on those holdings until an operator resolves the incident. A green banner lists incidents already resolved. The words are taught in §8 and §22.

Five destinations, not nine peer tabs

Older builds put Accruals, Allocations, Holdings, Claims, Emissions, Portfolio, Trading, Pipeline and Projects on one bar. They are still the same jobs. They are now grouped so you pick a purpose first, then a detail.

The top bar is labelled Certificate lifecycle. Which tabs you see depends on your seat. A generator sees Origination. An off-taker does not.

A second bar, Certificate workflow detail, appears when the destination has more than one view.

The old address ?tab=trading still opens. It is not on the bar. It shows a short Open interest note — how many of your listings and orders exist — and a button Open carbon market. The book itself is §20. On Portfolio, Manage trading commitments goes straight to Market → Orders & listings.

Under the bars, one sentence states the purpose of the view you are on. Read it before you act. It is the same sentence as the tab’s tooltip.

Overview — position, then the next step

Four tiles:

The next-step panel changes with what is wrong:

• A double-count incident: Resolve the double-count incidents first.
• Something awaiting verification: Complete the evidence for your external holdings.
• Nothing held: Bring issued certificates into the portfolio.
• Otherwise: Choose the purpose before using a holding.

The buttons under that panel are Register & retire, Review registry steps, and Open market. They are shortcuts, not new jobs.

Three cards repeat the journey in order. Establish the asset counts REC batches in the selected month and, for a generator, links Review issuance. Keep an auditable chain counts external blocks on the registry pipeline and links Inspect provenance. Substantiate the claim counts retirement claims in the calendar year and links Review reporting.

A grey panel, Three different measures, keeps the units apart:

• 1 REC = 1 MWh — an electricity attribute, useful for a renewable-energy claim only after retirement.
• 1 carbon credit = 1 tCO₂e — a registry-issued reduction or removal. Tax use still needs the project and the surrender papers.
• Avoided emissions = a reporting estimate — a calculated comparison. It is not, by itself, an issued credit or a tax offset.

Portfolio

Lots & provenance is the live cupboard. §19 teaches the tiles, the drill-down, and the dialog Record an agreed bilateral trade.

Register & retire is where a holding you already own outside WeBill comes in, and where a completed retirement is recorded. The purpose line says a declaration establishes custody, a registry statement supports evidence review, and only connector confirmation establishes verification. The honesty ladder — declared, evidenced, confirmed — is in §19.

Origination

This destination exists when your seat issues or allocates certificates.

REC issuance reviews batches accrued from energy that has reached FINAL settlement, then the hand-off to the external registry. WeBill does not issue the certificate. A month with no FINAL settlement shows an empty state, not a batch of zero. The mechanism is §3.

Allocation reconciles issued RECs between contracted buyers and what you keep, before you confirm the split. §5.

Carbon projects follows validation, verification, and registry issuance. Verified avoided emissions become credits only when a registry issues them. §14. Templates on this view do no arithmetic. Every figure is a field the desk already computed. You mirror a verified issuance from here. If the verification is missing, the refusal is named verification_required.

Registry pipeline

Each external credit is a block with its registry and its verification state. The operator records a completed stage against evidence. Buying or holding the credit does not complete a surrender. An empty pipeline says No external credit blocks on the COAS pipeline yet. The stages themselves are §21.

Claims & reporting

Emissions statement shows the two greenhouse-gas methods for the selected month, and any detector findings. §12 and §13. Rand figures that come from the reference price are estimates. They are not invoice prices.

Retirement claims lists claims in the year: quantity, purpose, and period. A claim uses the certificates up. The same unit cannot support a second claim. §7. The traceability PDF for one allocation is GET /org/certificates/traceability.pdf?allocation_id=….

What this room will not pretend

A purchase, an estimate, or an uploaded file is not a finished claim. The screen keeps RECs, issued carbon credits, and avoided-emissions estimates in different sentences. Declared, evidenced, and confirmed holdings stay different states. A partial retirement leaves the rest of the lot available. If the custody change fails, the claim is not left behind as if it had succeeded.

10. Certificate terms in contracts

The negotiator’s problem: the RECs & Carbon step used to have four attributes. It now has seven, and a digest that moves under a new default would break in-flight proposals.

What was added

Completeness: UNBUNDLED and priced requires a positive REC price; carbon enabled and priced requires a positive offset price.

Where this is taught. Field-by-field in the wizard — V7 §4 Step 9 (physical) and Step 7 (virtual).

11. Buying and selling certificates

The trader’s problem: they hold 400 unbundled RECs and have a buyer. Who is allowed to put that on an invoice?

GENERATOR_SITE and TRADER_SUPPLY may issue :rec and :carbon on an invoice, not a credit note. Eskom and the Market Operator may not. A line’s quantity_kwh is empty — a certificate is not energy. Provenance is certificate_allocation:<id>.

VAT on these lines is interim standard-rated (C1, named constant interim_standard_pending_c1) until CS1’s tax opinion lands.

The issuer runs at 05:00. Accrual ran at 04:45. Confirmed, priced allocations therefore bill on a later run. Inventory is the allocation you still hold: retired and sold-external rows do not invoice.

What you actually hold — lots, custody, serials — is the Portfolio tab.

Where this is taught. Who issues what — V15 §4. Charge groups — V15 §7.

12. Your emissions statement

Open Carbon → Certificates → Claims & reporting → Emissions statement (/org/certificates?tab=emissions). Pick the Issuance & reporting month first. The statement is for that month. The download buttons in the page header are the Green Statement for the same month.

The sustainability lead’s problem: two numbers for the same month, because GHG Protocol asks for both methods.

Location-based = consumption × grid-average factor.

Market-based = (MWh covered by retired RECs × 0) + (residual × residual-mix factor). Holding is not covering. Coverage cannot exceed consumption; extra retirements show as over_retired_mwh.

South Africa publishes no official residual mix. v1 proxies the grid average and prints that fact on the face of the statement (C2). A factor without a source cannot be written.

Avoided emissions (renewable MWh × factor) appear when carbon terms are enabled. Combined-margin weights live on the factor row (C3), never as calculator literals. Carbon terms off → the figure is absent, not zero.

FINAL statements are not silently restated. A factor change inserts a new version. Grade is PROVISIONAL until every period in the month is FINAL.

The monthly certificate runner rebuilds statements in the same pass.

13. Emissions analysis — the tab, the Green Statement, detectors

Claims & reporting → Emissions statement shows the statement figures and any detector findings (REC dormancy, unretired holdings at year-end, unsold retained inventory, the 12-month advisory window). Rand figures on detectors come from the CertificatePrice reference row and are an estimate — never an invoice.

The Green Statement PDF is byte-deterministic (no timestamps). CSV is the same figures. Download Green Statement PDF or CSV from the Certificates header. If the selected month has no statement, those controls are disabled.

Risk metrics added for the planner: REC_REVENUE_R, CARBON_REVENUE_R, UNSOLD_CERTS, UNRETIRED_RECS, AVOIDED_TCO2E, REC_COVERAGE_PCT.

14. Carbon offset projects — why most sites do not qualify

A tradable carbon credit is not “the plant is renewable”. It is a registered project under an external standard, with a crediting window, a methodology, and (for SA tax) often a COAS listing.

Eligibility is recorded, never inferred. No code path looks at technology: :SOLAR_PV and decides you are additional. A project cannot leave draft without a standard and a registry project id. Issuance outside the crediting window is refused. Grouped projects are out: one CarbonProject is one generator site.

Verified issuance is mirrored: the platform never computes the tonnes — the verifier did. The batch is kind: :carbon and goes through the same evidence guard as a REC (serial + hashed artifact). Mirroring now requires a ProjectVerification for the vintage: the SOP chain Generation → MRV → Verification → Issuance is one evidenced walk, not a folder discipline.

The SOP lifecycle on the project

Three records sit on the existing CarbonProject:

The crediting window’s source of truth is the validation’s granted period, copied onto the project. Issuance.mirror/2 still refuses a vintage outside that window; it also refuses a vintage outside the verification’s monitoring period, a missing verification, and a quantity that would exceed what the VVB blessed.

The PDD is evidence the platform stores and hashes. It is never a document the platform generates.

SOP §6 — the evidence folder is the artefact store

Folders become (subject_type, subject_id) pairs on WB.Billing.Artifact. Nothing about SOP §6 needs a filesystem.

CS1 (regulatory & eligibility) is a hard exit gate for shipping offset mechanics on the wrong rules. The code is in; the findings are not. Treat every live project as pending that review.

Careful. The same megawatt-hour cannot support both a REC claim and a credit claim for the same party (§08 rule 5).

15. Offsets and carbon tax

The tax lead’s problem: the Carbon Tax Act lets you retire listed offsets against a tax period, up to an allowance, at a statutory rate. The platform stores the rate (effective-dated, source-required) and records a retirement against tax_period with a coas_reference.

The section-6 working is computed in the Tax room, taught in V20. The allowance and rate are register rows. The Tax screen labels the result a working estimate and says the tax treatment requires review. A saved FINAL version freezes that working. It does not turn the estimate into a filed return.

The combined-margin factor uses CDM default weights on the row until CS3 replaces them. Changing weights is a new factor row, not an edit.

16. A worked certificate year

Walk one generator month end-to-end. Numbers are the pattern, not a promise that your demo seed matches every cent until mix setup.demo has backfilled.

June

1. Settlement FINAL: 2,500 kWh (2.5 MWh) + 0.4 MWh carry → 2 certificates, carry 0.9 MWh.
2. Accruals tab: confirm → submit to zaRECs → record serials with hashed evidence → ISSUED.
3. Allocations: one bundled buyer took 1,667 kWh delivered, one unbundled took the rest of the energy. Preview: buyer 1 cert, retained 1 cert. Confirm. 1 + 1 = 2.
4. Off-taker retires 1 REC for the calendar year with evidence. Market-based coverage for 1 MWh; residual consumption uses the disclosed grid-average proxy.
5. Priced retained inventory does not invoice this month — the issuer already ran at 05:00. It queues for July.

Conservation checks: allocations ≤ issued; coverage ≤ retirements; carry identity holds.

Follow along. After mix setup (or mix setup.demo for a full year), open /org/certificates?month=2026-06.

17. Terms used in this volume

18. Reference card

Sign-in (demo): password supersecret. Organisation door e.g. offtaker_c@webill.net.

19. Your certificate portfolio

Holdings on the Certificate Desk used to be a single integer on an allocation row — one quantity, one status. That cannot represent “sell 300 of 1 000, pledge 100, retire 50”. The lot is the tradeable unit: a contiguous quantity of one asset, held by exactly one organisation, in exactly one custody state. Split a lot and the parent closes as SPLIT (quantity intact for the audit trail); the children partition the quantity and, when the registry issued serials, the serial range. The tree is the paper trail.

Open Carbon → Certificates → Portfolio → Lots & provenance (/org/certificates?tab=portfolio). The portfolio is live. The month selector on the page does not change which lots you see. Manage trading commitments on this view opens Market → Orders & listings. There is no separate portfolio address.

Custody, in plain language

Inventory counts FREE + PLEDGED + LISTED only.

Reading the tiles

Each tile is a group of open lots that share kind, registry, vintage year, custody and pool. The Rand figure, when present, is estimated-grade: it multiplies quantity by the CertificatePrice reference row in force that day, and it carries that row’s source note. It is not an invoice price. Contract prices on PPA REC/carbon terms are the only figures that become document lines.

A group with no reference row shows quantity and “No price on file”. That is a different claim from R 0.00.

Where this is taught. Who may put certificates on an invoice — §11 Buying and selling certificates. Estimated-grade reference prices — §18 Reference card.

Drill-down — click any lot and see why

From a lot row, Drill down patches ?lot_id= on the same tab and shows three things, none of them computed in the template:

1. Split tree — climb to the root and walk the children. SPLIT parents keep their quantity.
2. Journal — every movement that touched this lot or its ancestors (kind, quantity, counterparties).
3. Serial trail — serial_start–serial_end per tree node, or serial-free stated plainly when the origin registry issued no per-unit serials (or the batch’s range did not parse).

A lot id that is not this organisation’s is refused.

The pool book

A :FREE lot can be booked onto a trader pool (holder_pool_id). The organisation total does not change — it is the same certificates, now visible through that pool’s facet on the portfolio. The journal records a one-sided BOOK_TO_POOL movement.

What this view does not do

It does not show the public book, match an order, or run an RFQ or auction. Those live in Carbon → Market, taught in §20. This view does hold the lot, record an agreed sale you have already made, and show why a lot is free, pledged, listed, split, retired, or sold outside the platform.

Register & retire (/org/certificates?tab=holdings) is the other half of Portfolio. External registration and a recorded retirement live there. An agreed bilateral sale is recorded from a free lot on Lots & provenance, in the dialog described below.

Registering an external holding

Certificates you already own elsewhere — a purchase on another venue, a Verra account, a group treasury transfer — come onto the platform through Portfolio → Register & retire (/org/certificates?tab=holdings). The control is on that view, not a new address.

Registration-in is one gesture. It creates the asset, a root lot (no batch — the holding did not originate in this platform’s settlement engine), and a one-sided REGISTER_IN journal movement. The lot is yours and FREE.

Honesty is a three-rung ladder. The platform never pretends it has checked a registry it has not spoken to:

Serial-free holdings (the origin registry issued no per-unit serials) store the sentinel NONE on serial_start. That keeps uniqueness closed: at most one serial-free asset per organisation × registry × project × vintage. A second serial-free registration for the same tuple is refused by name; top up by registering against the existing asset instead. Overlapping numeric serials on the same tuple refuse too.

Upload the registry statement to lift DECLARED to EVIDENCED. Evidence, once hashed, is not unattached. Cross-organisation duplicates are invisible at this rung by design — each organisation’s external account is private — and are exactly what connector confirmation and the CAD Trust cross-check exist to catch.

Recording a bilateral trade

Two organisations that have already agreed a sale record it on Lots & provenance. On a free lot that is not only declared, Record an agreed bilateral trade opens a dialog. The dialog uses the same branded header as the rest of the product. Its title is Record an agreed bilateral trade. The eyebrow says Certificates.

The body says that recording the sale pledges the whole lot to the buyer, and that invoicing and delivery continue in Market. You choose Buyer (every organisation except your own) and Agreed price per unit (R), then Record trade. Escape, the X, or the dimmed backdrop closes the dialog without recording anything. The buyer and the price are not typed into the table row.

Split the lot first if you are selling only part of a holding; the trade consumes the whole slice (quantity equals the lot). The sold slice pledges the moment the trade is recorded — custody FREE → PLEDGED, journalled as PLEDGE, the trade named on the movement. A second pledge, a retirement, or a pool booking of that slice is refused naming the blocking trade.

The seller’s issuer then raises a standard tax invoice through the billing rail that already numbers, hashes and covers every other document. The price is the trade’s price, never the CertificatePrice reference row (that row is estimated-grade valuation; putting it on an invoice would launder a guess into a tax document). The line’s source_ref is the lot; the document also carries carbon_trade:<id>. A second invoice over the same slice refuses as already covered.

Platform fees are priced from the FeeSchedule register — seeded at the assessment’s 2.5 % seller / 1.0 % buyer with volume tiers, every row stamped interim — assessment model, pending Q1. No percentage lives in code. Changing a dated row changes the next trade’s fee with no deploy. At settlement the Market Operator raises one small fee document per charged side, referencing the trade invoice. A cancelled trade raises none.

Payment delivers the certificates in the same database transaction that marks the invoice paid: SALE on the journal, holder changes, custody returns to FREE under the buyer, the trade SETTLED. Paid-but-undelivered is unrepresentable. Trusted repeat pairs can opt into delivery-on-issue (deliver_on_issue on the counterparty preference); that mode stamps onto the trade at creation, so a later flag change never moves an in-flight trade.

Cancellation by mutual consent (or expiry) before payment runs RELEASE, the trade becomes CANCELLED, and an unpaid issued invoice is voided — never edited. A paid trade does not cancel: unwind with a new opposite trade. Certificates cannot ride a trader’s credit note.

Refusals you will see, each naming its rule:

• a DECLARED holding cannot sell (ladder_refuses_list);
• a pledged slice cannot sell, retire or book again (the blocking trade is named);
• a second tax invoice over the same slice is already covered;
• an order-book, RFQ or auction origin is not recorded from this dialog — those trades are created in Market.

The venue is §20. A bilateral trade recorded here is still a change in what you hold, which is why the dialog lives on this view. After it is recorded, open the trade from Market → Trades & delivery to invoice, take payment, and deliver.

20. Trading carbon on the platform

Two organisations with no prior contract can discover a price, agree a trade, and exchange certificates against payment. That is the Market room. Every path ends in the same trade the bilateral dialog already uses: invoice, pay, deliver. There is no second settlement mechanism.

Open Carbon → Market (/org/carbon-market). The heading is Trade with a clear purpose. The sentence under it says you acquire carbon credits for an offset strategy, or RECs for a renewable-electricity claim, and that you compare the registry, the vintage, and the verification before you commit.

The old Certificates address ?tab=trading does not open this room. It shows a count of your open listings and orders and a button Open carbon market.

VAT on a venue invoice is an estimate that requires review. The line at the bottom of every Market tab says so: prices on the screen are unit prices, and the dated fees, VAT, and total belong on the trade invoice.

Follow along. Seat: OffTaker C. Path: Carbon → Market. You should see four tiles — Firm price levels, Open buy orders, Live sell listings, Trades awaiting completion — then the tabs Discover, Orders & listings, Private negotiations, and Trades & delivery.

The four tabs

Think of the market as a shop. Discover is the window. Orders & listings is your own order pad. Private negotiations is the back room. Trades & delivery is the counter where the parcel is invoiced and handed over.

If you are not admitted, a panel Complete venue access replaces the happy path. When the missing piece is the trading agreement, Review agreement opens a drawer. You read the current version, tick that you are authorised to accept it for the organisation, and press Accept agreement. A later version asks again. Actions that place an order, list a holding, request a quote, or accept a quote stay disabled until admission is in order and you are an active member of the organisation.

flowchart TB
  A[Discover a firm offer] --> B[Review the commitment in the drawer]
  B --> C[Confirm the order or the listing]
  C --> D[Trade appears on Trades and delivery]
  D --> E[Seller prepares the invoice]
  E --> F[Payment delivers the certificates]
  G[Private request for quote] --> H[Counterparty quotes]
  H --> I[Accept quote and create trade]
  I --> D

Discover

Filters sit in one row: Instrument (all, carbon credits in tCO₂e, or RECs in MWh), Registry, and COAS status (any, or COAS listed only). Place buy order and List a holding open the right-hand drawer. Both stay disabled until you may edit and the venue has admitted you.

Firm offers are inventory already committed to delivery. Each row groups offers with the same instrument and the same price. Seller names stay private until a trade exists. Columns are instrument and standard, registry, vintage, COAS, quantity, ask per unit, verification, and Prepare order. Verification reads Registry confirmed or Unverified evidence.

An empty book says No firm offers match this view. That is not a price of zero. Broaden the filters, place a limit order, or open Private negotiations.

Indicative interest, when any exists, is a closed disclosure. Those rows are price discovery only. The inventory is not committed, and you cannot lift an indication.

Two cards at the bottom point at the purpose, not at another copy of the book. Planning a tax offset? links to Tax → Offsets. Planning a renewable-energy claim? links to Certificates → Register & retire.

Orders & listings

Your commitments repeats Place buy order and List a holding.

A buy order shows the instrument, the limit price, how much is still open, the status, the registry filter, whether it is COAS-only, and the expiry. Cancel remainder asks you to confirm, and cancels only the unfilled quantity.

A sell listing shows kind, price per unit, remaining quantity, status, and whether it is public or private. Withdraw listing asks you to confirm, then releases the remaining inventory.

Empty states: No buy orders yet and No sell listings yet. A firm listing reserves the quantity until it trades, expires, or you withdraw it.

The drawer does not commit on the first press. Review commitment shows what will match immediately and what inventory will be reserved. You confirm only after that review. A price-level Prepare order from Discover fills the instrument filters from that row.

Private negotiations

Request a quote opens the drawer. The guidance says a private request is visible only to you and the organisations you invite, and that a quote is visible to its author and to you.

Each card is either Your request or Invitation to quote, with direction, quantity, instrument, status, and the close time. You can Withdraw request while it is still pending. An invitee with no quote yet can Respond with a quote. You can Accept quote & create trade on a live quote against your own buy request. The confirm sentence names the quantity and the unit price, and says the acceptance creates a trade and pledges the quoted inventory.

Your auctions sits under a divider. Bid prices, identities, and counts stay sealed. Only a published clearing price and the awarded quantity are shown. If you own none, the line is No auctions owned by this organisation.

Trades & delivery

The heading is From agreement to delivery. The order on the page is matched, then invoiced, then payment confirmed, then delivered. Each trade is a button: Bought or Sold, quantity, unit price, counterparty, origin, and the next action for its status.

Opening it uses the same right-hand drawer. You see the stage, the counterparty, the quantity, the price, and the settlement mode. If you are the seller and the trade is matched, Prepare trade invoice is the action. Open invoices goes to Billing. View certificate custody opens the lot on Certificates → Portfolio. The drawer does not pretend that pressing a button has taken the payment.

An empty blotter says No trades yet. Matched orders, accepted quotes, and bilateral trades recorded on the portfolio appear here.

The book and buckets

A listing is an offer of a lot slice. A FIRM listing pledges the slice as it is created (FREE → LISTED): what is on the book is always deliverable. An INDICATIVE listing advertises without pledging and cannot be lifted — it exists to prompt an RFQ. Listings over projected accruals are INDICATIVE until the certificates actually accrue.

An order is a standing buy intention. It names filters, not a lot: kind, registry, standard, vintage range, COAS-listed. A compliance buyer cares that it is a 2026 COAS-listed VCS (Verified Carbon Standard) credit, not which one.

The venue’s unit of fungibility is the instrument bucket {kind, registry, standard, vintage_year, coas_listed?}. Two listings from different projects with the same tuple are the same instrument. Project identity stays visible on the listing detail pre-trade; project-specific demand is what RFQs are for.

Depth is the best five FIRM price levels per bucket. INDICATIVE rows are flagged and never mixed into liftable depth.

Names travel no further than they must

Until a trade exists, the public book has no seller identity — not even a nil. Own listings and own orders are the only book queries that return a name, and only the caller’s own. Matching is the first moment the two sides see each other. The same rule is why a foreign organization_id on this URL is 404, never 403: a 403 would tell you the other organisation exists and trades here.

RFQs

A request-for-quote is a time-limited invitation: you name the counterparties. An invitee sees the RFQ and their own quote. The requester sees every quote. A non-invited organisation sees nothing. Acceptance creates a Trade with origin :RFQ and pledges the seller’s quoted slice in the same transaction. Decline and expiry write no movement — an RFQ promises nothing until a trade exists.

Auctions

A seller opens an auction over inventory. Opening pledges the lots (LISTED). Bids are sealed: until the window closes, not even a bid count leaks to the seller or a rival. Clearing is uniform-price: sort bids high-to-low, accept down the stack, and every winner pays the lowest accepted bid. Nobody regrets bidding honestly. Unawarded remainder returns to FREE. A window that closes on nothing is UNSOLD and the whole inventory is released.

Escrow, in one sentence

A lot slice is FREE, LISTED or PLEDGED exactly once. It can be promised to at most one buyer. Double sale is structurally impossible, not policed. Settlement delivers through mark_paid (:SALE in the same transaction). Cancellation or expiry of an unpaid trade :RELEASEs the slice; it is immediately re-listable. Those are the only two exits from PLEDGED.

Fees and VAT

Venue fees resolve from the FeeSchedule register (assessment model, pending Q1) — never a constant in code. The seller invoice and the fee documents ride the billing rail you already know from V15. VAT on certificate lines and fee lines is the named interim treatment pending review. The footer on /org/carbon-market says the invoice VAT is an estimate, and that the unit prices on the screen are not the invoice total.

The trading agreement

First use of the venue — list, order, quote, or accept a quote — requires acceptance of the currently effective carbon trading agreement. On the Market page that gate is the panel Complete venue access and the drawer Review agreement. A later version asks again. Existing platform organisations trading their own lots need the agreement. A third-party carbon trader also needs an operator ACTIVE profile. A profile still waiting for approval is refused with that state named.

What the venue will not do

No derivatives, no margining, no shorting, no money custody, no simultaneous delivery-versus-payment. No suggested prices — a venue advising both sides of its own book would be a conflict, and fees are its only stake. Creating the organisation’s carbon participant profile is separate from this room; the tax year is V20.

21. Registries connected

The platform talks to origin registries through one seam: WB.Carbon.Registry.Connector. Five callbacks — holdings, project, cancellation request, cancellation status, retirement status — and three adapters behind them: Verra, Gold Standard CorTenX, and COAS. A fourth adapter, the Mock, is the default in every environment. Going live is a configuration change plus a recorded-fixture conformance suite, not a rewrite.

Follow along. Seat: OffTaker C. Path: Carbon → Certificates → Registry pipeline (/org/certificates?tab=pipeline). A demo build walks one Verra holding to CONFIRMED and one COAS block to RETIRED. An empty pipeline reads No external credit blocks on the COAS pipeline yet.

Why the Mock is the default

Registry APIs bill per action. Tests never open a socket (carbon_registry_forbid_network). The Mock answers the same way every time for the same seed, including certificate-document bytes, so a fresh mix setup.demo shows the same confirmed holding and the same retired COAS block.

What a sync run records

An operator starts a sync against an organisation’s registry account. Each run stores:

• which adapter answered
• when it started and finished
• an outcome (CONFIRMED_ALL, DIFFS_FOUND, or FAILED)
• a diff summary (confirmed / absent / mismatched counts)

Every confirming response is stored as a hashed Artifact before the confirmation row exists. A confirmation without that artifact is impossible — the evidence rule of the custody ledger, applied to automation.

The ladder’s top rung

CONFIRMED means a connector matched the holding against the origin registry. The confirmation artifact is one join from the asset. Direct writes to the rung still refuse; only confirm_verification with a :CONFIRMED confirmation grants it. A later :MISMATCH does not downgrade the asset — that is a conversation the ledger makes visible, not an automatic un-confirm.

A confirmed holding lists without the unverified flag, may be retired, and may be used for tax. DECLARED still grants nothing. EVIDENCED still lists with the flag and refuses retire and tax-use.

The COAS pipeline

Credits that will reduce South African carbon tax walk four stages (spec §2.4), shown as stations on the Pipeline tab:

INTERNATIONAL (held) → LoA applied → LoA granted → cancellation requested → cancelled (certificate stored) → COAS listed → COAS transferred → retired (SARS Carbon Offset Certificate stored).

Each completed hop is a journalled movement with its artifact. After cancellation the international serial is dead — the COAS listing is the live thing. Quantity-only (serial-free) lots stay tradeable on the venue but refuse :CANCEL_TO_COAS until decision Q7 lands.

The Carbon Offset Certificate at RETIRED is the document the DA 180 pack consumes — that pack is V18, once carbon tax lands.

22. The world’s card catalogue

CAD Trust is the catalogue of the world’s carbon credits: which registry issued a block, whether those serials are still live, and who currently holds them. This platform reads that catalogue for every holding it touches, and it is built to publish the South African drawer into it — testnet first, until the business holds the mandate to go live.

The CADT node is infrastructure beside the app. The application never embeds Chia and never holds a wallet key. CI and the demo estate talk only to a Mock. Pointing at a real node is a configuration change.

Follow along. Seat: OffTaker C. Path: Organisation → Certificates. Operator path: /operator/cadt. A demo build seeds one colliding serial block, finds it, and shows it resolved with evidence.

What observing does for every holder

Once a day the observer syncs every registry on the governance list. For each lot the platform holds it asks: does this serial block appear live in more than one registry?

Two live hits in two registries is a double-count suspect. That is a market-integrity incident, not a warning. Listing and retirement refuse until a human resolves it with evidence — a corrected registry statement, a cancellation record — stored as an artifact. The Certificate Desk shows a blocking banner on the affected holding. Operators see the same incident on /operator/cadt, with sync health beside it.

One hit in the origin registry of an externally registered holding is the expected mirror. It does not fire. A serial-free lot cannot be serial-checked; the platform records that honestly rather than pretending a clean pass.

What the banner means, and who clears it

The red banner on the Certificate Desk means: this holding is suspected of existing in two registries at once. You cannot list it and you cannot retire it. Clearing it is an operator act on /operator/cadt (or the same resolve action the demo uses): evidence, a name, a note. The resolution trail stays on the Desk after the banner comes down. A later hit is a new incident — history is not overwritten.

What publishing makes visible

When the platform publishes, ledger events (issuance, retirement, COAS listing) map onto CADT Data Model v2.0 tables and drain through a queue: stage on the node, then commit. Every node response is stored as an artifact. Replaying an event cannot double-post. Governance picklists are checked here first, so a non-conformant value is a refusal on this side of the wire.

The mapping is sparse-honest. Where the platform does not yet hold a methodology code or a validation record, those tables stay empty. Empty is conformant. Inventing a code would be a lie in the world’s catalogue.

Article 6 / AEF hooks exist on the lot and as a stub table. Nothing writes them. Full AEF publication is a later governance decision, not a code path waiting to be switched on by accident.

Testnet until the mandate exists

The pipeline targets CAD Trust testnet. No configuration in this repository names mainnet. Reaching mainnet needs a deliberate runtime setting, keys held beside the node (Chia wallet mnemonic in real key management; CADT API key from the environment only), and the institutional mandate — who carries the conversation with CAD Trust, under which legal entity. Engineering has nothing left to build against that line. It is ticked when the business answers it.

Operators: the V19 chapter on this volume’s sibling (V21 §9) covers deployment sizing, the mirror-database option, and where the key ceremony is recorded — never the material itself.

23. A worked trade, end to end

This chapter walks one certificate’s life on the demo estate so the manual and a fresh mix setup.demo agree. Seat: IPP 2 (Atlantis Wind) as the originator, then the buyer who takes the lot through the venue and into a July tax pack. Password for seeded users is supersecret.

Each stage names the screen where the demo shows it.

Settled megawatt-hours become an accrual

Settlement for a FINAL month produces the megawatt-hours the plant actually delivered. The Certificate Desk Accruals tab (/org/certificates?tab=accruals) shows the REC batch that month: quantity, carry, status ISSUED on the demo (S10 already walked confirm → submit → record issuance so the actions are not sitting idle for you). Lineage still resolves to the settlement periods.

The offset project is walked, not hoped for

Open Projects (/org/certificates?tab=projects). IPP 2’s Atlantis Wind project (demo step S23) carries the SOP spine:

1. An EA assignment on the SELLER-owned physical PPA — carbon terms enabled, ownership snapshotted.
2. A validation with a hashed PDD. The PDD bytes are the Mock registry’s fetch_project/1 response; the API response is the evidence.
3. A monitoring report built from settled intervals where they exist and Mock inverter telemetry where they do not. Completeness, consistency and traceability are named QA/QC lines, not silent drops.
4. A verification for that period, quantity an integer, attached to a passing report.
5. A mirrored kind: :carbon batch in ISSUED at the verifier’s quantity, linked to the verification.

Every artefact on that card resolves by hash. That is SOP §7 — Generation → MRV → Verification → Issuance — as a walk the platform can print.

The lot, the listing, the trade

The issued carbon batch becomes a lot on Portfolio (/org/certificates?tab=portfolio). Demo step S20 already listed a book on /org/carbon-market: FIRM against INDICATIVE, matching, escrow that never promises twice. Follow the Atlantis holding onto the venue, or the S20 order-book trade if you want a settled print without placing a new order.

COAS, then the buyer’s July pack

Registry pipeline (/org/certificates?tab=pipeline) walks a COAS-destined block stage by stage (S10’s retired COAS walk; CT3’s connector Mock). Each completed stage stores the API response (or the manual upload) as the artefact.

The buyer who needed that offset for carbon tax opens Carbon → Tax (/org/carbon-tax). Demo step S21 (BrickCo) is the July pack: the section-6 engine and the DA 180 working sheets. The screen labels the liability a working estimate and says the tax treatment requires review. Filing stays outside WeBill.

What this walk does not claim

It does not claim the VAT character of venue fees or tax-pack lines (CS1). It does not claim the platform is South Africa’s CAD Trust mainnet publisher (Q2). It does not claim a live Sungrow / Sunsynk / Huawei / Sigenergy adapter — telemetry is Mock-complete; going live is configuration plus a fixture-conformance run.

CAD Trust still watches every lot (S22, /operator/cadt). A double-count suspect still blocks listing and retirement.

That is the programme, end to end, on mocks, on the demo estate.