Most platforms in the sustainability stack are content with proving something exists. An exchange has a harder job: it has to make that something tradeable, between strangers, under regulatory scrutiny, with money on the line and finality measured in seconds. When the Client briefed our team, the design challenge was unusually compressed. Build ONE venue that can host both regulated carbon credits and unregulated cryptocurrencies. Give it the auditable integrity that a permissioned Hyperledger Fabric ledger provides. Layer on the AML/CFT screening the crypto market increasingly requires and the carbon market has always required. And do it in a way that the carbon credits issued through the Client’s companion MRV platform can flow directly in as Polygon-based tokens and find an actual buyer.
This case study walks through the 5-layer architecture our engineering team designed and built for the Client, layer by layer, with particular attention to why Hyperledger Fabric sits at the heart of the system and how the Exchange completes the vertical that the Client’s MRV platform begins. The live portal is at .
- The Exchange is the hardest layer in the carbon stack — it is where issuance meets liquidity, and where regulators, traders and engineering all collide.
- Our team chose Hyperledger Fabric for the order-book and settlement ledger because permissioned, deterministic finality is non-negotiable for an exchange that must answer to auditors.
- The platform handles two asset classes in one venue: cryptocurrencies (Bitcoin, Ethereum and more) connected via wallet integrations, and carbon credits flowing in from Polygon and supported chains.
- AML/CFT screening is designed as both inbound (onboarding) and outbound (every withdrawal), with every screening event written to the Hyperledger ledger for regulator review.
- Together with the sibling MRV platform, this Exchange forms a complete tokenisation vertical — from smart-meter measurement to trade settlement — and is now our team’s reference architecture for any tokenised real-world asset market.
Why an Exchange Is the Hardest Layer in the Carbon Stack
The MRV platform our team built for the Client (covered in detail in the companion case study) does one job exceptionally well: it proves that a tonne of CO2-equivalent reduction is real, measured, verified and minted as a token. That is a foundational achievement — without it, a carbon credit is just a promise. But proof of existence is not the same thing as liquidity. A credit that nobody can buy or sell is, economically, worth nothing. The Exchange is what turns a verified credit into an asset that clears the market.
That responsibility carries weight no other layer of the stack has to bear. The MRV platform answers to scientists, auditors and project developers. The Exchange answers to all of those plus traders, custodians, banks, AML investigators, securities regulators in multiple jurisdictions, and the counterparties on either side of every order. The failure modes are correspondingly harsher.
An exchange that mishandles counterparty risk loses real money for real customers. An exchange that misses an AML obligation puts its operating licence at risk in every jurisdiction it touches. An exchange that confuses custody — who actually controls the keys to which balance — can be wiped out by a single insolvency event. An exchange that fails to settle a matched trade deterministically becomes the subject of the dispute, not the resolver of it. And an exchange that tries to handle two asset classes on the same rails compounds every one of these risks unless the architecture is designed for that asymmetry from day one.
This is why an exchange is the hardest layer in the carbon stack. It is the convergence point where all the engineering, all the regulation, and all the human trust have to land in the same place at the same instant. Everything our team built for the Client after the MRV platform was answering one question: how do you make that convergence happen reliably, transparently, and at exchange-grade speeds?
Layer 01: Connecting Asset Sources — Crypto and Carbon Credit Blockchains
The Exchange starts at the edges, with the question of what assets it can actually accept. Layer 01 of our architecture covers connectivity to every external source of value the platform recognises. Cryptocurrencies arrive through standard wallet integrations — Bitcoin and Ethereum first, with additional chains added on demand through the same integration pattern. Carbon credit tokens arrive from Polygon and supported chains via smart-contract observers that monitor the issuing contracts and bridge contracts that move balances safely into the Exchange’s custodial environment.
Around those two asset streams, our team also built a dedicated SDK and exchange-connector layer. This is the seam where third-party data providers, custody partners, price feeds and partner exchanges plug in. By isolating that interface from the core ledger, the engineering team gave the Client the freedom to onboard new connectivity partners without having to touch the trading or settlement code.
Why the same exchange handles both
The initial instinct of many architects would be to build two exchanges — one for crypto, one for carbon — and bridge them at the user-account level. Our team rejected that pattern for the Client. The carbon credit market is still maturing, liquidity is thin in many segments, and the buyer base for carbon credits overlaps significantly with the digital-asset community already comfortable with on-chain settlement. Putting both asset classes in one venue means crypto buyers see carbon credits beside their existing holdings, KYC is done once, custody is unified, and the operational team manages a single compliance perimeter rather than two. The architecture treats asset class as a property of the token, not of the platform — which is what allows a Polygon-based carbon token to sit beside Bitcoin in the same user portfolio.
Bitcoin and Ethereum have decades of standardised wallet tooling. Polygon-based carbon credits have bespoke issuing contracts, project-specific metadata and vintage attributes that need to be preserved end-to-end. Our team’s Layer 01 design uses a unified token-descriptor model so that the rest of the platform — matching engine, ledger, dashboard — treats every asset the same way, while the connector layer absorbs the asymmetry between a generic crypto wallet integration and a project-attributed carbon-credit bridge.
Layer 02: Hyperledger Fabric as the Exchange’s Private Ledger
Layer 02 is the heart of the Exchange and the reason this entire project is anchored in our team’s blockchain capability. Around three operational services — Notification (real-time alerts), Database (structured data), and the critical piece, a Private Ledger powered by Hyperledger Fabric — we organised the core trust guarantees the rest of the platform relies on.
The choice of Hyperledger Fabric was deliberate. A public chain like Ethereum cannot host an exchange’s internal order book without exposing trading intent to the public mempool, suffering MEV extraction on every match, paying gas on every settlement, and accepting probabilistic finality measured in minutes rather than the deterministic finality measured in seconds that any serious exchange requires. Fabric solves all of those problems at the cost of decentralisation that an exchange does not need anyway — the Client, its regulators and its banking partners are the trust set, and they are perfectly happy to operate a permissioned network among themselves.
What Hyperledger Fabric gives the Exchange is therefore precisely what an exchange needs: order book integrity recorded in tamper-evident form, trade settlement records that cannot be retroactively edited, audit-ready transaction history that any regulator can inspect through a governed channel, no public mempool exposing the order flow, deterministic finality so settlement either happens or doesn’t (no reorganisations, no rollbacks), and channel-based governance that lets AML investigators access exactly the records they are entitled to without leaking unrelated activity.
What lives on the private ledger vs what stays in the database
One of the early architectural decisions our consultants worked through with the the Client team was the boundary between the Hyperledger ledger and the conventional database. Not every byte belongs on a blockchain; equally, the bytes that DO belong on chain must be there without exception. The boundary we landed on is straightforward:
- On the Hyperledger Fabric ledger: matched trades, asset balances, transfers, mint/burn events for tokenised credits, compliance screening outcomes, and every audit event tied to a regulated action.
- In the conventional database: pricing snapshots, market data, news content, KYC documents, user profile records, session data, dashboard configuration, and anything that is mutable by nature or excessive in volume.
The principle is simple: anything that, if changed silently, would undermine the integrity of a trade or an audit, lives on the ledger. Everything else lives in the database where it can be queried fast, indexed flexibly and updated without consuming chain resources. The result is that the ledger stays lean and auditable while the user experience stays responsive.
On a public chain, a trade is "probably settled" once it is several blocks deep, and even then a reorganisation can theoretically unwind it. For an exchange that has to confirm settlement to a regulator, to a counterparty’s auditor, and to the next trade in a chain of dependent settlements, "probably" is not a usable answer. Hyperledger Fabric provides deterministic finality — once a transaction is endorsed by the policy-defined organisations and committed to the channel, it is settled, end of discussion. That property is what allowed our team to build a matching engine that can confidently report a fill the moment Fabric returns the commit, with no rollback window to engineer around.
Layer 03: Exchange Platform Functions Users See
Layer 03 is the surface the Client’s users actually touch. It is the set of modules that make the platform feel like an exchange rather than a database with an API. Our engineering team built each of these modules as an independent service against the Layer 02 core, so the user-facing functionality could evolve without disturbing the settlement guarantees beneath it.
Carbon Credit Bidding supports both auction-style sales for large project tranches and continuous bidding for ongoing supply. Send & Receive Digital Assets covers on-chain transfers in and out of the Exchange’s custodial wallets, with address whitelisting and withdrawal review built in. Wallet Management exposes the user’s consolidated balance across asset classes, with custodial holdings as the default and self-custody patterns offered for advanced users. KYC & Profile Management handles document collection, verification status, and re-verification triggers when risk scores change. News Management delivers curated market and project news directly inside the trading interface so users can interpret price moves in context. Investment Portfolio aggregates the user’s positions, performance and exposure across both carbon and crypto. Payment Gateway handles the fiat on-ramp so users can fund accounts and withdraw to bank accounts. Buy & Sell Digital Assets covers the standard order-entry flow for cryptocurrency pairs.
The bidding mechanism for carbon credits
Carbon credits do not trade like Bitcoin. Where crypto markets are characterised by high-frequency, small-lot, anonymous order flow, carbon credit trading is lower frequency, larger lot, often bilateral, and almost always context-rich — buyers want to know the project, the vintage, the standard, the geography and the verification trail before they place a bid. The bidding mechanism our team built reflects that reality. Carbon listings expose the underlying project metadata directly in the order screen, so a buyer can see at a glance whether the credits are from a renewable project, a forestry project, or another category, what vintage they are, and which MRV trail produced them. The bidding engine supports both sealed auction lots for fresh issuance and continuous bidding for ongoing inventory, with the matching logic respecting the larger lot sizes typical of carbon trades.
Layer 04: External Integrations for Compliance and Market Data
Layer 04 is where the Exchange reaches out to the regulator-facing world. Two integration families dominate this layer: AML & CFT screening, and cryptocurrency market data.
The AML & CFT Screening API connects the platform to external compliance providers that maintain global watchlists, PEP databases, and sanctions registers. Every onboarding profile and every large transfer is screened against those lists in real time. The Cryptocurrency Market Data API provides real-time pricing, volume, liquidity, and analytics feeds for fair valuation of digital assets across the supported pairs, which the Exchange uses both to display reference prices and to validate that internal trades execute within acceptable bands of external markets.
Why our team designed AML as inbound and outbound
A common shortcut in exchange engineering is to screen users only at onboarding. Our consultants rejected that pattern for the Client. Risk is not static — a user clean at onboarding can be added to a sanctions list a week later, and a transaction pattern can shift from low-risk to suspicious overnight. The AML/CFT integration our team built therefore operates in both directions: inbound at the moment of KYC, and outbound at every withdrawal request, with re-screening triggered when risk profiles change. When a screen produces a block, the reason code is returned to the compliance officer, logged immutably, and surfaced to the user with an appropriate (non-tipping-off) message.
Every AML/CFT screening result the Exchange produces — pass, fail, manual review, override — is itself written to the Hyperledger Fabric ledger as a compliance event. This matters enormously for the Client and its regulators. When an investigator asks "did the platform screen this customer before allowing this withdrawal?", the answer is not "let me check the logs". The answer is "here is the on-chain compliance event with timestamp, screening provider, result, and operator action, and it cannot have been edited after the fact." That property turns a compliance archive into legal evidence, and it is one of the strongest justifications for choosing a private ledger over a conventional database for the Exchange’s audit trail.
Layer 05: End-to-End Flow from Asset Source to Trade Settlement
Layer 05 is not really a layer; it is the choreography. It describes how the four lower layers actually move a single trade from intention to settled fact. Walking through one trade end to end is the clearest way to see how the architecture earns its complexity.
A buyer logs in to the the Exchange platform. Their identity has already been verified at Layer 03 through the KYC module, and the AML/CFT integration at Layer 04 has confirmed they are not on any watchlist. They check live carbon credit prices, which are sourced through the Layer 04 market data feeds for crypto pairs and through the Exchange’s own order book for carbon listings. They see a Polygon-based the Client carbon credit minted by the sibling MRV platform, sitting on the order book as a Layer 01 asset. They place a bid. The matching engine finds a counterparty, and the Hyperledger Fabric ledger at Layer 02 records the matched trade and updates the balances of both sides — deterministically, immutably, instantly. The Layer 04 AML integration re-screens the counterparties for the specific transaction. The Layer 03 wallet management module updates both users’ dashboards. And the trade record itself becomes available, forever, on the Hyperledger ledger for the user’s auditor and for the Client’s regulatory reporting.
That single trade touched every layer of the architecture, and the trust guarantees compounded as it moved through them. Identity at Layer 03. Pricing at Layer 04. Asset at Layer 01. Settlement at Layer 02. Compliance at Layer 04. Wallet update at Layer 03. Audit record at Layer 02. None of those layers can be skipped without breaking the chain of trust that makes the trade defensible.
The architecture our team built for the Client is not five layers because five was a tidy number. It is five layers because each layer contributes a distinct trust guarantee that the trade cannot do without: connectivity (the asset is real and addressable), settlement (the ledger says so and cannot be re-edited), user experience (the trade is visible and actionable), external validation (pricing and compliance from independent providers), and end-to-end flow (every step is reproducible from logs that auditors can read). Strip any layer out and the trade becomes a promise instead of a settlement.
How the MRV and Exchange Together Form One Vertical
The Exchange does not stand alone. It is one half of a two-system vertical that our team designed and built for the Client, and the other half — the MRV platform — deserves its own credit in any honest account of how this market works. The MRV platform proves emissions reductions are real, by ingesting smart-meter data, calculating reductions against baselines, packaging them for verifier review, and minting verified credits as Polygon tokens. The Exchange takes those minted credits and makes them liquid, by giving them an order book, a counterparty pool, custodial wallets, compliance screening, and a settlement ledger their buyers and regulators can trust.
Either system on its own is incomplete. Issuance without trading is a museum of unsold certificates. Trading without verifiable issuance is a casino. Together, MRV plus Exchange forms the full vertical from the smart meter on the rooftop to the settled trade in the buyer’s wallet. Readers who want to see how the issuance side works are encouraged to read the companion MRV case study.
What makes this 2-system pattern interesting beyond the Client is that it generalises. Any tokenised real-world asset — carbon, renewable energy certificates, supply-chain provenance tokens, fractionalised commodities — requires the same two-system architecture: a measurement-and-issuance platform that proves the asset exists, and a trading-and-settlement platform that makes the asset liquid. Our team treats the the Client MRV-plus-Exchange build as our reference architecture for any future RWA market we are asked to engineer. The principles transfer directly. The asset class is just a property of the token.
For the Client, the immediate payoff is that carbon credits minted through the MRV platform now have a market venue from day one. Project developers do not have to find buyers off-platform, negotiate bilaterally, or trust uncollateralised IOUs — their credits flow into a venue with real liquidity, real compliance, and real settlement. For our team, the payoff is a proven architecture that we know how to deliver, and a client whose live portal at is the public proof that the design works.