Hi iExec Team. I have some questions as follows. If some questions are not suitable to reply here/now or you have replied to others already, please feel free to skip them.Thank you!

• Growth (this is the most critical question everybody ask, i guess)
  • 1) Target Markets - It seems at first that iExec were focusing on the dApps market at first, is this still true or iExec have some other target markets that can be explored sooner? If you have wider targets, what is the plan?
  • 2) Awareness & Adoptions - How is iExec's strategic plan and budget to tackle Dev/User/Worker Awareness & Adoptions?
• Platform Efficiency
  • 3) Capacity Utilization - If public workers are operating in V2.X, their working capacities need to be utilized to keep them profitable. How is your strategy to this challenge?
  • 4) Transaction fee - For now iExec plan to use some sidechains for cheaper transaction fee. In future,  have iExec considered to create its own sidechain (and this adds more utility to the RLC tokens if staking is needed to secure iExec sidechain)?
• iExec Platform Security
  • 5) Smart Contract Auditing - How is the smart contract auditing so far? I guess that the audit is for V2.X version (with public workers), right?
  • 6) Contingency Measures - Have you explored the contingency measures in case of something gravely wrong happens from the vulnerability of the smart contract or system design? (e.g., forking to new smart contract?, etc.).
  • 7) Scheduler/Worker Fund Locking Period As A Last Resort Measure (Idea for your consideration ) - If the malicious behaviors are in massive scale (ex: 51% attack), an RLC fund locking period (eg. 1 day, 1 week, 1 month, etc.) before the worker/scheduler can take out from smart contract (to sell or whatever) could be a last-resort countermeasure if iExec team and community need to step in. This way the malicious actors cannot just hit and run to dump the gained RLC immediately but they are stuck for a period while the iExec team & community have more time to take action.