CleanApp Whitepaper (2018) p. 1 of 30 (cc) www.cleanapp.io

CleanApp Whitepaper (2018)

Boris N. Mamlyuk, Ph.D. CEO, CleanApp Foundation1

letscleanapp@gmail.com www.cleanapp.io

Associate Professor of Law

University of Memphis, School of Law

Abstract. CleanApp employs a patented (US Pat. No. 9525967) trash/debris/hazard/incident reporting process to allow parties to send reports about trash/hazards and dangerous conditions to a responding party or parties with an interest/obligation with respect to the reported condition/object(s). The CleanApp process and related processes provide a range of solutions to a very common trash/hazard under-reporting & under-responding problem. Current reporting apps (Litterati, DebrisTracker, SeeClickFix, PlasticPatrol, @WorldCleanupDay, LitterGram, and many others, as well as particular processes in other apps that can be said to fall within this genre, like roadside-hazard reporting in Waze) rely on dedicated app processes that place significant costs on a reporter. Standalone hazard reporting apps/processes provide part of the solution, but the main benefits are lost if a reporting party is still required to spend more than de minimis amount of time fulfilling the reporting function. We propose a solution to the time-spending problem using an open-source CleanApp reporting standard that can be integrated directly within numerous operating system environments (Android, iOS, Fire, FitbitOS, etc.). By encouraging native OS integration, the standard makes generating CleanApp reports as easy as interacting with a digital assistant (e.g., Siri, Cortana, OKGoogle, Alexa, etc.) or executing a pre-programmed IoT command. With express user permission, the standard also makes certain reports available to third parties who may have obligations/incentives to respond to the given CleanApp report(s). False reports, duplicate reports, and dataset integrity against attackers/vandals is controlled by parties that operate various CleanApp processes on decentralized networks. The CleanApp process itself requires minimal structure. At an operational global scale, the system envisions billions of active CleanApp users; with each user generating several reports daily, the CleanApp system proposed here is designed to handle billions of CleanApp reports daily. At such scale, the system operators, reporters & responders each obtain significant material incentives to further optimize the operation of discrete and overall systemic CleanApp processes—moving us forward towards an even more efficient subsequent iteration of CleanApp.

1 CleanApp Foundation is a nonprofit corporation incorporated in Tennessee (@CleanApp & www.cleanapp.io). We would like to thank Satoshi Nakamoto for showing the world the awesome power of ideas, clarity of vision, and execution. Those familiar with the Bitcoin whitepaper will find many parallels here. Those who are not, should be: https://bitcoin.org/bitcoin.pdf (& this key companion).

CleanApp Whitepaper (2018) p. 2 of 30 (cc) www.cleanapp.io

1. Introduction As a practice, trash/debris/hazard reporting on the Internet is widespread, and continues to proliferate.2 There are a number of standalone mobile apps dedicated to helping parties generate & dispatch trash/debris/hazard reports (hereafter, “Report(s)” or “CleanApp Report(s)”). Examples include Litterati, OpenLitterMap.com,3 SeeClickFix, PlasticPatrol, WorldCleanupDay, LitterGram, and others (as well as particular processes in other apps that can be said to fall within this genre, like roadside-hazard reporting in Waze). Millions of people also generate CleanApp reports on a daily basis on social media, even if they do not consciously identify their posts as such, or even intend for those reports to be sent to a particular responding party. Further, the widespread adoption of digital assistants and SmartHome/SmartSpeaker/IoT systems has also raised public awareness of the possibilities opened by natural-language voice commands and CleanBot integration.

Most everyone who has ever interacted with a RoboVac knows that it is only a matter of time before we can tell our Roomba (or equivalent) to “CleanApp the kitchen,” or “CleanApp this part of the playground,” or “CleanApp this sidewalk” – and that we already have the hardware, software and economic incentives to make this a reality.

Trend data and even conservative growth forecasts show a need for a harmonized approach to input, analysis, and output of trash/hazard data. The time for fully open-source global trash/hazard reporting/analytics/response standards has come. What follows are preliminary attempts to conceptualize these standards. 2. Problem In mid-2018, there is still a wide gap between the capabilities of current app/SmartAssistant offerings4 and the daily reporting needs of a large, and growing, global base of users. Our research has identified five main categories of problems with the current state of the art: (1) high time-input costs on Reporters; (2) need to trust a centralized authority; (3) lack of open-source data access; (4) lack of meaningful interoperable global data standards, and hence, global waste/resource analytics; (5) lack of reliable funding mechanisms for continuously scalable growth. The solutions proposed here solve all five problems, with multiple discrete potential solutions for each problem. 2.1 Problem 1: High Time-Input Costs on Reporters The dominant trash/hazard reporting technology in 2018 is still a dedicated app that is run on a smartphone or in some cases, on a tablet.5 Mobile trash/hazard reporting apps are usually localized in their functionality, permitting reporting within a bounded geographic area (like a city), though apps like TrashOut/Litterati/Pirika/WorldCleanupDay have global reach.

2 U.S. National Science Foundation, Grant Award No. 1746758 (Litterati) https://www.nsf.gov/awardsearch/showAward?AWD_ID=1746758&HistoricalAwards=false 3 Seán Lynch, OpenLitterMap.com – Open Data on Plastic Pollution with Blockchain Rewards (Littercoin) Open Geospatial Data, Software & Standards (2018) 3: 6. https://doi.org/10.1186/s40965-018-0050-y (hereafter “Lynch”). 4 An illustrative, non-exhaustive list of trash/hazard reporting apps is available as Appendix A. 5 OpenLitterMap.com is only available as a web app, with pending mobile development. CleanApp is actively developing a Google Action for CleanApp (a natural language input stream on the Google Assistant platform) & Alexa CleanApp skills, both in beta form. See also https://cleanapp.io/cleanappar/.

CleanApp Whitepaper (2018) p. 3 of 30 (cc) www.cleanapp.io

While the standalone-app approach may work well enough for some transactions, such as the use of the SwachhBharatApp in the context of the current SwachhBharat cleanliness campaign in India, it still suffers from the inherent weaknesses of a high time-input model. Relatively frictionless transactions are not really possible, since users who want to generate CleanApp Reports (hereafter, users who generate Reports are referred to as “Reporters”) must, at a minimum,

(1) know what app to launch; (2) open that dedicated reporting app; (3) take time to carry out that app’s input functions.

The time/opportunity costs of input increase overall transaction costs, limiting the practical likelihood of frequent, casual reporting transactions. The bottom line: it should be extremely easy for all of us to generate reports like the one below wherever we may be, but there is no frictionless input solution currently available, not to mention a robust decentralized market for this data. CleanApp solves both problems: (1) it makes input much easier, which in turn (2) helps to sustain viable responder markets for obvious needs like the one in the photo below:

Figure 1 - A sample CleanApp Report, illustrating problem.

CleanApp Whitepaper (2018) p. 4 of 30 (cc) www.cleanapp.io

2.2 Problem 2: Need to Trust a Centralized Authority The current version of OpenLitterMap.com (OLM) is a good illustration of the current problem with centralized authority, in the founder’s own view. Centralized verification is laborious, data-hosting is expensive, and a single mistake can erase months of user-input data, including imagery data.6 A system that requires manual distribution of Littercoin rewards is prone to accountability challenges, mistakes, and overall lack of structural redundancy. It is important to re-emphasize that OpenLitterMap.com itself raises these critiques in its inaugural peer-reviewed publication, so this should not be read as disparaging the overall scope of the current OLM embodiment, nor its potential, which is enormous.7 Rather, as OLM itself acknowledges, advances in the underlying Ethereum platform may permit a governance and operational structure like a DAO that is more robust, democratic (e.g., more decentralized) and far more automated than at present. Like OLM, other industry-leading applications like Litterati, SeeClickFix, World Cleanup Day App,8 SwachhBharatApp all have a centralized authority that administers the overall operation of the data gathering, analytics and distribution system. By itself, there is nothing inherently problematic about a data processing approach that uses a centralized authority. The overwhelming majority of our online activity occurs in interactions through centralized servers, including online banking, email, social media and so on. In the trash/hazard reporting domain, however, reliance on a centralized authority present unique problems. For instance, in the case of illegal dumping, it is often the case that what is being complained about is a lack of responsiveness by a governmental central authority. If that governmental central authority has outsourced its civic report/response functions to a private sector IT provider like SeeClickFix, this may create a potential conflict of interest: the private vendor’s chief customer is the municipality that has commissioned its app, therefore, there might be theoretical or pecuniary disincentives to underreport. As with the OLM case study above, it must be made expressly clear that the allusion above does not seek to critique SeeClickFix or any of its data solutions for individual cities. Instead, the analysis is meant to show the theoretical potential for conflicts of interest and/or underreporting. Furthermore, a vertical report-response chain that takes reports from a broad base of users and processes these reports for eventual responsive action by a city (or its contractor(s)) may not have the most efficient workflow for assuring prompt remedial action. Data and process bottlenecks may reduce functionality, and an attack on the central authority may completely debilitate the CleanApp function, leaving users without a reporting-response platform. Next, global litter and other civic complaint reporting processes inevitably run into jurisdictional borders, at micro- and macro-scales. To provide users with the analytics products they would wish to obtain from a streaming global database of waste data, a centralized service would need to have

