At Thallo we consider carbon credits to be a semi-fungible asset. All carbon credit projects are defined using certain attributes. These include Sustainable Development Goals (SDGs), the type of project, the location, the vintage year etc. The credits from one project and vintage will not share the same attribute values as other credits from a different project and vintage. This results in numerous low volume pockets of fungibility. We call this the “liquidity problem”. In this article we’ll introduce you to Thallo’s innovative concept called dynamic pooling.
Efficient Markets
In a low liquidity pair the market simply will not function efficiently – price will jump around erratically and buyers & sellers may struggle to get their orders filled.
If we take a traditional market, say XAU/USD, all gold in this market is fungible and all dollars are fungible. This creates a highly liquid market meaning exchanges, brokers, and market markers can do their job of facilitating trading efficiently. Allowing for trading with minimal slippage and low spreads.
Static Pooling
Some existing Web3 protocols have attempted to solve this issue by creating pools of credits. For example if the credit is nature based it can go into a nature pool and the depositor of that credit will receive a “nature pool” token in return. This creates a high volume of fungible tokens which facilitates a functioning market.
However this has a number of problems including the fact the buyer doesn’t know the exact project and vintage that their pool token represents. They only know that the project is nature based. Most businesses are looking to offset their carbon footprint have Corporate Social Responsibility goals. They want to ensure that the credits they are purchasing are both high quality and align with their CSR goals. Static pooling restricts the buyer’s ability to make informed purchases. Making the connection between the pooled token and the underlying credit opaque.
There are also pricing issues. The pool token will be priced roughly on the average price of all the credits that back it. Credit owners are incentivised to arbitrage this by depositing low value credits that meet the pool criteria. This way they will receive a pool token back that is very likely worth more than the deposited credit. They can then immediately sell the pool token on the open market for a profit. It’s a race to the bottom. The overall quality of the pool, and the environmental impact it has, diminishes over time.
There is also another concern here. In order to give buyers more choice about the types of credit that back their pool token you could create multiple pools with different entry criteria. For example we could have a “nature” pool and a “Paraguay” pool. A credit can however only live in one pool at a time in the static pooling model, otherwise we’d double count the credit. If you have a nature credit that belongs to a project that was implemented in Paraguay – which pool do you place it in? The one with the highest price of course. But now the pools are competing against each other for liquidity which loops us back to the original issue – the liquidity problem.
Dynamic Pooling
Let’s take a look at the two sides of trading – sellers and buyers. For the most part sellers want to sell their credits at the best possible price. Buyers want to buy at the cheapest price, where the credit meets their criteria. This is where dynamic pooling comes in.
We allow buyers to specify their exact CSR requirements and consider all credits that match that criteria fungible. Given the vast nature of the attributes of carbon credits, the number of unique criteria permutations is over a billion. Our dynamic pooling engine is capable of analysing each and every one of these combinations across all projects. We can then offer features that you would find in traditional markets such as buy-limit, good ’til cancelled orders, setting alerts for price movements and price history analysis.
This means we have the absolutely maximum amount of liquidity available in each pool. A credit can be considered across multiple pools at run time. It’s only within executed trades where historic price analysis is performed. Of course the credit can only be purchased once ensuring it does not get double counted.
Conclusion
We’ve essentially solved the liquidity problem by giving buyers the privilege of creating their own definition of fungibility. Sellers benefit as they no longer need to make a binary choice when locking liquidity in a single, static pool – they can benefit from the best price and buy-liquidity available on the market. It’s a powerful concept that will unlock many other use cases as we continue to innovate.
In the meantime keep an eye out for our various releases over the next few months by signing up for beta access and expressing your interest.
