DOVU Labs H22

Insuring carbon removals through decentralized reputation. 🕊

Comment

Inspiration

In 2030 the market for carbon credits is primed to be worth upwards of $50 billion.

There is not enough verifiable carbon offset supply to meet global demand, especially when it comes to finding sources where key facets such as additionality, leakage, and durability are tracked effectively.

All of this is in all is intertwined within the mindset shift from “offsets” to “removals” of CO2 from the atmosphere into short and long-term storage methods.

At DOVU, our mission is to build the trust layer for carbon offset integrity on Hedera Hashgraph.

We have a diverse product suite from a marketplace, tracking on-chain carbon analytics, to a highly flexible incentivization engine.

However, there is one piece of the puzzle which we have felt is missing.

  • How do we know we can trust different actors who contribute to the creation and maintenance of these carbon removal assets?
  • Could there be a protocol that is flexible enough con any kind of carbon removal project then potentially any kind of ESG-related project or actor, that connects to the Guardian?

The entire purpose of the H22 hackathon was to answer these questions, to create a product to act as an MVP to fulfill this goal, and then explore a vision of what the future looks like.

What it does

In a sentence, insure carbon removal projects through decentralised reputation.

To do this on mainnet only tokens that are backed by a real market, like $DOV or stablecoins should be considered.

As an expanded version, a protocol for tokenized carbon projects, or actors contributing therein, to be connected to a reputation market where the combined TVL can be used as a metric for how much network participants trust an actor. In addition, this reputation doubles back as an insurance strategy in case the worse was to happen, that's a leakage or fraud event occurred.

Every kilogram of verified carbon that is on the market may be backed by a single DOV, based on the collateralised backing of a given project. The backing of DOV towards a project represents either an over or under collateralization of assets backing the project itself – eventually, this will affect the risk and reward profile of a given staked position.

In that case, the owner of the contract (eventually a multisig DAO) has the capability to trigger an insurance payout as a project liquidation, currently, a percentage can be used based on proposed evidence through proposals.

Understanding the current Proof of concept

As a whole, there are two actors for this demonstration.

  • The owner of the contract is currently us, but this ownership may be transferred to a multisig account or DAO.
  • A user, specifically on the Hedera network with access to a Hashpack wallet.

Below, I will cover the different capabilities of each role.

Owner or administrator

This currently would be considered the superuser, and would effectively make the system more centralized until which time we are happy and ownership transferred over to a multisig or DAO.

  • Ability to add new projects
  • Access to the admin features of the panel
    • To view and modify models
    • To generate new users and with specialised roles, some that can specifically create DAO insurance proposals
  • To add tokens to the contract
  • To set maximum claimable tokens
  • Ability to trigger a liquidation insurance event, to affect all accounts connected to a given project pool.
  • All base user capabilities, stake/unstake/remove timelock.

User

A user, in this case, has access to a Hedera account and can:

  • Claim tokens from the treasury
  • Interact with projects through staking and unstaking
  • Ability to remove a timelock for a staked position (testnet demo only)

How we built it

Before building out the project we first approached with a design of extending DOVU’s staking capabilities but with using smart contracts.

We were inspired by projects like Woo, Wise, and Hex in terms of how timelocks can create and foster a community but we wanted to focus on the concept that tokens backed by real markets and value could be applied to reputational and insurance markets.

The initial design Insuring carbon credits by staking DOV as finite reputational energy, encompassed this vision.

However, to begin building we started with testing different smart contracts, getting to grips with Hedera’s Contract quirks around HTS, and navigating the various number of examples that were produced. In time, we created the Hedera Hardhat Tooling library to support rapid development of smart contracts on Hedera, it has a number of unique features as:

  • A powerful template and structure for creating on the fly JS tests for a new contracts
  • One-click commands for rapid deployment, testing, and seeding, to reduce feedback times.
  • Contract id environment injection for keeping track of latest deployments
  • Example contracts, with documentation, can be the foundation for anyone.
  • Rich tests for the example, using a black-box style.

After we finished the details of that repository we ensured that it was a template that anyone could use.

Next, we started the development of the Smart Contract. This was more of evolution as we started with a basic staking contract linked to projects and we added the timelock features later. This enabled a lot of progress to be made on the frontend and grow in parallel with the contract development.

Our primary frontend dapp is built in React and Typescript and connects with Hashconnect as the primary wallet, providing advanced capabilities for the owner of the contract

We iterated quickly and discovered that there was a need for an API to manage the off-chain state for the user experience to be tolerable. We couldn’t expect users to continually transact with the contract to get data. From this insight, we built out a rich API with an admin panel to keep track of all the different elements involved, with role management and auth/token-driven control.

The API grew to be larger than initially expected as we want to try to keep the user experience as clean and fast as possible. Being able to store any and all data to synchronise with a contract after a call was useful.

One of the final contract features that were added is the insurance trigger feature, we had a number of interesting problems that were quite confusing but this was a symptom of allowing instant timelock removes with a fairly healthy yield reward.

