# Thesis v0.3 ## Notes from sync Tuesday, 30 Nov 2020 "Policy" vision: - Competing oracles - Transparency into the sources of an Oracle's output - Value add ecosystem : everyone is incentivised to participate (they all win if they stay together) - No perverse outcomes/incentives - Transparency into buyers as well as sellers - Make it possible for small, marginalized groups to take part in the system b/c low onboarding costs - Legacy compatible - Compatible with Article 6 of the Paris Agreement - Bulid synthetic products/derivatives on TOP of this - Incentives towards opening as much as possible - We want to be flexible for any kind of carbon sequestration projects - Anything green is fair game - Participation of multiple groups in defining the standard - "Consumer": Hansen dataset : what would motivate/how to make profitable? - Participation of multiple groups in defining the standard - We want data to have a *multiplicative effect* - This should function like public infrastructure that maintains itself and that anyone can contribute to (and profit from) : something that just becomes a feature of life and markets ## The story Imagine you go to book a flight on Google Flights, and beside your flight is a button where you can offset your emissions with transparency, and that you trust. ... ## My notes (Policy) We want: * (social coordination) Anyone to be able to contribute in a trustless way by: * Running an oracle (this gives competing oracles) * Starting a project * Running an on-chain marketplace/DEX/AMM for the carbon tokens * (social coordination) The platform to be able to adapt to changes in governance, project types/metadata, and entrypoints * (social coordination) Incentives to align so that people are incentivized to: * Keep the platform secure/void of hacks * Collaborate and work together * Use the platform to mint/sell tokens * (transparent) Be auditable/straightforward to verify so that governments and corporations trust the platform and can reliably use it to get actual results * Be resistant to corruption/greenwashing * (social coordination) Be highly composable * Means having a coherent ecosystem/set of token standards on the Tezos blockchain * Legacy compatible/easily upgradable to satisfy new and changing needs * (social coordination) Profitable to participate, and more profitable to participate over a long period of time * Encourage permanence in the oracles * Encourage permanence in projects (projects get more profitable over time) * (social coordination) This platform to act like highly adaptable public infrastructure that is, in a sense, owned and operated by no one person but that adapts rapidly as people use it and contribute to it. * This is Anil's point about good tech fading into the background into the fabric of society. A blockchain project done right becomes public infrastructure that maintains itself as people use it and interact with it. ## Open-Source Oracles It is essential that oracles *not* be black-box. Oracles should be on-chain and transparent, in a smart-contract optimised roll up (SCORU) to: * Prevent corruption * To make the oracle auditable * Prevent greenwashing Like open-source software (and, honestly, good science), making the oracle open source is essential so that we get reliable results that are reproducible and auditable, and so that we encourage innovation. Entities wishing to run an oracle who do not wish to openly collaborate or are worried about being forked can file a patent and claim intellectual property before publishing their oracle. They can also run their oracle on-chain in a low-level language like web assembly, which would make it difficult (though admittedly not impossible) for someone to figure out exactly what's going on in the oracle's model. Having black-box oracles is also simply not in line with the ethos of blockchains. In my mind, it makes little sense at all to use a blockchain if oracles are black-box. ### Monetizing an Oracle Entities providing an oracle can monetize it easily by: 1. Charging projects to use their oracle (this is very straightforward to do) 1. Running the oracle (Since an oracle is embedded in a SCORU, someone has to run it, and whoever runs it makes a profit from it. The higher the traffic, the higher the profit.) Even if an oracle gets forked and people use the forked oracle, there will likely be *plenty* of traffic for groups to monetize their oracles. Oracle providers will also likely be governments, universities, or research institutions, all of which would be incentivised to run a reliable, innovative oracle for reputation. Because reputation is so important to each of these types of entities, it is unlikely that any of these would fork someone else's oracle. Rather, they would take pride in developing their own competing oracle to the others out there. ### Forking an Oracle An oracle can be forked, but it's obvious when that happens. Whoever forks the oracle will (a) not be a respected institution like a University, nor (b) a trusted gubernatorial institution. (North Korea may fork an oracle, but the majority of the world won't trust it.) The reason for this is that governments and universities both have incentives to be trustworthy and reliable, and rely as much on reputation as they do on funding. If MIT forks Cambridge's oracle, it's a bad look for MIT. If some anonymous person forks an oracle, they are free to do so. But they will almost certainly not be well-respected, nor will they know the source code or the research as well as the ones who implemented it originally. Using their oracle could be risky, too, because they may have changed some small details in a perverse way. They will also likely not be able to update their oracle, keeping it state-of-the-art, as well as the original research team, since they won't be as intimately familiar with the research. ### Composability As outlined in "Policy," we want our project to be as composable as possible. Having open-source oracles encourages collaboration and higher levels of on-chain composability. ### Conclusion Considering the sheer volume of capital flowing into carbon sequestration, I think that keeping oracles black-box would invite corruption and would be antithetical to our work, and to the fact we're building on a blockchain at all. As outlined above, I think that there are still plenty of (economic and reputational) incentives for an entity to develop and run an oracle, and the risk of forking is quite low.