# Proposal: zkProver Engine

## Project Background
We propose to create a framework for programmable objects in Web3 that stand for real-life things and contain fields that launch custom logic. This makes an object a smart contract or empowers it to call a smart contract deployed off-chain. This unlocks many real-life use cases, mainly associated with asset ownership and management: **real-world assets (RWAs)**, certification, gaming objects, and more. Essentially, we’re developing an ERP for digital assets in Web3.
We effectively integrate zero-knowledge proof into digital asset management by creating a **zkProver Engine** - infrastructure to generate zk-proofs for operations with digital assets. The zkProver Engine is intended to bring ownership and management of digital assets into their owners’ hands. Now, a digital creator will easily prove the authenticity of their blog post, companies can manage their stocks through blockchains, and insurance companies will prove an insurance event.

## Proposal Overview
### Problem
The vision for a new internet powered by programmable cryptography promises efficiency, privacy, and cost savings through local code execution and various proofs. However, it requires a decentralized, censorship-resistant protocol like the Mina Protocol, which offers a secure, scalable, and intuitive platform for building and accessing these proofs. This article gives more details on the subject matter.

Some blockchains have a built-in object model that allows asset ownership and management functions to be implemented. Take, for instance, dynamic fields on Sui that behave as autonomous programmable entities. However, Mina is an account-centric blockchain and doesn’t support an object model. As a result, Mina doesn’t have programmable objects. Besides, there are currently only eight Fields on a zkApp account, which impedes enhancing programmability on Mina.

### Use Cases
Below are several corner cases for our zkProver Engine.

**Use Case 1 - Gaming**
There’s a game with gaming items. These items can be created and mutated due to a set of rules. For example, a user goes to the blacksmith with their gaming sword and a magic stone. A blacksmith mints a new magical sword with the stone. The sword is a programmable object with a link to the frame in one of its properties. Once the necessary condition is met (the user has a magic stone), and the user initiates the object mutation, the script launches, and the programmable object gets mutated. This use case applies to a metaverse.

**Use Case 2 - Car Insurance**
Programmable provable objects are good with RWAs. Once an insurance event occurs, the insured person applies for indemnity to the insurer. The insurer needs proof that the insurance event is valid (the car was damaged in a road accident). The object representing the car has a property with a code link that defines the rules by which this object can be mutated. An expert proves the event’s validity, and a zk-proof is issued; then, the object is mutated, showing that an insurance event occurred with the car.

**Use Case 3 - Supply Chain Management**
The Procurement Department in a production company has completed the procurement list. For each position on the list, a programmable provable object is minted. Once a position is procured, the object’s property responsible for that is changed, mutating the object.

**Use Case 4 - Asset Management**
A company has many assets (buildings, machinery, vehicles, other infrastructure) with their estimated value reflected in the corresponding account of the ledger. For each such asset, a programmable, provable object is minted with properties that describe this asset. Once the value of an asset changes (due to market price fluctuations or as a result of wear and tear or a force majeure), the corresponding property of the object changes, mutating the object.

**Use Case 5 - RWA Securities**
Real-life securities: bonds, treasures, shares - may need authentication and verification of their status change. Once a bond is issued, a programmable provable object is minted with a set of properties, among which is latest_sell_timestamp. This field changes once a bond is sold and the object is mutated, representing the bond status change.

**Use Case 6- Verify Stamps**
This use case is akin to what notaries usually do - verify documents, signatures, and stamps. Once a stamp is placed on the document, a programmable, provable object is minted with a set of properties. One such property represents that the stamp is valid.

**Use Case 7 - Music and Entertainment**
Sometimes, performers write a cover version of an existing piece of music or several versions of one track. A programmable, provable object is minted for each track to differentiate between the original track and a version/cover of this track. Once a performed decides to write a new version of an existing track, the code embedded in the programmable object is triggered, and one of the properties of the object is mutated, thus creating a new object to represent the latest version of the track, while the original version is represented by the previous object.

**Use Case 8 - Luxury Goods**
Luxury goods like antiquity objects, yachts, and luxury or retro cars need proof of authenticity. Sometimes, they need to be restored, which should be proof of that since it affects the selling price. When a luxury good is registered, a programmable, provable object is minted to represent it. It has a property for the object’s version, which means the number of times the good has been restored, and a property for the latest restoration date. When the luxury good is restored, the programmable object is mutated by changing the said properties.