6 Lynch (2018). 7 CleanApp Foundation, Crypto’s Killer App is Litter-ally Under Our Feet (1 of 5), available at: https://medium.com/@cleanapp/cryptos-killer-app-is-litter-ally-under-our-feet-1-of-5-eb064a6ab215 8 World Cleanup Day (www.worldcleanupday.org) was started by an Estonian non-profit organization, Let’s Do It World, and it has committed to providing open-source data that it aggregates from multiple sources. That data is available here: https://opendata.letsdoitworld.org/

CleanApp Whitepaper (2018) p. 5 of 30 (cc) www.cleanapp.io

access to practically all the world’s trash data. In other words, to be effective, a globally centralized service would need to be the Google of trash/waste/hazards. With information, it is relatively easy to provide this level of comprehensive coverage (global search results). But to operate a global streaming data intake system for imagery data, comprehensive coverage runs the risk of morphing into a global monopolistic takeover of citizen-civic interactions, and/or a surveillance arm of the state.

A Google of waste, or a Twitter of litter would be very difficult to displace from its dominant market position once a global base of users grows accustomed to the vast utility gains that flow from functional civic report-response operations.

There are numerous other concerns with a conventional centralized approach to data administration authority, but the above examples are sufficient to illustrate the need to explore alternatives. 2.3 Problem 3: Lack of Open-Source Data Access Most trash/hazard reporting processes currently work on what would traditionally be considered a “closed-source” data model. In consideration of the considerable work by app developers to bring users far better reporting utility than anything else available (in the far more user-friendly form factor of a mobile app), the core agreement with users is that a given CleanApp can aggregate the data in any way it wants, and BigData rights, so to speak, rest with the app that is investing in creating the BigDataset and BigDataAnalytics. Based on our research, the overwhelming majority of users may not know or care about the ownership/licensing status of something as seemingly insignificant and immaterial as a photo of trash. Our polling shows that when presented with this question in the abstract, users are generally far more interested in obtaining outcomes, learning about ways to confirm a responsive action. However, when the question is asked in slightly different ways, users realize that even though the photos may themselves seem worthless, the metadata enmeshed in those photos can reveal valuable user habits/behaviors/proclivities. Furthermore, though most users are generally comfortable sharing their data with app developers, users consistently respond with strong concern regarding open-source access to imagery data that is gathered in the confines of one’s home or other personal setting (common/shared spaces in dormitories, workplaces, etc.). As between different app developers in the CleanApp space, there is no known publicly-accessible data-sharing regime or data-sharing protocol. Furthermore, there is no customary or standardized format for CleanApp reports, leading to a dizzying maze of data points and historical report data.

Notwithstanding the observation above regarding an express commitment to open-source data access, many trash/hazard reporting apps have taken various unilateral steps to make data available to researchers, fellow trash reporting developers, and even share post-processed data visualizations (usually icons displayed upon a map).

Thus far, to our knowledge, only two organizations have expressly committed to making their data freely available for research purposes: OpenLitterMap.com (OLM) and WorldCleanupDay.com (WCD). But there are significant differences between the approach of these two organizations. OLM’s fully open-source data regime includes what OLM describes as 2-stage verification by OLM personnel, similar to the authenticity verification steps claimed to be undertaken by organizations

CleanApp Whitepaper (2018) p. 6 of 30 (cc) www.cleanapp.io

like Wikileaks. By contrast, WCD’s World Waste Platform9 includes significant original content gathered through the World Cleanup Day App, but also a significant amount of data that is aggregated from other litter reporting services. The key takeaway regarding open-source data access is that even the most strident open-source commitments—like those made by OLM and WCD—do not represent immediate/streaming access to something like “raw” user-generated reports. Furthermore, the open-source databases, while technically accessible, are not very user-friendly from the standpoint of a digital native user. What a user sees on an OLM/WCD map is not visually that different from what a user sees on a Litterati map. In fact, from the standpoint of a casual/non-research user who may want to browse the litter incident reports in her or his community, “closed source” databases like Litterati actually offer a much smoother UI. To close, irrespective of what platform is used, the user experiences the trash maps as more or less static representations (report icons superimposed on a map).

For current purposes, these data practices and visualizations might seem sufficient. But digital natives are demanding access to increasingly more accurate real-time data feeds. The only way to satisfy this demand now is to imagine a data aggregator like WCD that is able to obtain data-sharing commitments from every other global trash-tracking app development team.

At present, however, we observe apparent ambivalence among the trash/hazard reporting community to anything resembling streaming data-sharing or functional data interoperability: “good in principle, but still premature.” That is a problem. The apparent lack of momentum to resolve the open-source v. closed-source divide adds to fragmentation within the litter/hazard reporting community. Until it resolves this issue, TrashTech will continue to underserve a global community of eager users who crave a robust and secure civic reporting platform.10 When communities are underserved, litter goes under-reported. 2.4 Problem 4: Lack of Functional Interoperability Next, lack of functional interoperability in trash/hazard reporting heightens the likelihood of the emergence of proprietary “silo-ed” approaches to trash/hazard report-response functions. Here’s what that problem looks like in a few years:

Person A: “Siri, CleanApp the trash in the front yard, ask Vesta to do it.” Siri: “I’m sorry Person A, but Vesta refuses to obey my commands.” Vesta (in a whispering voice): “You got that right, Siri!”

The last line is playful, but the rest of the future dialogue is entirely conceivable in light of observed interoperability challenges today. Lack of functional interoperability means a lower chance that the trash in the front yard will be picked up, leading to more trash in the environment. Furthermore, first impressions correlate directly with likelihood of repeat, and/or frequent, app use. Unfavorable

9 https://opendata.letsdoitworld.org/ 10 Though nominally the narrow problem and use case under examination is litter reporting, it should be clear that the litter reporting is scalable to other objects/conditions that need to be CleanApped. Litter reporting is a useful proxy for thinking about resource management processes more broadly; lessons from the trash reporting and response mechanism presage other types of CleanTech/CivicTech interactions.

CleanApp Whitepaper (2018) p. 7 of 30 (cc) www.cleanapp.io

initial cross-platform interactions (even if the problem stems from something like tech congestion) will result in less CleanApp activity overall.

Further, the lack of a standardized approach to reporting means there is little to no interoperability between these various apps and/or their respective datasets and/or any harmonized response process(es).

Therefore, though a proprietary “silo-ed” approach to litter reporting may seem appealing at first, lack of open source data access requires users to place trust in the integrity of the reporting platform. This can lead to the emergence of closed-source monopolies,11 2.5 Problem 5: Lack of Stable Funding Mechanisms Inhibits Scaling One of the biggest problems to the successful implementation of CleanApp has been the classic chicken-egg dilemma. We know that once the platform is operating at a scale of ~100-500K active monthly users, it begins to generate enough revenue from access to its streaming report data to become self-sustainable and sustainably profitable. Please note that this includes micro-monetized rewards to individual users who submit CleanApp Reports. However, achieving those user rates is difficult without an initial expenditure of capital necessary to sustain a tech development, marketing, and user adoption. There are several solutions to this chicken-egg problem. (a) The first is to greatly reduce the time-cost of doing CleanApp Reporting activity by partnering

with or nudging an existing BigTech player such as Google. For the past year, we have been doing precisely this, with a petition that asks Google to activate CleanApp reporting directly in Android (without the need for a separate app infrastructure).

(b) Another approach is to leverage DLT advances to create an intrinsically scalable data

architecture for (1) accepting CleanApp Reports, (2) making those reports available for verification and/or optimization, and (3) opening acquisition channels for various CleanAppAnalytics products, including access to individual reports.

