Introduction
Standardizing energy attributes
Last updated
Standardizing energy attributes
Last updated
By collecting many non-fungible EATs that share identical attributes into a single asset pool they can be treated like a liquid commodity. Web3 markets can continually discover the price of commodity pool, and market participants can more easily move in or out of balance sheet positions.
The fact that EACs are non-fungible & atomic makes it difficult to use them in web3 directly.
No two Energy Attribute Certificates (EACs) are identical - and that's the point! Grid energy is fungible, and the EAC carries all of the non-fungible attributes of the energy.
Energy Attribute Tokens (EATs) inherit these properties from the EACs they represent.
Some example EAC properties:
Vintage: When the energy for an EAC was generated - typically designated by a month and year.
Location: There are multiple non-tiling location properties of an EAC. These could be political locations like State or Nation, or technical locations like the power grid the generator is connected to.
Tech type: Denotes if an EAC was generated by solar, wind, geothermal, etc. power.
"CRS Listed" Status: CRS provides an extra layer of verification that many climate actors rely on.
Because each EACs has unique properties it's hard to know how to price them. If one EAC sells for $100, and another sells for $10, you still don't know much about how to price a third EAC.
EACs were originally designed by analogy with physical paper certificates. Each one has its own serial number, and each one is denominated to exactly 1MWh. You can have 1MWh of EACs or 2MWh of EACs, but you can't have 1.5MWh of EACs.
When a registry issues or retires EACs it's always in a whole number of these certificates. To ensure interoperability with these legacy compliance systems, EAT's are atomic, just like the EACs that they represent.
In practice, despite their differences, EACs are often fungible to the companies who retire them to meet their climate targets. Most buyers are as happy to have one EAC as they are to have another similar EAC.
Our basis pools combine EATs with shared properties into pools and use an ERC-20 token to represent fractional ownership of the assets in the pool. Unlike the EATs, these ERC-20 tokens are perfectly fungible, have deep liquidity, and are highly divisible. They can be used in any web3 application that supports the ERC-20 standard. We call them Jasmine Liquidity Tokens (JLTs; pronounced 'jolts').
When a user needs to redeem a specific EAT, they can use JLTs to withdraw a specific EAT from the common basis pool.
Credit: Our basis pools are inspired by Toucan's "reference pools" and to our knowledge they were the first project to use this design primative.