**Use Case 9 - Identity and Certification**
There’s an outsourcing software company. Each employee is outsourced to an external project. For each employee, a programmable, provable object is minted with properties representing their level, profile, skills, stack, language proficiency, etc. Once an employee gets through assessment and is upgraded (from Junior to Senior level), the property “level “changes its value, and the object is mutated.

**Use Case 10 - Publishing, Media, and Blogging**
There’s a media marketplace where authors write and sell their articles. Once an article is created, a programmable, provable object is minted to represent it. This NFT has properties representing the article’s metadata. An author decides to edit their article. Once the necessary corrections and changes are made, the properties that stand for the version and the latest version timestamp change, thus mutating the object.

**Use Case 11 - Fundraising and Crowdfunding**
There’s a crowdfunding platform. Once a project is listed, a programmable, provable object is minted to represent it. One of the properties represents the project status. Once the status changes from “Being Funded “to “Funded “, the object is mutated.

**Use Case 12 - Supply Chain (Procurement)**
The Procurement Department in a production company has completed the procurement list. For each position on the list, a programmable provable object is minted. Once a position is procured, the object’s property responsible for that is changed, mutating the object.

**Use Case 13 - Asset Management**
A company has many assets (buildings, machinery, vehicles, other infrastructure) with their estimated value reflected in the corresponding account of the ledger. For each such asset, a programmable, provable object is minted with properties that describe this asset. Once the value of an asset changes (due to market price fluctuations or as a result of wear and tear or a force majeure), the corresponding property of the object changes, mutating the object.

**Use Case 14 - Governance**
Governance and voting are among the most prominent and common programmable object use cases. As a voter registers, a programmable provable object is minted with a set of properties, one of which represents the vote status. This parameter changes when the voter casts a vote, and the object is mutated.