Challenges we ran into

There were a number of different challenges we met during the hackathon, other than the usual insight to understand how this technology works.

Initially, we were having some issues with Hashpack’s hashconnect and it seemed to be freezing transactions, there are a number of updates that definitely helped over the period for us communicating directly to our contract. With that said we got more acquainted with the tooling and those issues seem to mitigate completely.

On the security side of things, one of our concerns was around not having a Hedera SDK client reference actually in the front end. Most of the documentation for smart contracts relies on calling a client, unfortunately as the risk of storing environment variables on a front-end application is too great we really wanted to avoid this.

But one of the primary reasons we had the client was to be able to reference data directly from the contract to ensure that the user would have to touch the contract as little as possible, this was resolved through our API and we were happy to remove the dependency for any client or private keys within the environment file of the dapp.

And finally, UX was a big factor, we wanted an experience that was seamless and fast and our API work really allowed us to provide an experience everyone expects and to be able to transact with the contract as little as possible. Naturally, the challenge with this is that you need to ensure that all data in the API is in sync with the contract this is challenging but it is the preferred approach undoubtedly.

What od the funniest example throughout this process is that we were having really strange results with transactions failing, especially around liquidation events and unstakes. We are having deterministic issues where different transactions failed at different times. The diagnosis of this was that because we provide the time lock cancellation capability for the demo purposes users may receive a 25% yield after making it through their time lock, and the Treasury couldn't pay out the additional yield. To rectify this we added a set a check such that only 1000 DOV could be staked for a given project.

Accomplishments that we're proud of

Within six weeks we have built out a huge amount of product and tooling for this project.

We have a full-stack dapp, that is actually positioned to solve a real problem and connects serious DLT work, like the Guardian to decentralized finance. Ultimately, the explosive growth of networks is primarily through community and DeFi protocols that are simple and easy to use.

We are really proud of the tooling we have created, that allows the developer to get started treating smart contracts for Hedera to deploy and test in real-time the hard requirements of having a local chain running. This means that developers can work directly on the network by default and understand all issues ahead of time in terms of deployment as a natural progression, Hedera of course makes this more possible compared to other EVM ecosystems as the time to finality and costs are so low.

For our primary dapp we have:

  • A contract for staking value to projects with a timelock
  • A frontend application
  • An API for managing off-chain value
  • An admin panel for handling all offchain data, with role management capability.

Although there is still a bit of work to go and audit before we are ready to release this into production we have the foundation to really create something that is fit for purpose, that combines decentralized finance communities and key Hedera and Guardian stakeholders.

What we learned

Generally, working with the idiosyncrasies of the smart contract platform, especially with HTS tokens was a learning experience and I think everyone who has submitted to this Hackathon has probably shared in the view. As time goes on there will be more documentation and example of such contracts.

One of the key opportunities working with Hedera smart contracts is how the network manages accounts, in particular balance state, everyone owns their slice of account state. With a strict EVM system, there is a major disadvantage that all of your token value is linked contract mapping, your token balance is derived through referencing contracts that have been deployed rather than having your own state on the network.

While with regular tried-and-true standards ERC20/721/1155 this isn’t a risk, there is a fundamental issue that the contract can have full control of all balances at any time, it is trivial to write additional methods that instantly drain token balances. In short, there is an argument to be made that trusting the teams and developers of protocols can be considered a risk, no matter how small.

Although Hedera contacts may implement traditional ERC standards for storing value and have cross-compatibility with the majority of features we have a superset with HTS (eventual HCS) services which is unique in the landscape.

We see a future, particularly on Hedera, where the state of the system provides protections to any account holder – potentially to derisk asset holdings especially when the core HTS integrations are used.

Whilst there might be some security issues that appear through this approach I believe that the utility-delta will be a net positive in terms of personal security.

This of course is a balance, on one side having eventual 100% compatibility with EVM is wonderful addition but having a slightly restricted HTS feature-set for security is certainly a worthy tradeoff for many.

What's next for DOVU Labs

DOVU Labs represents our long-term aim to work to deploy various Skunkworks projects with the core team and community members to explore what the future holds with DOVU. For this project in particular we are excited about the implications of it becoming our core utility.

There are a number of items needed to fully realize the vision of minting wrapped tokens to represent a position within a given project or toward an actor, then by extension, the design and creation diversified vault of projects relating to particular risk profiles and attributes.

With that said, we need to take stock of what we have now and apply a full productization structure to the project to ensure that it is fit for purpose.

This will include:

  • Conversions and planning with key Hedera and Guardian members, to align our goals.
  • Planning and design on how we can integrate this work into our current DOVU marketplace, whether we can simply build upon the current frontend.

What steps do we need to take for it to be a more attractive prospect to serve a diverse range of actors and projects?

This should be our first aim, building for the sake of building is unlikely to yield the benefits we are aiming to achieve.

Share this project:

Updates