# Thesis v0.4

## The Thesis

This thesis outlines the innovation required to build a trustless, decentralised, globally-accessible, transparent, upgradeable, and competitive marketplace for the creation and sale of the externalities emerging from projects aimed at capturing, tokenising, and selling carbon.

This is built to be the infrastructure for a new asset class. It is highly scalable, dynamic, encourages transparent competition and collaborative research. Importantly, it significantly lowers the barrier to entry for projects seeking to harvest airborn carbon as a scarce resource in demand.

Independent entities can contribute profitably by:
1. Initiating a project and harvesting carbon/other positive environmental externalities
1. Building and maintaining an oracle (either metadata or legal compliance), and charge for its usage
1. Building and maintaining a DEX or an AMM

They can also propose upgrades to the contract structure, though not profitably.

## Policy

We want:
* 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
* Proposing upgrades to the smart contracts, in governance, entrypoint type signatures/addresses, or the contracts themselves
* The platform to be able to adapt to changes in governance, project types/metadata, and entrypoints
* 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
* 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
* Be highly composable
* Means having a coherent ecosystem/set of token standards on the Tezos blockchain
* Standard APIs for developing oracles/AMMs
* Legacy compatible/easily upgradable to satisfy new and changing needs
* 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)
* 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.

## Smart Contract Structure
1. One upgradeable `project` contract which project owners use to create new projects.
- Upgradeable in the sense that entrypoint type signature, governance, and actual contracts can evolve coherently.
1. A class of oracle contracts that validate projects, give the project tokens metadata, and give them permissions to mint.
1. A class of marketplace contracts that allow token holders to isolate value in their tokens and trade tokens on a marketplace
1. A class of oracles that validate land ownership rights/legal compliance (could be part of the metadata oracles)

## User Flow
1. A project owner initiates their project using the `project` contract.
1. The landownership/metdata oracle(s) validate the project and give permissions to mint tokens in a particular quantity and with specific metadata
1. The project owner sells their tokens on their desired marketplace

Anyone who wants can make an oracle and an AMM. Reputation plays a key role, so we will keep a registry and rating system of marketplaces and oracles. This provides a natural funding model for research across the world.

## Community Standards
1. Standards for token metadata to be used across the Tezos blockchain and ecosystem, in particular any AMM compatible with our platform
1. Standard API for oracles to interact with projects and give permissions
1. Standard API for DEXs/AMMs to get data on what projects exist (using views)

## Opportunities for Community Contribution
1. Build/maintain a DEX/AMM using the provided APIs
1. Build/maintain an Oracle for a special use-case or to compete with an existing oracle
1. Propose an upgrade to the contract structure

The first two of these are profitable

## Innovations

The innovations can be classified in three areas:
1. On-chain oracles with SCORUs (one of potentially many)
1. An AMM for semi-fungible tokens (one of potentially many)
1. A "fully upgradeable" smart contract that mimics Tezos itself (this so that it can function as public infrastructure and not necessarily rely on one team)

Also, community standards as outlined above.

## 4C
4C will:
1. Run/maintain a land ownership/token metadata oracle (probably for-profit)
1. Run/maintain an AMM for tokens that allows for precise value-capture and sale and facilitates marketplaces
1. Maintain a registry and rating system of oracles
1. Maintain the main `project` contract, facilitating upgrades when necessary. Potentially upgrade governance to include other parties as appropriate.

## Oracle Landscape (raw notes)

What will the oracle landscape look like?

You'll have oracles for specific projects. We should require transparency, or rate oracles higher if they are transparent. For example with specific sensors, specific plants, etc.

You'll also want "public infrastructure" oracles that allow you

You'll have a network of oracles. No single oracle will do for everything.

There should be some standard of transparency to "convince the blockchain" that the outputted data is good.

Since we want to lower the barrier to entry for projects, it's important to make as many publicly-available oracles as possible so **it's cheap to get certified**.

Research at universities can be in how to continue to lower the barrier to entry here. There is an obvious funding model. But this (a) provides the infrastructure for natural streams of research, and (b) funds them naturally.

There NEEDS to be a standard or a notion of "what it takes to convince the blockchain." Either that or some reputation system; you want to root out corruption so that this project *actually works*. You want to **prevent corruption**, rather than trying to root it out after it emerges.

All the calculations need to be reproducible, all the code open source, and all the data publicly available. You won't want to reveal business secrets ... hmmm ... except that's what a patent is for! Of course! Just patent, and it's very easy to verify if someone has violated your patent, because they will have to publish all their calculations publicly!! 🤯

**Everything has to be transparent, reproducible, and publicly available.**

You can track everything. You have to track everything.

You need a standard API output that is dynamic and able to be changed.

NOTE: This encourages a "franchise system" --

## Metadata (raw notes)

"Standards compliant" : there needs to be something there that regulated what metadata output looks like. You need standards to make sure metadata doesn't go wild.

This is the standard output API for the oracles.

This should be thought of as capturing and quantifying externalities of proved processes. Transparent and reproducible verification.

Verification. Oracles need to be publicly verifiable.

### Features of metadata structure

- It would be nice if they could be quantified: numbers, as a general rule
-