### Impact
The internet’s development was driven by the need for secure communication, leading to advancements like HTTPS. Programmable cryptography, such as **zero-knowledge proofs (ZKPs)**, enhances various applications’ security, privacy, and integrity. At O(1) Labs, the focus is on building ZKPs to address issues like data ownership and digital manipulation, restoring trust, and safeguarding user privacy.
Mina pioneers recursive ZK proofs in production developed the Snarky programming language, and has maintained a stable manner with no unplanned outages since launch ([Our Focus, Our Future: o1Labs and the Journey to a Decentralized Internet with Mina](https://www.o1labs.org/blog/our-focus-our-future)). Recently, a new upgrade to enhance the protocol’s programmability was released.

In light of the above, our zkProver Engine will significantly contribute to the mass adoption of the technology endorsed by Mina by unveiling a vast array of practical use cases, thus empowering the Mina community to build a better Internet. That will be the first endeavor to bring the zk-proof technology that Mina endorses to mass use, which can unlock a vast market of real economics for Web3.

### Solution
We offer zkProver Engine - a framework for creating and updating business objects representing real-life entities and an infrastructure for proving transactions with such objects. A user runs transactions with such business objects, the zkProver Engine produces proof for creating or updating the business objects, and the user verifies such proof.

#### Business Objects
A business object is the cornerstone notion in zkProver Engine. It represents real-world objects: bonds, cars, machinery, gaming objects, property, etc. A business object has fields with properties. One or several such fields contain a link to the frame in which custom logic is deployed. When a manager on the side of an Internal/External Party runs a transaction, a business object is created or updated according to the rules defined by an off-chain smart contract called in the transaction.

Business objects are created according to templates. A template should contain the following:
1. **Object fields** - a set of fields with data type descriptions.
2. **Code link** - one of the fields will contain a link to the frame where the custom logic is performed, as a result of which one of the fields will be updated.
3. **Proof Calculation Rules** - the rules according to which a zk-proof is calculated provided by the zkProgram.
4. **Proof Sample** - a JSON object provided by the zkProgram that’s a template for a zk-proof.

#### ZkProver Engine
ZkProver Engine bridges the Customer Service ERP on the side of Internal and External Parties that need to interact with their real-world assets through business objects and the Verification App on the End User’s end that verifies proofs about transactions with such business objects.

An Internal/External Party manages its assets in the ERP System. Business objects are created and updated as needed in the Customer Service App. zkCloudWorker runs a transaction and generates a zk-proof. The Verifier Service then verifies this proof for an End User. The End User can use their own Verifier Service or the Verification Service provided in the Customer Service App.

### Case Study
Let’s see a real-life example of how this should work in practice. Let’s imagine there’s an insurance company (External Party) that insures cars. A company manager uses the Customer Service App to create a “Car n “business object using the “Cars “business object template.
This business object will include the following fields:
- model,
- production year,
- VIN,
- license number,
- insurance policy ID,
- owner’s first and last name,
- last insurance event date,
- object version,
- link field.
The Object Version field is a counter showing how often the business object has changed its status. The Link field contains a link to the frame where the smart contract is called to execute the business logic.

One of the company’s clients got their car hit in a road accident and is now applying for indemnity for the suffered loss.
1. The client provides all the required documents, and proof that it was an insurance event, and the company agrees to indemnify.
2. The company manager sends the public input (information to be disclosed) and the private input (information NOT to be disclosed) to the Customer Service App.
3. The Customer Service App uses private and public input to execute the logic; as a result, the business object representing the client’s car is updated, which means that the object version field is incremented by +1. The last insurance event date is recorded/updated.
4. The zkCloudWorker generates a zk-proof and sends a transaction on-chain.
5. A government authority (Police) must verify that the insurance event was lawful and due.
6. An officer (End User) makes a verification request through the Verifier Service, which verifies the proof received from the zkCloudWorker and stores it in the database.

### Architecture
The ZkProver Engine architecture embraces five environments: Customer Environment, zkCloudWorker, Marketplace Environment, Blockchain Environment, and End User Environment. This is what the architecture of zkProver Engine will look like.

#### Customer Environment

The Customer Environment is intended to serve customers’ needs. Customers are companies and individuals that own business objects and provide public and private input for transactions to run with such objects. The customer Environment is where business object templates are created and updated, proof calculation rules are defined, and proofs are validated.

The Customer Service App is at the core of the Customer Environment. It has an application for creating business objects for Internal/External parties and an application for proof verification for end users.

The use case diagram below shows the role model in the Customer Environment.

#### zkCloudWorker

**zkCloudWorker** is an infrastructure that runs transactions with business objects and produces zk-proofs. In other words, it’s an AWS for zk-proofs. This infrastructure includes Tx Builder, Validator set, Tx Compiler, Tx Prover, Tx Sender, Tx Monitor, and Tx Indexer. The use case diagram shows what each of these components does in zkCloudWorker.

#### Marketplace Environment

We have two ideas about **marketplaces**: for zk-proofs and business objects. On the zk-proof marketplace, proofs will be listed, bought, and sold, while the business object marketplace will list business objects and templates. This means it will enable buying real-world assets on-chain, just operating business objects representing asset ownership. View the use case diagram to see what can be done in the Marketplace Environment.

#### End User Environment

**End users** perform proof verification in the system. An end user may opt-in to request proof verification with the Customer Service App or verify proof in its own End User Environment using its own verification application or smart contract (see the use case diagram below).

#### Blockchain Environment

We will use Mina as an L1 blockchain to run transactions and store transaction data. We will have a zkApp account through which the transactions will run. The MinaNFT V3 RWA contracts and metadata standards will be used, including ZkPrograms mutating the metadata and supporting ZkPrograms Plugins.

#### Modules
The table below shows the modules contained in the ZkProver Engine.

<table width=100%>
<tr>
<th>Module</th>
<th>Functions</th>
<th>Status</th>
</tr>
<tr>
<td rowspan="5">Business Object Designer Platform</td>
<td>Create Business Object Templates</td>
<td rowspan="5">MVP</td>
</tr>
<tr>
<td>Create Template Queries,</td>
</tr>
<tr>
<td>Create Business Objects,</td>
</tr>
<tr>
<td>Set Proof Rules,</td>
</tr
<tr>
<td>Update Business Objects.</td>
</tr>
<tr>
<td rowspan="7">zkCloudWorker</td>
<td>Sequence, order, and batch transactions,</td>
<td rowspan="7">MVP</td>
</tr>
<tr>
<td>Validate transactions,</td>
</tr>
<tr>
<td>Produce proofs,</td>
</tr>
<tr>
<td>Compile transactions,</td>
</tr>
<tr>
<td>Send transactions on-chain,</td>
</tr>
<tr>
<td>Monitor transaction execution,</td>
</tr>
<tr>
<td>Index transactions for databases.</td>
</tr>
<tr>
<td rowspan="1">End User Verification App</td>
<td>Verify proofs</td>
<td rowspan="1">MVP</td>
</tr>
<tr>
<td rowspan="1">Router Service</td>
<td>Register transactions with business objects</td>
<td rowspan="1">MVP</td>
</tr>
<tr>
<td rowspan="1">Blockberry Platform</td>
<td>API services</td>
<td rowspan="1">MVP</td>
</tr>
<tr>
<td rowspan="1">Plugin Connector Platform</td>
<td>Integrate plugins (external services)</td>
<td rowspan="1">Future Stage</td>
</tr>
<tr>
<td rowspan="1">Decentralized Proving Protocol</td>
<td>Generate zk-proofs</td>
<td rowspan="1">Future Stage</td>
</tr>
<tr>
<td rowspan="1">ERP Integrator</td>
<td>Integrate ERP of Internal/External Parties</td>
<td rowspan="1">Future Stage</td>
</tr>
<tr>
<td rowspan="3">Proof Marketplace</td>
<td>List proofs,</td>
<td rowspan="3">Future Stage</td>
</tr>
<tr>
<td>Sell proofs,</td>
</tr>
<tr>
<td>Buy proofs</td>
</tr>
<tr>
<td rowspan="3">Business Object Marketplace</td>
<td>List business objects and templates,</td>
<td rowspan="3">Future Stage</td>
</tr>
<tr>
<td>Sell business objects and templates,</td>
</tr>
<tr>
<td>Buy business objects and templates.</td>
</tr>
<tr>
<td rowspan="1">DA Layers</td>
<td>Decentralized Data Storage</td>
<td rowspan="1">Future Stage</td>
</tr>
</table>

#### Platform Modules
The modules described below are the MVP of the zkProver Engine and will be implemented in the product’s first version.

**Business Object Designer Platform**

The Business Object Designer Platform is part of the Customer Service App and functions to build business objects and design business object templates.

A Manager of an Internal/External Party uses the Platform to create and update business objects via template queries. Designers use the Object Builder to create business object templates and template queries. Business object proofs are produced according to rules (business logic). ZkProgrammers in the zkProgram define each set of rules. Business objects created by Managers are stored in the Private Database.

This is the business object creation flow:

1. A Designer creates a business object template in the Object Builder. The business object template is saved in the Private Database.
2. The Designer creates a query template for the objects in the Object Builder. The query template is saved in the Private Database.
3. A zkProgrammer designs the business rules in the zkProgram.
4. An Object Creator/Editor (Manager on the External/Internal Party’s side) creates a business object using the previously created template.
5. zkCloudWorker runs a transaction and creates proof.
5.1. The transaction is recorded on-chain, and the business object state is saved in the Blockberry database.
5.2. The Router on the Marketplace registers the transaction hash and status in the Router Database.

At any time, a business object template can be updated when the business logic has to be changed, which follows this flow:

1. Business logic changes. The zkProgrammer updates the rules in the zkProgram.
2. An Object Creator/Editor (Manager on the External/Internal Party’s side) updates
3. The zkCloudWorker runs a transaction and creates proof.
3.1. The transaction is recorded on-chain, and the business object state is saved in the Blockberry database.
3.2. The Router on the Marketplace registers the transaction hash and status in the Router Database.

The diagram below shows the object design and registration flow.

#### zkCloudWorker

zkCloudWorker is an environment for generating zk-proofs for operations with business objects that run off-chain according to the rules. On the one hand, it is a prover machine that produces proof. On the other hand, it is a middleman between the customer environment and the Mina blockchain running on-chain transactions.

The table below shows zkCloudWorker components and their functions.

<table width=100%>
<tr>
<th>Role</th>
<th>Functions</th>
</tr>
<tr>
<td rowspan="1">Tx Builder</td>
<td>Sequence, order, and batch transactions.</td>
</tr>
<tr>
<td rowspan="1">Validators</td>
<td>Validate transactions.</td>
</tr>
<tr>
<td rowspan="1">Tx Prover</td>
<td>Produce proofs.</td>
</tr>
<tr>
<td rowspan="1">Tx Compiler</td>
<td>Compile transactions and generate prover keys.</td>
</tr>
<tr>
<td rowspan="1">Tx Sender</td>
<td>Send transactions on-chain.</td>
</tr>
<tr>
<td rowspan="1">Tx Monitor</td>
<td>Monitor transaction execution.</td>
</tr>
<tr>
<td rowspan="1">Tx Indexer</td>
<td>Index transactions for databases.</td>
</tr>
</table>

Let’s see how zkCloudWorker operates in a real-life use case.
1. A Customer Manager on the Internal/External Party’s side needs to update a business object. Then, the flow and interaction between zkCloudWorker components and other environments will look as follows:
2. The Customer Manager checks the business object data by querying in the Private Database.
3. The Customer Manager checks the object’s current state by querying the blockchain node.
4. The Customer Manager sends private and public input to the zkProgram using the Customer Service API.
5. The zkProgram generates proof and sends the public input with the proof to the Tx Builder component of the zkCloudWorker through the Service API.
6. The Tx Builder generates and orders a transaction and puts it in a queue for execution. Then, it batches the transaction into a data block and sends it to the Tx Compiler and Tx Prover.
7. The Tx Compiler generates prover keys and sends them to the Tx Prover.
8. The Tx Prover proves the transaction to the Tx Sender.
9. The Tx Sender sends the transaction to the blockchain, and the transaction hash is sent to the Tx Monitor. The transaction is validated on the L1 and enters the L1 blockchain.
10. The Tx Monitor queries the transaction status in the External Monitor API.
11. The Tx Monitor sends the updated object state to the Indexer Database through the zkProver API, the Private Database, and the object status to the Router Database.
12. The Customer Manager gets the transaction status from the Router Database.

The diagram below illustrates this flow:


#### End User Verification App

An End User can verify proof using either their Verifier Service or the Verification Service in our Customer Service App.

Let’s consider a case when an End User chooses to verify proof using their Verification Service. The flow will look like this:

1. The End User selects the use case in the application.
2. The Verifier Service requests config from the Query Template and receives it from the Verification Service.
3. The End User gets a response and makes a config-based verification request with the parameters and selected use case.
4. The Verifier Service sends the filled form to the Verification Service.
5. The Verification Service generates proof.
6. The End User checks the public and the private input and verifies the proof by signing it. Then, it sends all this to the Verifier Service.
7. The Verifier Service sends the verification of the proof commitment to the blockchain and gets a result.
8. The Verifier Service runs the proof validity check by scanning the use case verification parameters.
9. The End User is given the end binary result of the proof verification in the form of a boolean value: true or false. If the value is actual, then the verification was successful. If the value is false, the verification fails.

The diagram below illustrates the verification flow:

#### Router Service

The **Router** is used to aggregate and route data into the Router Database. It performs the following functions:
- handle events for the Marketplace,
- update Marketplace objects,
- handle verification requests and save verified proofs in the Router Database,
- handle requests.

**Blockberry Platform**

Blockberry is an API platform developed and provided by Staketab that allows users to get reliable blockchain data. We plan to integrate this platform with the zkProver Engine. We will launch endpoints for various business objects as we partner with more projects and businesses.

### Future Stage Modules
These modules are included in the future versions of the zkProver Engine and are on our product roadmap.

**Plugin Connector Platform**
There are lots of projects out there that provide valuable services with whom we can partner. We will use then the products of such projects as plugins. We integrate projects that use a Zk Program. One of our key goals is to foster the composability of zkApps, which is currently challenged.
The Plugin Connector Platform will be used to deploy and manage plugins like wallets or zkEmail.

**Decentralized Proving Protocol**
We plan to scale the zkProver Engine into a decentralized proving protocol.

**ERP Integrator**
Companies using our zkProver Engine might have their own ERP to manage real-world assets. We plan to develop an environment for integrating custom ERPs with zkProver Engine.

**Proof Marketplace**
Proof generation can be effectively marketed. With this in mind, we intend to create a proof marketplace where zk-proofs will be sold and ordered.

**Business Object Marketplace**
We can market not only proofs but business objects, too. On our Business Object Marketplace, External and Internal Parties can list the business objects they created when they decide to sell their real-world assets. In such marketplaces, real-world objects can be effectively sold and bought.

**Business Object Template Marketplaces**
It’s possible to market business objects and templates that designers create. It’s more about building business models and processes. Companies can create and sell or buy templates to tailor to their business needs.

**zkProgram Marketplace**
A library of ready-made solutions (samples, templates) with particular objects associated with a specific Customer.

**Plugin Marketplace**
A marketplace for zkProver integrations. Projects will participate in an online auction of integrations. Integration opportunities can also be sold to third parties.

**DA Layers**
We can effectively integrate zkProver Engine with already existing DA layers or build our own DA layer on Mina that can be used both by our product and external projects to store business object data.

### Platform Security
We consider security paramount since we deal with private data that can be sensitive. This is how we ensure data security:

1. Storing and processing private data in all modules in all steps.
1. Possible solutions:
* fully isolated customer and user environments
* zkProgram on the Customer’s end.
1. Cloud platforms with data center certificates.
1. Change Trace for Auditing all the process stages
1. Contract audits with MDA (Mina Developer Alliance)
1. Transaction inclusion into blockchain state audit (reconciliation of Private Database and blockchain state)
1. BOD Platform: authentication and authorization for all users and administrators.
1. Compliance with European Laws (SOC 2, GDPR, ISO 27001)

## Existing Work
1. [zkCloudWorker](https://docs.zkcloudworker.com/) - a fast cloud-proving service designed for zkApps (zero-knowledge applications). It helps developers by providing a cloud-based environment to efficiently run and verify zero-knowledge proofs.
1. [Blockberry API](https://docs.blockberry.one/docs/getting-started) - a data-rich multi-blockchain API platform provided by Stak
1. [MinaNFT Contracts & Proving Service](https://minanft.io/explore) - proof-of-concept NFT minting platform on Mina.

## Budget and Milestones
### Development Period
3 months

### Stage 1
The goal of Stage 1 is to develop a proof of concept of the Customer Service application, which can interact with the zkProver environment and perform proving cycle operations.

**Midpoint Milestones - Stage 1**
1. zk Cloud Proving Service Worker implementation.
1. Blockberry Environment: zkProver API implementation.
1. Blockberry Environment: Object State Database implementation.

**Final Milestones - Stage 1**
1. ZkProver Customer Service App design.
1. POC: Customer Service App Frontend - a web-server application run in a local host environment.
1. POC: Customer Service App Backend - the backend application runs in a local host environment.

### Budget Requested
100,000 Mina.

### Budget Breakdown
1. zk Cloud Proving Service Worker implementation (20,000 Mina).
1. Blockberry Environment: zkProver API implementation. (10,000 Mina).
1. Blockberry Environment: Object State Database implementation. (12,000 Mina).
1. ZkProver Customer Service App design. (10,000 Mina)
1. POC: Customer Service App Frontend - a web-server application run in a local host environment. (28,000 Mina).
1. POC: Customer Service App Backend - the backend application runs in a local host environment. (20,000 Mina).

## Wallet Address
B62qm5HhL5ESWzGMBRdzjVkRGD5ZzAf8YYErcXYyDbSy7o9EXUXMqnk

## Team Info
**Mikhail Korotkikh** - smart contract developer

**Vitali Horba** - project manager

**Ducca** - solution architect, devops

**Dzmitry Sakalou** - analyst

**Ilya Peker** - analyst, designer

**Evgeni Haurushou** - front-end developer

**Vitali Karpuk** - front-end developer

**Artem Brodski** - back-end developer

**Denis Streltsou** - back-end developer

## Proposer GitHub
https://github.com/Staketab

### Proposer Experience
**Minascan Team:**
* Minascan;
* Minascan Custom GraphQL;
* Blockberry API platform;
* Zekoscan;
* Suiscan;
* Staketab - AA-rated Verified Staking Provider.

**Mikhail Korotkikh:**
* MinaNFT project;
* zkCloudWorker;
* Graduated from the Encode Club ZK bootcamp (October 2023);
* Graduated from the Encode Club AI bootcamp (July 2024).

## Risks and Mitigations

1. **Distributed Environment**

Mitigation: Staketab’s experience in building distributed systems infra.

2. **Design Complexity**

Mitigation: Close communication with real-world enterprises to utilize their experience and get valuable feedback.

3. There are **no similar systems on the market**, and potential customers do not understand the features of ZK solutions.

Mitigation: We will prepare presentations explaining the technology and its advantages for non-technical executives.