follow up on today's call -- governance for OrbitDB of open offsets directory
Hello Christiaan and all,
So sorry I had to jump off -- I had a meeting scheduled for the offsets research project but made a mistake with the time.
To continue our conversation earlier today, I'm thinking that we could:
1. Use OrbitDB to host the open offsets directory, since the directory is just data. OrbitDB will make this data peer to peer on IPFS, and different developers could make different search, sales, ratings, etc. applications with it as the back end.
2. Write access to the directory, ie who can make changes, will be given to entities who will be trusted to make correct entries in the directory. These entities can be standards organizations, project developers, trading organizations, or depository trusts. They will be responsible for:
(a) holding the offsets in their name on the standards' registries.
(b) tracking the transfer of the offsets
(c) recording retirements of offsets in the correct name on the registries.
--> Anything else?
3. Verification of what the entities write to the database can be done automatically by comparing the entries in the registries and manually by users comparing the records and flagging incorrect entries. Some of the key things that we could check for are:
(a) Issuer is correct - verified with registry and with issuer entity
(b) Project info is correct - verified by users
(c) Credits issued, retired, and balance - verified automatically against registries
--> Probably more can be done?
4. If information is found to be inaccurate, an oversight group will change it.
5. If an entity writes too many inaccurate entries, the entities' write permission will be removed.
The mechanism for 3/4/5 will be similar to the Chainlink governance as discussed in their 2.0 white paper: Entities would stake reputation tokens on the data they write to the directory. Challenges could be made to the accuracy of the information. A supervisory group would judge the challenges. Reputation tokens would be removed if challenges are successful. Without enough reputation tokens, entities would no longer be able to write the directory. Since chainlink is open source we could try it to govern the access to the directory.
What I like about this is that the directory is just a directory. It can be used to build a lot of other applications on top of the offsets. You can use whatever blockchain technology, public or private, that you'd like. It can work with the existing registries as they are, or allow them to write to the directory when they'd like to try it.
Let me know what you think. We can continue this discussion on the ML or the wiki page.
Open Source Strategies, Inc.
Hello Si and Everyone
Apologies for taking so long to respond, I kept on thinking about this. As things stand now, I still cannot see how we can avoid having a public ledger for emissions reporting, trading and retirements if we want to ensure I high level of trust through transparency. Having though about it, my impression is that Si’s proposal is about something else.
@Si Is my interpretation correct that what you propose below with OrbitDB is directory (like a phone book - remember those?) that lists all available credits and enables interested buyers to know what is on offer and that any due diligence and transactions are left to the parties to sort out afterwards accoring to their own preferences. In other words, this precedes the hierarchy I spoke about: The first step is actually to make the market transparent by just making information more freeely available.
I haven't read the Chainlink Wihtepaper yet - will try to do that before our next discussion.
toggle quoted messageShow quoted text
Yes, it is a directory which, like open source projects, accepts "commits" from accredited members.
So yes, a lot of the due diligence and definitely the transactions are left to the members on their own.
On the transactions, I definitely think most of it should be handled to the members, for the simple reason that different countries have different rules about trading, cryptocurrencies, and money laundering (KYC/AML). We should just require that members register the ownership and most importantly retirement of credits correctly.
As for due diligence, the directory would not get involved in the due diligence and methodology of specific projects, though it could set rules about what generally is acceptable. For example, we could set rules about which specific standards we would accept, or more broadly what criteria are required for standards organizations. Should they be separate from issuing entities? What should their fee structure look like? Should their methodologies be updated recently?
This brings up an interesting question: Should CDM projects be included in our directory? What do you think?
On Fri, Sep 10, 2021 at 2:24 AM Christiaan Pauw <christiaan.pauw@...> wrote: