# Subsystem Design & User journey for net.zero app
### net.zero subsystems
Overview of subsystems interaction, mechanics, stateupdate logic and admissible actions.
* Policies/ External factors: Incluence the system and are external in nature.
* System Mechanics: All the actions that the system can execute without external intervention.
* Admissible actions: Are all user based actions.
---

---
Factors that influence the system by design are tokenomics and user scenarios.
#### Scenarios by user type:
* For institutional users daily triggers is not relevant. They are willing to pay for immutable data/ quartely/ annual.
* For general public daily triggers are important but dont have to be immutable. Its improtant to provide access to general public to build trust in the transparency of the data provided.
#### Revenue:
* Institutional subscription of data.
* Donations from public (open wallet used for gas fee, like wiki)
* % of GTAX
#### Expenses:
* YOY application maintanance cost (People/ Process/ Tech upgrade/ Migration)
* Insfrastructure cost
* EUMETSAT infrastructure cost
* Govt licence
* Gas fee
* Location reporting incentive for public users
* zero emmision for net.zero portal
---
## Customer Journey
### Landing page: where it all begins
the user lands on a simple landing page with a legal disclosure? to accept he has to link his metamask or other wallet?//ni8mare - Yes, a "connect to wallet" button can be made//
Once terms and conditions are accepted the user lands on a page with a search tab and small map next to the tab.
the user is able to search for location using google maps and place a marker. This prompts the user to connect the wallet. If successful the use then has access the portfolio view.
The portfolio view can be a Scope 1 or Scope 2 observations.
#### For scope 1:
The user has options for porfolio creation, amendment and deletion. MVP
at a later stage to import a portfolio from any of the standards.

**Links to goole map api:**
https://developers.google.com/maps/documentation/javascript/adding-a-google-map
https://developers.google.com/maps/documentation/javascript/marker-clustering
Should we give the user the option to add this to his favourites and create an account? or simply allow him to link his meta mask wallet?//ni8mare - Favourites might not be needed. Let's just track a few locations in total for this hackathon.//
//ni8mare - Dont know if its possible. But, can a user get the lat and lon of a location from the maps and then use those coordinates to mint an NFT for that location?//
// Simon: that brings us to the question who owns the NFT? Is it one NFT per location, which an be minted once? That would mean the user has the option to either mint a new NFT or view an existing one.
Once a marker is placed the user has a choice to monitor that location for Green House Gasses. User feature to manage favourites?
~~what if two people are monitoring the same location? gas optimisation? Not needed in POC~~
### earth.data/ monitoring page
The user can then observe a simple table that shows readings of the location and some interesting visualisation for the data below.

This monitoring panel has ~~an option for the user to mint non fungible tokens (NFT's)~~ when any of the Green house gasses (GHG) data exceeds the treshhold (trigger event) a system event triggers NFT minting every 24 hours or every >20 data points minimum for statistical significance. making it a gas efficient mechanism.
//ni8mare - Should an NFT be minted everytime a threshold
is breached, or should an NFT be minted for a location just once and the NFT changes whenever the air quality changes(A dynamic NFT)?//
//ni8mare - another option for NFTs would be to have different images for different air quality levels. Example - poor air quality would be one image, good air quality would be another.//
**NFT design options**( QR code of latitude and longitude in red green or amber, https://www.npmjs.com/package/qrcode supports SVG's)
**Reports** The user has the option to download all data (off chain data/ open Weather) or just the trigger data (on chain telemetry data). https://web3js.readthedocs.io/en/v1.5.2/
> []ni8mare - Solidity uses something called "events". Lets say everytime a user wants to get the latest air quality data for a location, he clicks on a button on the ui which triggers a function in our smart contract, which further gets data from the openweather api(for pollution data) using an external adapter. Once the response is sent back to the smart contract, an event can be emitted. Our frontend can listen for these emitted events and then update the UI. Now, I have to look into events myself.But, it can be done.
The NFT's act as an immutable evidence that a trigger event has occured. This decentralised evidence becomes by design the GHG disclosure.
We can provide some insights or graphs to show count of historical trigger event etc or the total volume of pollution etc
> []//ni8mare - Lets concentrate on the above sections for the UI. We can come to the offset mechanism later.//
### Data processing for Paid Customers off chain.
Once the customer has requested for location to be monitored.
1. Python logic layer to make location specific API calls for SAT pollution data every hour.
2. Data stored in the external database is checked for statistical anomolies and trigger event pushed every 24 hours only if pollution exceeds the treshold. Brining the total data points for a location to 365. making it extremely gas efficient.
3. Computation to check for 3 standardeviation shift in pollution pattern. Statistical process control principles.
4. Multiple data sources may need post processing, due to SAT latency delays (3hrs for EUMETSAT). It adds complexity to the computation. Hence server time matching is required.
5. This triggrer event is transmitted by chainlink oracle (can oracles only listen without a get request?) and (Can?) keepers mint ERC1155 NFT+ GTAX tokens with token URI.
6. Token URI links to computed data published on IPFS. Containing CID of 24 (Time, date, Pollution data points).
### net.zero/ offset mechanism.
This page shows GHG tax tokens minted for earth.data location based on total number of trigger events.
An option to pay the tax: The accountable parties can pay for the tax in stable coin or any crypto. When the fee is paid the tax tokens are burnt.
A very small portion of the payment is used to fund net.zero operations and make its operations net.zero. We can publish openly the cost.
~~Should we incentivise users for reporting locations?~~
Full majority of the payment is allocated to Government Sustainability initiatives or Treasury. We can publish openly the cost of tax paid to Govt.
//ni8mare - We might not need an admin page. Every user will be looking at all the locations being monitored.//
### Admin page
Should have a view to monitor all the locations being monitored.
An option to input fixed admin fee and net.zero fee. (This mechanism should be linked to calling contract for the tax token smart contract)
Some options for our stats such as performance, latency etc.
#### Limitation of gas
While gas is not a challenge in the testnet is poses a scalability issue in the main net (Layer 2 solutions may be an alternative).
Gas cost can be reduced by removing the dynamic nfts and using the front end for insights. Also reducing the frequecy of write requests to the blockchain may be a potential to save Gas Costs.
Removal of Dynamic NFT's means we may not be able to do cool things like imposing dynamic low ultra emission zones in places.
### State update logic and computation
1. Constraint: Open weather 60 calls/minute Cap: 1,000,000 calls/month
2. Constraint: Weatherbit 500 calls/day, 16 day forecasts, 60 minute forecasts, Non-Commercial use only. Data in American AQI format (needs to be adjusted to Euro AQI). Shared drive has the documentation.
Due to the constaints above we need to cap the number of locations to 10 for Proof of concept.
Due to the gas fee constraint for blockchain we can monitor 24 API calls perlocation for pollution triggers (above treshold) before we (decision made on a hypothesis test)push out a write request to blockchain. this can be done off chain. this unfortunatley can be done in solidity because solidity doesnt support floats.
### Keeper Logic & Requirements
1. Dynamic array for adding or removing locations. (Please be mindful of limitation imposed by API calls per weather server).
2. Can the keeper switch randomly between weather bit and Open weather randomly?
3. Can we restrict calls per location to hourly i.e. call location only once per hour.
4. I assume keepers can do some level of computation online? any limitations?
5. Spoke to Zak from chainlink on limitation of decimal/float for Solidity, there is a work around and we can dicuss it further if point 4 is feasible.
6. Point 4 creates a segway to point 6. Can we define triggers events based on treshold breach?