CleanApp is currently pursuing both of the above scaling strategies, among others. 3. Proposed Solution What is needed is a system based on a simple but robust open-source CleanApp standards and data-sharing/data-analytics processes that can run autonomously as markets for CleanApp reporting & CleanApp responder activities. Open standards will permit Reporters to submit Reports across a broad-range of input devices, from digital assistants operating on mobile phones or SmartWatches, to SmartGlasses, to GoPro cameras, drones, and in-home SmartSpeaker-type assistants (AmazonEcho/GoogleHome/AppleHomePod/etc.). A single reporting standard also accommodates a large and growing number of trash & hazard reporting apps. Harmonizing underlying data standards, practices and processes facilitates the

11 CleanApp Foundation, “All Our Patent Are Belong To You (CleanTech Edition)” (June 14, 2018), https://medium.com/@cleanapp/all-our-patent-are-belong-to-you-part-deux-2018-cleantech-edition-2f4b9b58d2a9

CleanApp Whitepaper (2018) p. 8 of 30 (cc) www.cleanapp.io

development of plural approaches to the input-time problem by multiple developers, operating on different incentive models. 3.1 Open Reporting Standards Lead to Much Higher Utility Open data standards and harmonized input processes permit Reporters to submit Reports irrespective of where they may be located—at home, on others’ private property, in public parks, in any city, in any country—without having to identify, download, and utilize a dedicated cleanup/reporting app for that particular area. The logic is basic:

The easier it is to submit Reports, the more likely Reporters are to submit them. Open CleanApp reporting standards heighten the likelihood of accelerated reporting activity because individuals would be able to use familiar reporting/micro-blogging services to perform CleanApp Reporting/Responding functions (using services such as Twitter for the data-hosting/data-security backend).12 3.2 Open CleanApp Standards Create Entirely New Markets An open-source CleanApp Report standard also permits a data structure wherein any two willing parties can transact directly with each other without the need for a trusted third party, raising the development possibilities for a wide range of different CleanApp responder processes.

“A” has scrap metal in the form of a rusty tractor and a few metal wheels laying around as “trash” in their field. “B” is a metal scrapper. Whatever device A uploads a CleanApp Report on for their “trash,” if B can easily access it, it raises the probability of an A-B transaction to reuse/repurpose that scrap metal. If the A-B transaction is successful & frictionless, it raises the likelihood of future A-B, A-C, B-D, E-F transactions, which is a net positive outcome because it facilitates recycling/reusing of scarce material resources.

3.3 Trustless-ish Reporter-CleanApp-Responder Transactions Are Possible

Like Ethereum or other distributed data structures, an electronic CleanApp reporting system based on distributed cryptographic proof instead of centralized verification/trust gives Reporters what they need—a system to submit reports securely, with robust opt-in non-attribution/anonymity protections and a range of data protections that are unavailable in current hazard reporting environments.

Moving from a purely centralized paradigm to a more decentralized paradigm, it becomes necessary to consider the possibility of a most decentralized DLT embodiment for CleanApp, operating numerous global and hyper-local data markets simultaneously.

CleanApp is currently researching which current Blockchain development platforms offer the optimal (resource-constrained) environment for deploying its vision of dynamic global data markets 12 Running “CleanApp on Twitter” is not only possible, but this functionality is operational. Every trash/hazard report tagged #CleanApp is an illustration of CleanApp Reporting. Next, existing services like SwachhBharatApp leverage Twitter for data-hosting/incident-reporting at national scales (India). Lastly, Twitter itself advertises several use cases where it, Twitter, has partnered with Transport for London and a town in Spain to operate Twitter as a civic reporting/response platform.

CleanApp Whitepaper (2018) p. 9 of 30 (cc) www.cleanapp.io

for trash/hazard/incident reporting. The leading candidates currently are Ethereum & IOTA, but we are additionally researching other development platforms.

Whichever platform CleanApp chooses for its in-house CleanApp development purposes, it must also be clear that we encourage the simultaneous development of other CleanApp processes and markets.

Everyone is better off when we have multiple I/O channels for trash/hazard/incident data and maximum number of potential transactional permutations between Reporters & Responders.

3.4 Market Coordination & Convergence It should also be clear that multiple market planes instantly create the need for harmonization. Market efficiency and liquidity is maximized when everyone can access one another’s API (or API-equivalent) to bargain over access to location data for a given “dumpsite” – something that in rational CleanApp parlance is not a “dumpsite” at all, but a cache of valuable recyclable resources.

A walk-though observation regarding an illustrative operation of CleanApp markets13 re-emphasizes the need for a shared open-source standard to create the conditions for maximum functional interoperability.14

Further, an open-source standard that incentivizes updating/upgradability with respect to matters like data storage & data security protocols permits evolution of the standard commensurate with general tech improvements in respective spheres. This has the potential of creating entirely new peer-economy cleanup processes and business models.

13 CleanApping & Plogging in 2021 (July 4, 2021), available at: https://cleanapp.io/2018/07/04/your-first-cleanapp-plog-in-2021/ 14 CleanApp:Standard, available at https://cleanapp.io/cleanappstandard/.

Figure 2 - at full scale, CleanApp offers global Uber-of-trash capabilities (see, e.g., Rubicon Global)

CleanApp Whitepaper (2018) p. 10 of 30 (cc) www.cleanapp.io

4. Market Need/Potential Adoption of CleanApp facilitates the emergence of myriad “UberTrash” services where micro-economy CleanApp contractors can submit bids for particular CleanApp areas (Z neighborhood) or types/volumes of materials (aluminum). Right now, those large potential sharing economy gains are not being realized due to a lack of a harmonized conceptual and technological approach to waste/hazards.

4.1 Objects at Rest Remain at Rest

Lack of interoperability & lack of harmonized standards for trash/hazard reporting result in increasing fragmentation in the CleanTech/CivicTech space. As a result, even in the most hyper-connected “smart cities” in 2018,

citizens are deprived of useful tech-based solutions to some of their most mundane, but also most annoying, daily micro-nuisances and micro-hazards. This leads to gross underreporting of trash/hazards, resulting in more trash/hazards (since the observed rate of abatement is far lower than the rate of production of trash/hazards).

Socially and psychologically, this can lead to desensitization to the environmental and health perils posed by seemingly “small-scale” litter. With litterscapes becoming the new normal,15 and no data-driven way to tally the actual global toll of littering,16 illegal dumping & preventable hazards, we are stuck in a data-deficit/ostrich paradigm.

We have no idea how much trash is out there, and because we do not have the answers to those questions, we render the questions less urgent than the other questions for which we do have good data feeds. This is a core global problem CleanApp is working to solve. Our big questions are these: “how much trash has humanity produced, and is producing; where is this trash going; how can we recycle, reduce, reuse as much of those resources as possible, using all of the new breakthrough tech tools being made available to us; […]?”

4.2 Objects in Motion Create Transactional Opportunities

Below, we outline a solution to the trash/hazard under-reporting problem using a peer-to-peer distributed timestamp server to generate robust immutable chronological records of CleanApp Reports. Our solution also facilitates and incentivizes a broad range of transactions between CleanApp Reporters & potential responders to CleanApp Reports. Our proposal relies on numerous operational open-source data structures and published proof-of-concept/proof-of-work literature.

15 Hari Kumar, Kai Schultz, ‘The Dump Killed My Son’: Mountains of Garbage Engulf India’s Capital, New York Times (June 10, 2018).

16 There are many current projects that seek to crowdsource global trash data, but each one has limited reach, which is a core problem that CleanApp Foundation seeks to solve. Because of limited data, the most robust studies we currently have regarding the global impacts of litter and trash pollution focus on very narrow questions, such as the way microplastics enter the human food chain. Jessica Glenza, Sea salt around the world is contaminated by plastic, studies show, The Guardian, September 8, 2017.

CleanApp Whitepaper (2018) p. 11 of 30 (cc) www.cleanapp.io

We are also mindful that an entire CleanApp ecosystem can also be run as a proprietary closed-source BigTech service (e.g., AmazonCleanApp, GoogleCleanApp, SiriCleanApp), operating on various semi-permeable/hybrid/public-private data governance regimes.

In our view, BigTech participation is this TrashTech space is both welcome and inevitable, given the billions of dollars in new commodity-trading and services revenues made possible by new CleanApp markets.

Therefore, in illustrating a particular CleanApp embodiment, at scale, we will draw on existing BigTech product/service offerings to showcase how CleanApp can be incorporated to offer immediate value to end users and firms. As patent holders whose patent claims cover aspects of the underlying CleanApp processes described here, we express no preference at this time concerning the eventual optimal CleanApp embodiment(s).

Our research and analysis suggests that the most likely market outcome in the near term (2018-2028) is the emergence of multiple CleanApp services competing in the same marketspace.

In full disclosure, we are actively lobbying Google & other BigTech firms to adopt the CleanApp standard described herein, including hosting an active public advocacy campaign to nudge Google to activate trash/hazard reporting directly in Android (information available here). Further, we are preparing a draft international ISO standard in effort to standardize the data privacy protections outlined in this CleanApp Whitepaper and elsewhere. Accordingly, in discussing standards, we also take the liberty of suggesting several business/revenue models that will sustain and underwrite the expansion of CleanApp tech. As a starting point, Hitachi Data Systems predicts that the global BigData/SmartCity market will be worth $7 Trillion by 2021.17 As there is no global trash/hazard reporting-response market as such, this $7 Trillion figure is likely an underestimation. To find out much this CleanApp Report is really worth, we must create CleanApp marketplaces for such reports:

17 Mark Bowen, Hitachi says ahead of GITEX that Big Data market will top $7 Trillion by 2021 (September 4, 2017), available at: http://www.intelligentcio.com/me/2017/09/04/hitachi-says-big-data-market-will-top-7-trillion-by-2021/

CleanApp Whitepaper (2018) p. 12 of 30 (cc) www.cleanapp.io

5. Definitions Our goal in this paper is to outline technical parameters and baseline consumer expectations in a vernacular that is accessible to as many different audiences as possible; if our analysis is too full of jargon at particular points, we encourage reference to the following definitions. CleanApp [noun/verb; \ˈklēn-ˌəp\]: (1) an act or instance of cleaning using tech to report trash or hazards that need a prompt response (“The children were #CleanApp-ing trash on their field trip to the Tesla Gigafactory.”); (2) in colloquial usage, using any form of tech to publish a trash/hazard report, to submit that report to a responsible party, and/or a response to any such report (“Chicago O’Hare just installed CleanAppBots that respond to passengers’ trash & hazard reports, how cool is that?” “Yeah, when O’Hare started doing CleanApp, they noticed passenger satisfaction rates and overall cleanliness went way up.”). CleanAppBot: a robot engaged in the act of responding to a CleanApp Report; such as iRobot Roomba, AmazonVesta, Nvidia #Trashformer, etc. See also: CleanApp Responder. CleanApp Database(s): centralized or decentralized encrypted open-source databases that process, refine, store, optimize, and/or publish CleanApp Reports that are intended for public distribution by CleanApp Reporters or intended to form the basis for CleanApp transactions. Additionally/alternatively, centralized encrypted closed-source databases that handle CleanApp Reports for non-public environments (school or corporate campuses, secure airport facilities, etc.). Additionally/alternatively, privately-run database structures for closed networks like single-family residential home environments (e.g., various CleanApp intranet forms). CleanApp Metadata: user-generated and CleanApp-optimized data concerning the object or condition being reported, including, potentially, imagery data, user accuracy ratings, geolocation data, CleanApp report log data, historical progression data, etc. CleanApp Microdata: “lowest-denominator” level of actionable data, including user-generated, peer-generated, and/or machine-generated object recognition & geometric data (answers to the most basic “what,” “when,” “where” questions with respect to a reported object and/or condition). CleanApp Report: an electronic data record for a trash object or hazardous condition, containing accurate X/Y/Z (lat/long/elev) location, time, and imagery data. Also known as: “incident report,” “trash report,” “litter report,” “graffiti report,” “slip & fall report,” “spilled-milk report,” etc. A CleanApp Report can be submitted in any number of ways, such as through a dedicated app, in a digital assistant interaction (speaking with Siri or Alexa) or, via a public post on social media, like Twitter. If a report has necessary incident data and can be reasonably construed to request a response action, it may be properly considered a CleanApp report. After an individual submission or machine data uptake (in the case of Twitter/FB/Instagram scrubbers) of a CleanApp Report, each CleanApp Report obtains a unique digital signature that contains both CleanApp Microdata & Metadata concerning the object or condition being reported.

Anon CleanApp Report: a CleanApp Report for publication that is securely scrubbed of all identifying metadata information concerning the CleanApp Reporter; e.g., an anonymous non-attributed CleanApp Report. Aggregate CleanApp Report: a CleanApp Report that is the aggregate of multiple CleanApp Reports from multiple CleanApp Reporters.

CleanApp Whitepaper (2018) p. 13 of 30 (cc) www.cleanapp.io

Composite CleanApp Report: a CleanApp Report that is composed of multiple CleanApp Reports concerning a given object/condition from a single CleanApp Reporter. Chrono[logical] CleanApp Report: a metadata CleanApp Report concerning progression/diffusion/volume data that is drawn from multiple CleanApp Reports over a period of time, it can be visualized as a type of metadata time-lapse. Enterprise CleanApp Report: a CleanApp Report that is not published, and which is directed to CleanApp Responders within a particular organization, such as a university, a laboratory, a hospital, and so forth; different organizations (military bases, government buildings, laboratories, schools, hospitals, etc.) have diverse data privacy and data-collection regimes, but also have urgent need for CleanApp-type reports covering objects/conditions at those locations. Whatever tech is used to generate a given report, and however that report is geofenced and compartmented, the basic understanding of an Enterprise CleanApp Report is that it comports, in form, with the baseline reporting expectations of the given enterprise organization. So, a “Wal-Mart Enterprise CleanApp Report” is one that comports to Wal-Mart data-privacy/data-collection policies, irrespective of the hardware/software used to generate that particular report. Shorthand usage for “Enterprise CleanApp Reports” can also omit the word “Enterprise,” such that what’s understood by a “SpaceX CleanApp Report” is a SpaceX Enterprise CleanApp Report, a CleanApp report that conforms to SpaceX internal rules for permissibility, distribution, and/or actionability. Enterprise CleanApp Reports can be attributed or anonymous; open-source or closed-source (see Semi-Private CleanApp Report). Private CleanApp Report: a CleanApp Report that is not meant for any distribution, such as a private trash report in the confine of one’s home, items of clothing, auto, or other property (e.g., “CleanApp this stain on the backseat of the Tesla, pls.” “Alexa, CleanApp the baby poop off the lab coat & tux shoes.”). Semi-Private CleanApp Report: a CleanApp Report that straddles the line between private and enterprise-grade expectations of privacy. In this report genre, a CleanApp Reporter may not want any imagery data or HomeMapping data to be provided to third party vendors, 18 but may want to opt-in to share CleanApp Report metadata with commercial providers of tailored consumer transactions based upon the CleanApp data.

For example, if a CleanApp-er is sending reports about spilled coffee every other day, they may just be clumsy; on the other hand, they may have a broken coffee pot or travel coffee mug and may not mind being contacted with offers to buy a new coffee pot based on their CleanApp Reporting History. A user submitting increasingly exasperated CleanApp reports in the home may also not mind

18 Alex Drozhzhin, Xiaomi Mi Robot Vacuum Cleaner Hacked, Kaspersky Lab Daily (January 4, 2018), available at: https://www.kaspersky.com/blog/xiaomi-mi-robot-hacked/20632/ (“[Xiaomi RoboVac collects & uploads] several megabytes of data daily to Xiaomi servers. [...] this data includes the names & passwords of the Wi-Fi networks the device connects to & the maps of rooms it makes with its built-in lidar sensor.”); Michael Reilly, Roomba, The Cute Little RoboVac, Has Got a Side Hustle: Your Roomba Is Also Gathering Data about the Layout of Your Home, MIT Technology Review (July 25, 2017), available at: https://www.technologyreview.com/s/608344/your-roomba-is-also-gathering-data-about-the-layout-of-your-home/

CleanApp Whitepaper (2018) p. 14 of 30 (cc) www.cleanapp.io

receiving offers for new generations of CleanAppBots or in-home cleaning services of the sort offered by Amazon Clean or other third-party providers.

Figure 3 - A sample CleanApp Report submitted on Twitter without any sort of CleanApp interface, connection, or prompt. Here, a Starbucks customer complains of dirt in a particular location (Aliso Creek/Alicia Starbucks) over a particular period of time (a few days).

CleanApp Reporter(s): individuals (and, increasingly, machines) that submit first-party CleanApp Reports. CleanApp Responder(s): individuals, organizations, agencies, machines, etc., that respond to CleanApp Reports submitted by CleanApp Reporters. CleanApp-er or CleanApper: an individual doing CleanApp reporting and/or responding activity. CleanApping: act(s) of performing CleanApp Reporting or CleanApp Responding functions. CleanAppMap: a dynamic real-time mapping engine that provides access to CleanApp Reports made public by CleanApp Reporters (individually or via default public-sharing opt-ins), and/or CleanApp Report metadata (especially in situations where CleanApp Reporters desire anonymity/non-attribution), and, additionally, makes certain data streams available to third party responders, researchers, and other interested parties.

CleanApp Whitepaper (2018) p. 15 of 30 (cc) www.cleanapp.io

CleanAppTrack: a process for tracking CleanApp Responders’ responsiveness to a CleanApp Report. HomeMapping: processes through which spatially-aware tech (smart speakers like AmazonEcho, GoogleHome, Apple HomePod, etc.) create accurate 2D/3D maps of a typical home environment; a process by which users label locations in a home for use in tech applications, such as CleanApp (e.g., “Siri, this is my kitchen. When I say, ‘CleanApp the kitchen’ I want you to send my Roomba to this room, ok?”) IndoorMapping: a process by which spatially-aware tech (smart speakers like AmazonEcho, GoogleHome, Apple HomePod, etc.) is able to create accurate 3D maps of any indoor environment; a process by which users label locations in an indoor environment for use in tech applications, such as CleanApp (e.g., “Siri, this is Server Stack A. When I say, ‘CleanApp Server Stack A’ I want you to send the scrubber to this area, ok?”) Reporting History: a CleanApp user’s encrypted log of submitted reports, accessible solely to the CleanApp Reporter, containing all metadata (minus imagery data) for default-saved reports, minus anonymous reports, which are not stored in CleanApp Reporting History. VirtualAssistant CleanApp: CleanApp activities (reporting, tracking, responding) that are facilitated by

AlexaCleanApp: a prospective AmazonAlexa/AmazonAI-driven CleanApp interface. OkGoogleCleanApp: a prospective Google-driven CleanApp interface. SiriCleanApp: a prospective Siri-driven CleanApp interface.

[…] 6. Transactions By this point, we have several working definitions of core terms, which themselves give a rough idea of how the system is supposed to work in a globally-scaled embodiment. We also provide numerous use cases and visualizations at www.cleanapp.io, as well as several use narratives. 19 The basic contours of that system are: (1) plural input channels for submitting CleanApp reports, including through Twitter, FB, various trash/hazard reporting apps (e.g., OpenLitterMap), and various augmented reality / wearable OS ecosystems); (2) harmonized data-aggregation and optimization processes, for refining “raw” CleanApp Reports & submitting to previous, putative and/or potential CleanApp Responders; (3) feedback and process-improvement mechanisms, for dynamically improving CleanApp Report collection and distribution processes. For most people, the system outlined above evokes a centralized “CleanApp Bureau,” something like a global “Ministry of Trash” that receives, processes, and sends out CleanApp data. A 19 CleanApping & Plogging in 2021 (July 4, 2021), available at: https://cleanapp.io/2018/07/04/your-first-cleanapp-plog-in-2021/

CleanApp Whitepaper (2018) p. 16 of 30 (cc) www.cleanapp.io

centralized system is certainly feasible, and has many desirable operational (and revenue-generating!) attributes. However, a decentralized system has even greater long-term potential.20

To better understand the scalability and robustness of CleanApp as a decentralized process, we can analogize to existing blockchain data structures.

This allows us to heuristically define a CleanApp Report as a chain of unique digital data stamps, each of which is individually valuable. In other words, by thinking of different parts of various CleanApp processes as discrete transactions, we can identify microeconomic factors that motivate parties at various stages of these transaction chains.

We can explore the gains of decentralization by unpacking the operation of several representative CleanApp transactions.

20 We are actively recruiting “Hackterns” through the CleanApp Hackternship Program to explore the potential of different DLT platforms & CleanApp/CleanApp-like applications. Our Hackternship, while modeled on the Ethereum Foundation’s “Hackternship,” does not offer express financial incentives for milestone achievements. Instead, our Hacktership program seeks to incentivize individuals through contractual guarantees to certain CleanApp IP rights. To support the work of our Hackterns (on #TrashHash, @littercoin, & CleanApp:Chain), please donate to: 0x29A31e68a5c3b052Ac04A663f1e60a2cf184FF53.

CleanApp Whitepaper (2018) p. 17 of 30 (cc) www.cleanapp.io

6.1 One-Off CleanApp Reporting A single-iteration/one-off reporting transaction is very easy to conceptualize & process. In a smartphone embodiment, it can mean something as easy as snapping a photo and submitting it to a responsible party for cleanup.

Figure 4 - a sample one-off CleanApp Report interface, where a casual user can submit a simple condition report with one-button reporting. The key for facilitating reports is ease of execution, with ideal embodiments using pre-programmed smart buttons, digital assistant prompts (“Siri, CleanApp this bridge.”) or higher-order digital assistant interactions (“Alexa, CleanApp the slime on this bridge.”). The key question here is, what’s being CleanApp-ed?

Please note in this visualization that the bridge may appear “clean” to one person, but “dirty” to the party generating the CleanApp report. This is because “cleanliness,” like space-time, is a relative concept. Let us assume this is a photo of a bridge in a botanical garden frequented by families. Because the bridge is in a semi-public space, we can further assume that there will be a range of possible responses to conditions on the bridge. On one end of the spectrum, there will be experienced CleanApp users who walk past this bridge and may not see objects/conditions that, in their view, call for Reports. On the other end of the spectrum, there might be users who submit a high-urgency CleanApp Report based on a perceived threat that only they have detected. This range of possible responses is only natural, given that there is no objective standard of cleanliness for this bridge that would be known by any responsible party from this photo report, even a human actor who is familiar with the particular bridge in question. Nonetheless, it is important to note that a good faith CleanApp Report comprised of a single photo of a condition represents the reporter’s belief that the object or condition being reported in the photo would be reasonably identifiable from that single photo. In other words, merely by generating a CleanApp Report, the Reporter is signaling that the Report contains identifiable actionable data. Below is the screenshot again, for ease of reference.

CleanApp Whitepaper (2018) p. 18 of 30 (cc) www.cleanapp.io

In this CleanApp Report, is there a clear object or condition that can be acted on? It depends:

A. To some viewers, like third-party analysts or Responder unfamiliar with the bridge in question, there may not be anything of note. Some viewers may even consider this bridge flawless in aesthetic/cleanliness or design/structural terms. To them, this report would have little actionable value.

B. A machine analyzing this report could detect something else entirely. We can train our ML

algorithms to infer that there is something wrong in the picture merely because we have a credible user submitting a CleanApp Report. Furthermore, we can reliably train machines to identify problems on this bridge based on a user’s prior history of CleanApp reports. If a user habitually complains of slippery conditions or hazards, there may be a high probability they are complaining about a slippery condition on this bridge, even without identifying it as such in this CleanApp Report.

C. But it must also be borne in mind that individuals familiar with the bridge may have an

immediate expert reaction to this otherwise sterile Report, noting, for instance, that the third plank from the bottom, on the right hand side, is rotting, and that several nails & bolts are loose.

The key insight here is that CleanApp Reporting/Analysis/Responding transactions are deeply contextual. We’ve all heard the adage that “One person’s trash is another person’s treasure.” We agree with this premise, which is why the CleanApp 2.0 standard is expressly non-normative. Just because there exists a CleanApp Report for a given location/condition/object does not mean there is something inherently “bad” in the photo—it simply signals the Reporter’s belief that the scene captured in the Report can and should be improved, in different conceivable ways. This means one person’s trash can be another person’s hazard. That person’s hazard may be ranked “high urgency” by a third person. Alternatively, that same hazard may be ranked “low priority” by a fourth person. But whether the photo above is deemed to be actionable and/or not, have high and/or low urgency (by different users and/or ML analytics), the ambiguous/ambivalent Report is valuable in and of itself by serving a valuable cautionary function.

CleanApp Whitepaper (2018) p. 19 of 30 (cc) www.cleanapp.io

Subconsciously and/or on a probability-based analytical level, here’s what the single-photo non-textual Report is saying:

Dear Consumer of this CleanApp Report: Based on our analysis, we don’t know what the Reporter wanted us to CleanApp, but just so you know, the user who submitted the report is a 4.7-star user, so chances are high the report is not vandalism, and there’s probably something the Reporter wanted CleanApp-ed. Sincerely, @CleanApp

How could that ambivalent, textless, single-photo report be remotely useful to anybody? In terms of just the cautionary function above, it is potentially valuable to anyone who wants to cross that bridge. It may be especially valuable to individuals/firms that plan to use the bridge for particular purposes, such as photo shoots or video shoots, uses that may place unusual loads on the structure – or uses that have heightened stability or liability concerns. Moreover, the particular report above may be very useful to the owner/operator of that bridge to know that users have found something to CleanApp on it.

A supermarket that suddenly gets 17 unique CleanApp Reports in a time span of 30 minutes for a particular location in Aisle 7 gets actionable data just from the submission of the reports even if no human or machine analyst can identify the exact nature or precise location of the object/hazard being complained of. At a minimum, the store/facility manager can put a warning cone at that location or dispatch an employee to investigate further.

Please note that revenue-positive models already exist whereby responsible parties (like municipalities or stores) pay flat subscription rates or per-report bounties even for this relatively low data level of reporting. Considering the plurality of property owners in various sectors who face potential premises liability exposure or merely want their properties to be maintained to highest standards of visitor satisfaction (such as in the hospitality sector) – it becomes obvious that there is substantial revenue potential coursing through dynamic global CleanApp database structures. From in-home to enterprise-grade to CivicTech/SmartCity applications, a CleanApp system is a veritable gold mine. Literally. Just consider those mangled charger cords you often see laying on the ground, or busted old flip phones or other electronics. Most everyone knows there are small quantities of gold and/or copper and/or other valuable metals in those gadgets. And from now onwards, we also know that there are millions of potential CleanApp Responders who would pay a small sum for real-time access to that CleanApp Report:

Small sums (x) global user base (x) time = very large recurring revenue stream With standardized CleanApp tech in enough hands, credible natural language expressions describing a given Starbucks as relatively “dirty” and in need of “CleanApp” suddenly become very useful and actionable – even without imagery data. Moreover, there are many ways to incentivize the user to add additional inputs of actionable data to a given CleanApp Report.

CleanApp Whitepaper (2018) p. 20 of 30 (cc) www.cleanapp.io

Incentive structures to obtain additional data from CleanAppers can include requests that a one-off report be accompanied by a voice command, or text input that labels/tags/describes an object/hazard in a more specific way. Report-tagging can be gamified, with all CleanApp users automatically assigned to one of, say, two teams, and the two teams compete head to head on the number of CleanApp reports that are “tagged & verified.” Projects like OpenLitterMap’s @Littercoin offer ETH-based tokens and “experience points” in exchange for providing verification/tagging information. Litterati offers numerical badges for users—which gives progressively higher standing in the large and growing Litterati community. Alternatively, a photo-only Report can be tagged/processed/analyzed by third-party analysts/machines, yielding CleanApp object/condition data of varying levels of accuracy depending on the quality/parameters of the input image, in context.

There can be many more ways to incentivize data inputs, but the general parameters and value propositions of this transaction are sufficiently clear.

6.2 Composite CleanApp Reporting Transactions Because they took the time to notice & report an objectionable object/hazard in the first place, CleanApp Reporters can be said to be highly-motivated in obtaining a remedy for their complaint. Moreover, in the case of especially hazardous or unwieldly items of trash or a place of illegal dumping, the CleanApp Reporter may be interested in registering subsequent CleanApp Reports to highlight the persistent nature of the problem, the lack of an adequate response by responsible parties, and/or for any number of other reasons.

From a systemic and machine learning standpoint, the more reports a CleanApp Reporter generates for an object of trash, the better. For instance, having multiple reports over space permits existing image recognition algorithms to construct a 3D model of the trash and/or condition (photogrammetry). Multiple reports over time allows machine learning of trash decomposition/dispersal rates. Responders can make better data-driven decisions the more reports they have for a given item, such as when to schedule pickup for this type of trash object or when to schedule cleanups for these, say, recurring types of conditions.

Lastly, the original Reporter may be in the best position to keep track of the condition or object s/he originally reported. Consequently, CleanApp data structures must incentivize reporters to submit subsequent reports for a given object/condition, and permit linking these multiple reports concerning the same object in a form of Composite CleanApp Report. Visually, the composite report can be thought of as a set of overlay layers, or even a timelapse showing progression over time. Another way of visualizing a composite CleanApp Report structure is through a 2D “zoom-in” or in a 3D augmented reality “walk-through” directly to the object.

CleanApp Whitepaper (2018) p. 21 of 30 (cc) www.cleanapp.io

Figure 5 - a sample post-processed Composite CleanApp Report, where a Responder is able to reconstruct the nature of the hazard or requested CleanApp action from a simple progression of 3 progressively higher zoom photos (arrows added for emphasis). Context, the photo is of a hazardous waste storage locker in a consumer area of the outdoor section of a U.S. Home Depot store. The photo was taken moments prior to children on a field trip were given a tour of this store, including the outdoor goods department.

For objects that may be camouflaged into their surroundings, or are otherwise difficult to detect from a single image, these composite reports can mean the difference between a CleanApp Report that triggers a response, and one that is potentially flagged as “unactionable,” given the difficulty of discerning the actual hazard being reported.

Moreover, access to a CleanApp Composite Report can mean the difference between an effective response (where the Responder is actually able to locate and remove the object) and a failed response (due to inability to locate the object).

Irrespective of how we picture these composite reports, the actionable data yields from these composite reports are undeniably higher than a one-off report. Therefore, the generation of composite reports should be incentivized and rewarded. This does not necessarily mean imposing additional time-input costs on the Reporter. Composite rewards can be incentivized by asking users to set higher-quality reporting defaults, such as opting-in to composite photo (e.g., iOS Live Photo format) or video formats by default, and so on.

CleanApp Whitepaper (2018) p. 22 of 30 (cc) www.cleanapp.io

6.3 Aggregate CleanApp Reporting Transactions CleanApp Reports will generally acquire more value & more urgency when other CleanApp Reporters submit reports concerning that or similar object or condition. To extract the higher value from Aggregate/Composite CleanApp Reports, CleanApp must be able to chain multiple reports in different ways. The Reports can be chained into a linear series (appropriate for a Composite report of multiple items of trash that can be said to emanate from a single source, such as multiple advertisement flyers that can be logically traced to a single point of origin). Alternatively, the Reports can be chained into a branched/blocked chain or matrix, under a peer-review/peer-verification mechanism. In this embodiment, a subsequent reporter could ask an earlier reporter to corroborate that the trash object the second reporter is reporting is, indeed, the trash object the first reporter submitted a report for. In exchange for corroborating/verifying/linking the subsequent report to the second report, a later-in-time reporter can reward the earlier-in-time reporter with compensation, badges, a positive rating, or any other form of consideration. Multiple parties can be incentivized to corroborate/tag/verify/improve the Aggregate CleanApp Report. These incentives can take many different forms. For instance:

The first party knows that linked reports are likely to get more visibility from potential responders. Both parties can be credited with additional consideration when they create a a verified link between Reports. The incentive for the second reporter to attempt a link with an earlier report is the desire to benefit from “snowball effects” – similar to upvoting effects on social media or popular sites like Reddit. A peer-verified report is more valuable than an individual report, which creates a higher likelihood of the second reporter verifying the report of a third later-in-time CleanApp Reporter, whose report is preliminarily linked to the earlier double peer-verified Aggregate Report based on provenance/condition/time data markers. It goes without saying, but the relevant reward structure must be coded in such a way that first Reporters have higher rewards, and rewards drop off for each subsequent Reporter. Peer-review and peer-verification would still be compensable, but at progressively lower rates.

In this embodiment, the verification scheme parallels the blockchain transaction mechanism for Bitcoin, where an owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership. Here, the First Reporter endorses the Second Reporter’s Report by verifying its public key and signing its private key, transferring a “credibility upvote”—of sorts—to the Second Reporter’s Report. In exchange, the Second Reporter gives First Reporter something of value sufficient to motivate the First Reporter to attempt to verify the Second Reporter’s Report. That value proposition will be different in different reporting cultures. If scripted in a way where both parties are incentivized to peer-review one another’s potentially-linked reports, data robustness is improved. Furthermore, this incentivizes third/fourth/fifth/etc. Reporters to corroborate the validity of the earlier Reporter’s Report. Each subsequent “upvote” rewards the Party doing the voting while also rewarding each of the parties earlier in the chain for providing a high-quality trash/hazard report. Building on Bitcoin’s process chart, and replacing Owner 1, 2, 3 with Reporter 1, 2, 3, we get:

CleanApp Whitepaper (2018) p. 23 of 30 (cc) www.cleanapp.io

Chaining/linking CleanApp Reports anticipates/solves the problem of multiple discombobulated/overlapping/redundant CleanApp Reports. The redundancy problem is especially large in cases of moving trash or hazards, such as with debris during natural disasters. Without chaining reports into series/composites/aggregates, we also introduce the problem of over-rewarding reporters for submitting same-value reports. So, whatever the reward is for submitting a report in a given context, Reporter 1 would get the same reward as Reporter 2 as Reporter 3. This reward structure is simpler to code because it is essentially a discombobulated set of one-off Reports, but as described above, one-off reporting structures make it far more difficult to glean actionable data than composite or aggregate CleanApp Reports. One common solution to the need to link/chain reports is to introduce a trusted central authority that would check every report to see if it is duplicative or novel for purposes of assigning rewards. After each report, the report must be verified to make a quality determination. The problem with this solution is that the fate of the entire system depends on the capabilities of the central authority to handle an extremely large volume of reports, with every transaction having to go through them. This is impracticable for any large authority without a great deal of machine learning and autonomous processing. Further, we need a way for Reporter 2, 3, et al to know that the previous Reporters did not agree to link any earlier transactions with a Responder – meaning, that the object/hazard is still “live” and in need of a response. As founding blockchain documents teach us,

the only way to confirm the absence of a transaction is to be aware of all transactions. To accomplish this without a trusted party, transactions must be publicly announced, and we need a system for participants to agree on a single history of the order in which they were received.

The subsequent Reporters need proof that at the time of each transaction, the majority of nodes in the CleanApp database agreed that the trash/hazard was still a live problem. A dynamic database structure that permits and incentivizes report linking can provide statistically robust verification mechanisms that a given Report is still in need of a Response. Reporters can be effectively incentivized to learn whether the trash/hazard object is still outstanding by various means. For instance, when Reporters cease to link-back to an earlier report, that earlier report can be said to be orphaned – it represents object(s) that might have been cleaned-up, moved (as in the case of flash

Reporter Reporter Reporter

Reporter Reporter Reporter

Reporter 0’s Reporter 1’s Reporter 0’s

CleanApp Whitepaper (2018) p. 24 of 30 (cc) www.cleanapp.io

flood debris, or hurricane/typhoon/tornado dispersal), buried (by leaves, snow, other debris, etc.), or abandoned. Verification of Report “pendency” and assessment of “Report linkage accuracy” represent some of the most complex processual frontiers of CleanApp, but event these complex logic problems have elegant solutions that continue to be improved. For example, the “orphaned Report” issue can be easily reframed through periodization: the object may be under snow cover, or may have moved, or perhaps the Report area has been rendered inaccessible by road closure or some other occurrence. Additionally/alternatively, the admittedly complex linkage/aggregation steps become significantly easier with overall industry improvements in geotagging, image overlay, image recognition, and machine learning.

To those not familiar with blockchain tech, these transactional frameworks may seem extremely convoluted and unnecessarily complex. The purpose of this exercise, however, is to illustrate a viable proof-of-concept trash/hazard reporting system that is based on real-world dynamic data structures. Analogizing an Aggregate CleanApp Report structure to a typical cryptocurrency or smart contract shows that the system can work, and can work very efficiently. It also demonstrates that even anticipating full-load global CleanApp reporting, the processing loads and memory loads for very large global data sets can be managed in very economical and cost-effective ways. 6.4 CleanApp Reporter-Responder Transactions We already know that CleanApp Reports can come in many different varieties, that each variety is valuable in its own way, and that submission of Reports can be incentivized via different mechanisms. Decentralized CleanApp is not a one-size-fits-all system. Quite the opposite, CleanApp is conceived in such a way as to maximize the incentives for users to generate high-quality CleanApp Reports across different devices, platforms and networks. Because baseline CleanApp data standards are so easy to meet with imagery and/or location metadata from any smartphone or “smart” wearable device, we anticipate CleanApp Reports sourced from users wearing current and future-gen GoogleGlass devices, iOS phones and watches, drone-mounted GoPro cameras, various AR headsets (Upskill Skylight, for instance), and so on. A plurality of reporting mediums and technologies will result in Reports of varying quality. This is to be expected, and baseline post-processing (to correct orientation, remove filters, foreground Reported object, etc.) will significantly improve overall dataset quality. After initial processing steps, processed Reports can thus be imagined as falling along a spectrum, from low-value low-resolution one-off reports to extremely-high-value Aggregate CleanApp Reports that are sourced from multiple highly-ranked Reporters and present high-quality data regarding the object(s)/condition(s) being reported. Many different types of potential Responders want access to CleanApp Reports, many will pay for access to CleanApp Reports, and these Responders will have different incentives to actually respond to CleanApp Reports. These include, inter alia:

Likely Responders Reason(s) for Responding

Property Owners • want to know about illegal dumping on their property, or other trash/hazard conditions.

Store Operators • want to know about potential sources of premise-based liability, so that hazards can be contained/mitigated;

RoboVac Makers • give customers continuously increasing levels of CleanApp functionality & customers will remain loyal to brand through multiple future product cycles;

CleanApp Whitepaper (2018) p. 25 of 30 (cc) www.cleanapp.io

Municipalities • may be charter-bound to respond to citizen-complaints & CleanApp makes fulfilling uptake/response functions much easier than current tech;

BigTech • can charge large commercial property owners (hospitality, infrastructure operators, campuses, etc.) on subscription basis to provide on-demand cleaning services (e.g., AmazonClean);

• responding to hazard may be a small price to pay for acquiring live data feeds that can be used to teach AI regarding Reporting/Responding functions described above (in other words, a robust manned responder operation as a temporary transition stage on the path towards fully-autonomous CleanApp reporting/responding);

BigIndustry/BigWaste • operational CleanApp responder pathways give additional sources of revenue;

• increase landfill diversion by leveraging CleanApp image recognition/AI/ML processes to drastically improve sorting/recycling outcomes;

Scrappers • the scrap metal/materials market is a huge market globally; • armed with route-optimized real-time response maps, scrappers would be

able to economically bid for, select, and execute response functions (think Rubicon Global, except operating on even smaller scales)

ServiceMaster(s) • there are entire commercial segments dedicated to large-scale cleanup operations (e.g., ServiceMaster) – these firms would acquire an additional source of revenue by offering CleanApp Responder services;

Uber(s) • fleet operators could add additional sources of revenue by using slack capacity to pick up trash along given routes;

• allowing passengers to “share” a ride with removable waste seems possible; • dedicated & decentralized trash removal services can offer very large

potential revenue upsides; • with autonomous pickup & disposal/recycle, can take over the role of waste

operators in certain markets; Drone Operators • operators of drone fleets (e.g., Google/Amazon) can charge premium rates

for non-invasive surgically-precise autonomous trash removal services. Landscapers • landscape firms already do a large bit of general grounds maintenance, and

offering on-demand trash removal offers additional sources of highly-scalable revenue;

Campuses • Grounds personnel at large corporate campuses, medical complexes, universities, labs, military bases, and so on, are typically short-staffed;

• moving to an on-demand response paradigm can bring significant cost savings, higher productivity (than merely following predetermined routes), and better overall results;

[…] • […] Over five years of market research (2013-2018), we observe much better outcomes when CleanApp Reporters obtain assurances or evidence that their CleanApp Reports are making an impact. This could mean something as simple as a social media response by a business that signals “recognition of receipt.” In other contexts, this includes photographic proof of remediation.

Whatever the scope of responsive action in the past, by 2018, we observe rapid diversification, fragmentation and innovation in CivicTech response processes, including a clear push towards full automation of trash operations.

There are four key takeaways from this observation: (1) a decentralized report-input process can operate seamlessly with multiple decentralized response processes; (2) decentralization is more likely to result in competition for access to valuable Reports, leading to (3) greater innovation in

CleanApp Whitepaper (2018) p. 26 of 30 (cc) www.cleanapp.io

CleanApp Responder technologies and processes; (4) automation has great potential but it heightens the need for rigorous compliance with harmonized data standards & data protection practices. Whatever specific transactional form CleanApp activity takes in particular markets at particular times, it is clear that dynamically pairing CleanApp Reporters with CleanApp Responders is the logical culmination of CleanApp tech. A CleanApp Reporter-Responder transaction must be done right to satisfy the expectations of both sets of parties. We identify the following factors that Reporters & Responders bring to a likely transaction between them:

Reporters Responders Anonymous/Non-

Attributable Reporting • Anon/Non-Attributable Reports OK so long as they are high-

quality, independently verifiable reports; Confirmation of Cleanup • Flexibility to provide cleanup confirmation/verification where

feasible; no confirmation/verification where not feasible; Utmost In-Home/Enterprise

Privacy • Must provide highest-level data-privacy protections for in-

home/private reporting, including for HomeMapping or IndoorMapping data;

• Must provide “cold storage” / “Intranet-only” CleanApp functionality for users who will not share HomeMapping and/or IndoorMapping data in any form online, but still would like to avail themselves of the convenience/utility of CleanAppBots or other CleanApp Responder processes/utilities;

“Open-Source” Access to CleanApp Report databases

(e.g., OpenLitterMap) / “Closed-Source” Databases / various “hybrid” databases

• Some Responders will want to work solely with open source data for various ideological, institutional, liability reasons;

• Conversely, other Responders will insist solely on closed-source data generation/optimization/ownership.

• Key transactional point is that there is a broad range of likely transactional outcomes, so to obtain the fastest and broadest participation by as many potential transactional actors, it is crucial to give users a range of choices over data ownership/licensing—from exclusively open source regimes, to various hybrid and Creative Commons license regimes, to exclusively closed-source regimes. Choice facilitates the maximum number of transactions.

• If a government or retail establishment wants to have “de facto” or de jure ownership of all incident reports on its property, and if users are sufficiently incentivized to generate these types of “closed-source” Reports, then everyone benefits from the “exclusively closed-source” transaction because there is a higher chance of mitigation of the underlying incident/hazard/object. Even if more analytics gains would flow from a purely open-source process, the goal of attracting the highest number of active Reporters/Responders militates in favor of a user-specified data-privacy regime at the Reporter and Responder, and transactional levels.

Ease of Use / No Friction Same Customization Same

P2P Connectivity Same System-wide visualization Same

No liability / indemnification Same Interoperability Same

Incentivization for HQ Reporting

Same

[…] […]

CleanApp Whitepaper (2018) p. 27 of 30 (cc) www.cleanapp.io

7. CleanApp Standard Basics What we learn from the analysis above is that CleanApp standards must be harmonized, and yet flexible enough to accommodate a broad range of possible current (and anticipated) transactions. This allows us to address several aspects of the CleanApp Standard (with proposed CleanApp Standard documentation forthcoming).

7.1 CleanApp Universal Time

First, we propose use of a timestamp server that uses a harmonized universal time as a shared, standard-wide, reference point. Users’ individual time zones, timestamps will naturally vary, but to obtain maximum utility as a data point, timestamps on CleanApp Reports must be accurate by reference to a single time standard (similar to the need for a standardized conception of universal time in the GPS context). A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash online. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.

This structure accommodates One-Off, Composite, and Aggregate Reports. Moreover, a smart contract platform like Ethereum, and especially various anticipated Ethereum 2.0 embodiments, permit the implementation of custom/individualized blockchain processes for specific types of hazards and/or objects in particular territorial bounds. To give CleanApp Responders the best and most accurate Report data, we emphasize the need for a shared universal time across CleanApp nodes. Local time divergence can be reconciled at various response stages, but CleanApp’s ability to build sequential chaining requires clear and absolute first-in-time protocols. These, in turn, are premised on the adoption of an objectively verifiable universal time.

7.2 CleanApp Geolocation For basic planar Reporting needs of large objects/conditions (discarded furniture at a park, static road hazard like tires or burned-out automobile on the side of the road) existing GPS/GLONAS technology is sufficient to direct human and/or autonomous CleanApp Responders. However, for smaller objects/conditions, more precise geolocation standards will be crucial. Autonomous responder technologies (such as scrubbers, high pressure water washers, RoboVacs, autonomous window cleaners) have advanced to the point where they can operate effectively on vertical surfaces, and upside down. This means that our existing Lat/Long/Elev/time geolocation standards will need to include directional/orientation variables (“Vesta, CleanApp this hornet nest from the roof eave please.”)

Block ...

Block ...

Trash Hash

Trash Hash

Trash Item A Time X

Trash Item A

Time X+1

Trash Item B Time Y

Trash Item B

Time Y+1

CleanApp Whitepaper (2018) p. 28 of 30 (cc) www.cleanapp.io

CleanApp is one of many developers confronting the limitations of existing GPS technologies and eagerly anticipating next-gen geolocation standards and technologies. Our standard geolocatioin proposal is to use industry-leading geolocation technologies embedded in our current and forthcoming mobile devices, with several caveats: (1) users may have the need (and hence, should have the ability) to generate a CleanApp report that is radius-bound versus exactly geolocated (e.g., reporting workplace hazards/conditions/litter where precise geolocation may allow the organization to identify the Reporter, leading to possible reprisals); (2) users should have complete control over the extent of geolocation in HomeMapping contexts (“Siri, CleanApp the blood on the floor of the bathroom, please.”). As intuitive as they may seem, these two simple caveats expose a core tension in BigTech’s current geolocation paradigm: location services as either an “On” or “Off” switch, with the most granulated level of control being granted to users is app-by-app location permissions. Globally-scaled streaming CleanApp processes require far more granulated and far more fluid conception of geolocation and shared geofencing rights: employers and property owners may have legitimate interests in assuring that precisely geotagged hazard/object imagery does not freely leak without proper authorization/control; individuals may not want anybody performing CleanApp activity on what they considers to be their property; organizations may want to invite users to submit CleanApp reports within their locations (e.g., CleanApp@Retail) but may want to “transactionally”

CleanApp Whitepaper (2018) p. 29 of 30 (cc) www.cleanapp.io

limit the extent to which the information flows out of that location (e.g., a store may be willing to buy “exclusive” access to a user’s CleanApp reports through rebates, discounts, outright purchase, goods, promotions, etc.)

7.3 CleanApp Standard Ground Rules For functional CleanApp interoperability, we also propose a set of basic universal ground rules for objects/conditions that present particular legal/ethical/social/technological difficulties for ML-based cleanup operations, and, consequently, should not be CleanApp-ed at present. This normative constrains translates into a set of conditions that render a particular user-generated CleanApp Report as falling outside of standardized CleanApp reporting-response processes. We are finalizing peer review of our Standards/Protocol/Norm documentation, and will publish our draft documentation by the end of 2018. 8. Conclusion We have proposed a system for electronic waste/hazard/incident reporting and response transactions without relying on trust in a centralized authority. We believe this is an ideal use case through which to introduce global populations to DLT/Blockchain. The obvious economic utility and anticipated transactional ease provide a clear case for adoption. Furthermore, a use case that introduces multiple non-financial, and many non-rational, incentive structures for reporting/responding behavior serves as an ideal test platform for further studying the application of DLT to complex real-world behavioral patterns. CleanApp is also an ideal application for stress-testing our current regulatory approach to DLT.

The reasons above are why we contend that CleanApp is the crypto “killer app” through which the world should get to know the unprecedented utility of different DLT platforms and applications.

To close, we offer several bonus incentives for developing CleanApp, and a request: (1) At global scales, CleanApp has the potential of solving one of the humanity’s oldest and most

intractable problems: waste and micro-hazards. CleanApp has a real potential of showing that DLT can be leveraged to actually save the world like no previous or existing technology can.

(2) At global scales (billions of users = billions of daily CleanApp reports/responses), CleanApp also emerges as the world’s largest lost & found database.

Our request is this: We are a short-staffed nonprofit with a miniscule budget (the ETH address below is our budget). Our job is to research and aggregate existing processes for reporting trash & hazards, to research multiple methods for data optimization, data security, and data analytics, and to continuously push the limits of TrashTech, CleanTech & CivicTech. If you would like to support our core development objectives, please contact us at www.cleanapp.io and please consider supporting our development work.

CleanApp Whitepaper (2018) p. 30 of 30 (cc) www.cleanapp.io

Appendix A: Partial List of Existing CleanApps (alphabetical order)

American Rivers www.americanrivers.org SeeClickFix, Inc. SeeClickFix.com Litterati, LLC Litterati.org National Oceanic and Atmospheric Administration www.noaa.gov OpenLitterMap Foundation OpenLitterMap.com Marine Debris Tracker marinedebris.engr.uga.edu Marine LitterWatch eea.europa.eu Ocean Conservancy oceanconservancy.org Pirika, Inc. en.corp.pirika.org SwachhBharatApp http://swachhbharatapp.com/ TrashOut trashout.ngo WeDU! Decoro Urbano GooglePlay World Cleanup Day letsdoitworld.org