Exhibit 10.5

NRE FUNDING AGREEMENT

This NRE Funding Agreement (the “Agreement”) is made on September 1st, 2020 and effective as of January 1^st, 2020 (“Effective Date”), by and between and Gamma Research and Development LTD., a company incorporated under the laws of the State of Israel, with its principal offices at 94 Yigal Alon St. Tel Aviv (hereinafter: “GAMMA”) and Enigma MPC Inc., registered under the laws of the State of Delaware USA (hereinafter: “Funding Partner”).

WHEREAS GAMMA is engaged in research and development activities to develop and advance the software and technologies described in the development plan attached hereto as Appendix 1 (such Appendix, the “Development Plan” and such research and development activities, the “Project”);

WHEREAS Funding Partner desires that GAMMA invests sufficiently in the Project, and desires to assist GAMMA with the Project by funding GAMMA’s expenses with respect to the Project; and

WHEREAS Funding Partner’s interest in entering this Agreement is to support the creation of the technology infrastructure which would assist in enabling the continuity of Funding Partner’s digital assets and more broadly to add value to the whole blockchain industry.

NOW, THEREFORE, in consideration of the mutual promises and covenants set forth herein and for other good and valuable consideration, the receipt and adequacy of which are hereby acknowledged, and intending to be legally bound, it is therefore agreed as follows:

1. Project Assignment

1.1. Funding Partner agrees to fund GAMMA’s research and development expenses, dedicated capital expenditures, non-recurring engineering costs, and third party costs (collectively, “Project Expenditures”) targeted at developing the Project described in the Development Plan. GAMMA’s good faith estimate, as of the Effective Date, of the total Project Expenditures during the period starting on January 1^st, 2020, and ending on July 31^st, 2022, (the “Funding Period”) is attached hereto as Appendix 2 (such Appendix, the “Project Expenditure Estimate”).

1.2. During the Funding Period, GAMMA will in good faith use its commercially reasonable efforts to execute the Project in a manner that will lead to the achievement of the Development Plan under the most recent Project Expenditure Estimate. Funding Partner acknowledges and agrees that (a) GAMMA shall have sole control of the Project, (b) GAMMA is not committing to or guaranteeing the results of the Project or the suitability of the technologies described in the Development Plan for Funding Partner’s purposes.

1.3. GAMMA may change the Project Expenditure Estimate at any time, in its sole discretion. GAMMA will provide Funding Partner with an updated Project Expenditure Estimate, based on GAMMA’s then-current good faith evaluation of the state of the Project (a) within thirty (30) days prior to the start of each calendar year during the Funding Period and (b) promptly after GAMMA makes a significant change to the then-current Project Expenditure Estimate.

2. Project Funding

2.1. During the Funding Period, Funding Partner will pay to GAMMA a total of NIS 38,650,000 (the “Project Funding”). Unless otherwise agreed in writing by the Parties, GAMMA shall apply the Project Funding to the Project.

2.2. Subject to the payment of the advance payment as provided herein, the parties hereby agree that the Project Funding shall be paid by Funding Partner to GAMMA in equal quarterly payments over the Funding Period (“Quarterly Payment”). Each Quarterly Payment shall be paid at the start of each calendar quarter. The Parties hereby acknowledge that on February 29, 2020, Funding Partner paid Gamma an advance payment on account of the Project Funding in the amount of NIS 9,844,373.65. Notwithstanding this section Gamma may be entitled to request advancement of payment in case of early completion of a development phase.

1

2.3. Funding Partner shall pay each Quarterly Payment to GAMMA on the first day of the applicable calendar quarter. Each Quarterly Payment shall be paid in USD based on the USD/NIS representative exchange rate as published by the Bank of Israel on the date of payment.

2.4. The Quarterly Payments are exclusive of any applicable VAT. To the extent the Quarterly Payment are subject to applicable VAT, then Funding Partner shall add to each Quarterly Payment the applicable VAT amount, as will be invoiced by GAMMA.

2.5. Within thirty (30) days after the end of each calendar year during the Funding Period, GAMMA will provide Funding Partner with high-level report specifying in reasonable detail the actual Project Expenditures during the current calendar year.

2.6. Funding Partner acknowledges and agrees that GAMMA’s actual Project Expenditures for a given calendar year may be less than the last Project Expenditure Estimate issued prior to such calendar year, and that such situation shall not have any consequences, as the total Funding for the Funding Period will remain unchanged. It is agreed by the parties that GAMMA shall have discretion to shift Project Expenditures from one calendar year to another.

If GAMMA, in its reasonable discretion, decides to abandon the Project as a result of technological infeasibility or lack of sufficient industry demand to GAMMA’s technology and cease research and development activities with respect to the technologies described in the Development Plan, then GAMMA and Funding Partner will in good faith seek to agree to apply the remaining Project Funding to a different, mutually agreed GAMMA development project. If the Parties so agree on a replacement project, such replacement project shall be considered the “Project” for all purposes under this Agreement. If the Parties cannot agree on a replacement project, then GAMMA may invoice Funding Partner for additional 2 Quarterly Payments and this Agreement shall terminate.

3. Supply of SCRT Tokens by GAMMA to Funding Partner

3.1. For the purpose of this Section “SCRT Tokens” means the tokens of GAMMA, being the crypto-asset developed, created or minted by GAMMA.

3.2. In consideration of funding the Project Expenditures, the parties hereby acknowledge that GAMMA has transferred to Funding Partner 10,000,000 SCRT Tokens to the token wallet of Funding Partner, details of which have been provided by Funding Partner.

3.3. As additional consideration, during the term that commences on the date of this agreement and ends on December 31st, 2022, Funding Partner shall be entitled to purchase from GAMMA up to 15,000,000 SCRT Tokens for a purchase price which is equal to 80% of the Fair Market Value of the SCRT Tokens on the date of purchase (i.e. 20% discount on Fair Market Value). For purposes of this Section “Fair Market Value” means the closing price of SCRT Tokens as published on the last business day prior to the date of purchase on the website www.coinmarketcap.com.

4. Term and Termination

4.1. The term of this Agreement (the “Term”) shall commence on the Effective Date and continue in full force and effect until the completion of the Development Plan (which is estimated to be on June 30st, 2022) unless earlier terminated in accordance with the terms of this Agreement.

2

4.2. Funding Partner may terminate this Agreement upon ninety (90) days’ prior written notice to GAMMA and by paying to GAMMA an amount equal to two (2) Quarterly Payments. The Parties acknowledge and agree that this Section ‎4.2 sets forth the sole and exclusive right to terminate this Agreement, and that there are no other termination rights, express or implied, under this Agreement.

4.3. In the event of any expiration or termination of this Agreement, each Party shall promptly return to the other Party all Confidential Information and copies thereof belonging to the other Party which are related to the Agreement and are then in the possession, power, or control of such Party or any of its personnel; provided, that such Party shall nevertheless be entitled to retain copies of any of the foregoing (and related documentation) in accordance with its general records retention policy and to satisfy its obligations under applicable law or regulation.

4.4. Expiration or termination of this Agreement for any reason shall not affect any liabilities or obligations of either Party arising before such expiration or termination or out of the events causing such termination, or any damages or other remedies to which a Party may be entitled under this Agreement, at law or in equity, arising from any breaches of such liabilities or obligations.

4.5. Sections 6,7,8,9, and 10 and any other rights or obligations which by their nature and content are expressly or impliedly intended to survive, shall survive and continue following expiration or termination of this Agreement.

5. Audit

5.1. GAMMA shall maintain records in sufficient detail to permit Funding Partner to confirm the actual Project Expenditures for each calendar quarter during the Funding Period. Upon written notice to GAMMA, Funding Partner shall have the right, no more than one (1) time per calendar year and at its own expense, using an independent auditor selected by Funding Partner and reasonably acceptable to GAMMA, to review such records (to the extent generated since the last audit conducted by Funding Partner pursuant to this Section 5.1) during normal business hours, solely to verify the applicable actual Project Expenditures. GAMMA shall reasonably cooperate with such audit, and Funding Partner shall provide GAMMA with a copy of all reports and other findings prepared in connection with such audit.

5.2. If Funding Partner’s exercise of its rights under Section 5.1 results in audit findings that the actual Project Expenditures reported by GAMMA for a given calendar year are less than thirty percent (30%) of the last Project Expenditure Estimate prior to the start of such calendar year, then the Parties will meet to discuss such findings and, if the findings are confirmed by GAMMA, GAMMA will reimburse the extra funding paid by Funding partner above what should have been paid on actual costs and will restate accordingly the Funding due for the remainder of the Funding Period, which will in any event ensure that the total funding committed will be paid.

6. Confidentiality

6.1. During the Term of the Agreement, either Party may have or may be provided access to the other Party’s confidential information and material. For purposes of this Agreement, “Confidential Information” means all non-public and/or proprietary information of one of the Parties (the “Disclosing Party that is disclosed to the other Party (the “Receiving Party”) in the course of the activity pursuant to this Agreement, whether disclosed in oral, written, graphic, machine recognizable (including computer programs or data bases), model or sample form, or any derivation thereof, and includes product specifications, designs, production plans, bills of materials, development schedules, processes, method. Such information shall be Confidential Information if it would ordinarily be treated as confidential by the Disclosing Party or would ordinarily be considered information of a confidential nature in the industry, whether or not specifically marked as such. The Receiving Party shall hold the Disclosing Party’s Confidential Information in strictest confidence, using such measures as the Receiving Party uses to protect the confidentiality of its own Confidential Information of like importance, but in no event using less than reasonable care.

6.2. The Receiving Party shall not make any disclosure of such Confidential Information other than to its employees or agents on a need to know basis. The Receiving Party shall inform each such employee or agent of the Receiving Party’s confidentiality obligations under this Agreement, and shall be jointly and severally liable for any breach of this Agreement by any such employee.

3

6.3. The provisions of this Article 6 shall not apply to any information that is: (a) in or subsequently enters the public domain, other than by fault, act or omission of the Receiving Party, (b) obtained lawfully from a third person who was under no obligation of confidentiality, (c) independently developed by the Receiving Party without reference to any Confidential Material, or (d) required to be disclosed by law or regulation or in response to a valid court order; provided, however, that the Receiving Party shall, if legally permitted, give the Disclosing Party prior notice as soon as possible of such required disclosure so as to enable the Disclosing Party to seek relief from such disclosure requirement or undertake measures to protect the confidentiality of the disclosure

6.4. Any and all written reports prepared by and any information provided by GAMMA in connection herewith shall be maintained in strict confidence and may not be disclosed, in whole or in part, by Funding Partner to any third party without the prior written consent of GAMMA.

6.5. The Receiving Party shall immediately inform the Disclosing Party if it becomes aware of the possession, use, or knowledge of any of the Confidential Information by any person not authorized to possess, use, or have knowledge of the Confidential Information and shall, at the request of the Disclosing Party, provide such reasonable assistance as is required by the Disclosing Party to mitigate any damage caused thereby.

7. Intellectual Property

7.1. GAMMA will own any and all Intellectual Property (whether arising under the laws of the state of Israel, the United States or any other state, country or jurisdiction, now or hereinafter existing) created by GAMMA, and any and all work product developed or created by or on behalf of GAMMA in connection with this Agreement or the Project. For purposes of this Agreement, “Intellectual Property” means, in any jurisdiction throughout the world: (a) inventions (whether patentable or unpatentable, and whether or not reduced to practice), all improvements thereto, and all patents, patent applications, and patent disclosures, together with all provisionals, reissuances, continuations, continuations-in-part divisions, revisions, extensions, and reexaminations thereof; (b) marks; (c) copyrightable works, all copyrights, and all website content, and all applications, registrations, and renewals in connection therewith; (d) mask works and protectable designs, and all applications, registrations, and renewals in connection therewith; (e) trade secrets and confidential business information (including processes, procedures, research and development, know-how, formulas, algorithms, compositions, manufacturing and production processes and techniques, technical data, designs, drawings, specifications, research records, records of inventions, test information, customer and supplier lists, customer data, pricing and cost information, and business and marketing plans and proposals); (f) software, and all electronic data, databases, and data collections; (g) business processes; (h) all other proprietary and intellectual property rights; and (i) copies and tangible embodiments of any of the foregoing (in whatever form or medium).

7.2. Each Party will solely and exclusively own all right, title and interest in and to all Intellectual Property that was owned by or licensed to such Party prior to the Effective Date, or independently of this Agreement.

8. No Representations and Warranties

EACH PARTY HEREBY DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES WITH RESPECT TO THIS AGREEMENT AND THE PROJECT, WHETHER EXPRESS OR IMPLIED (INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND/OR NON-INFRINGEMENT). EACH PARTY ACKNOWLEDGES THAT IT HAS NOT RELIED ON ANY STATEMENTS, REPRESENTATIONS OR WARRANTIES OF THE OTHER PARTY.

4

9. Limitations of Liability

9.1. NEITHER PARTY WILL BE LIABLE TO THE OTHER PARTY OR TO ANY PERSON CLAIMING THROUGH THE OTHER PARTY FOR ANY SPECIAL, PUNITIVE, CONSEQUENTIAL, INCIDENTAL, EXEMPLARY OR OTHER INDIRECT DAMAGES, ARISING OUT OF OR IN ANY MANNER CONNECTED WITH THIS AGREEMENT OR THE SUBJECT MATTER HEREOF, REGARDLESS OF THE FORM OF ACTION AND WHETHER OR NOT SUCH PARTY HAS BEEN ADVISED OF OR OTHERWISE MIGHT HAVE ANTICIPATED THE POSSIBILITY OF SUCH DAMAGES.

9.2. THE LIMITATIONS OF LIABILITY IN THIS SECTION 9 SHALL NOT APPLY TO DAMAGES ARISING FROM, RELATING TO, OR BASED ON (i) THE GROSS NEGLIGENCE, WILLFUL OR INTENTIONAL MISCONDUCT OF A PARTY OR ITS PERSONNEL, (ii) PERSONAL INJURY, DEATH OR DAMAGE TO TANGIBLE PROPERTY CAUSED BY A PARTY OR ITS PERSONNEL, (iii) FRAUDULENT OR CRIMINAL ACTS BY A PARTY OR ITS PERSONNEL OR (iv) EITHER PARTY’S BREACH OF ARTICLE 6 HEREUNDER.

10. General Provisions

10.1. Construction; Absence of Presumption

10.1.1. For the purposes of this Agreement, (a) words (including capitalized terms defined herein) in the singular shall be held to include the plural and vice versa and words (including capitalized terms defined herein) of one gender shall be held to include the other gender as the context requires, (b) the terms “hereof,” “herein” and “herewith” and words of similar import shall, unless otherwise stated, be construed to refer to this Agreement as a whole (including all Appendices) and not to any particular provision of this Agreement, and Article, Section, paragraph, and Appendix references are to the Articles, Sections, paragraphs, and Appendices to this Agreement, unless otherwise provided, (c) the words “including” and “such as” and words of similar import when used in this Agreement shall mean “including, without limitation”, and (d) all references to any period of days shall be deemed to be to the relevant number of calendar days unless otherwise provided.

10.1.2. The Parties hereby acknowledge that each Party and its counsel have reviewed and revised this Agreement in good faith and that no rule of construction to the effect that any ambiguities are to be resolved against the drafting party shall be employed in the interpretation of this Agreement (including all Appendices) or any amendments hereto or thereto.

10.2. Amendments and Waivers. No amendment to or modification of this Agreement will be binding unless in writing and signed by a duly authorized representative of each Party. No waiver of any obligation or condition under this Agreement will be effective unless contained in a written document duly executed by the Party granting such waiver. Any such waiver shall not operate as a waiver of, or estoppel with respect to, any subsequent or other failure of compliance.

10.3. Amendments and Waivers. No amendment to or modification of this Agreement will be binding unless in writing and signed by a duly authorized representative of each Party. No waiver of any obligation or condition under this Agreement will be effective unless contained in a written document duly executed by the Party granting such waiver. Any such waiver shall not operate as a waiver of, or estoppel with respect to, any subsequent or other failure of compliance.

10.4. Severability. If any provision of this Agreement or the application thereof to any person or circumstance is determined by a court of competent jurisdiction to be invalid, void, or unenforceable, the remaining provisions hereof or the application of such provision to persons or circumstances or in jurisdictions other than those as to which it has been held invalid or unenforceable, shall remain in full force and effect and shall in no way be affected, impaired, or invalidated thereby, so long as the economic or legal substance of the transactions contemplated hereby is not affected in any manner adverse to any Party. Upon such determination, the Parties shall negotiate in good faith in an effort to agree upon such a suitable and equitable provision to effect the original intent of the Parties.

10.5. Relationship of the Parties. Nothing contained in this Agreement shall be deemed to constitute a partnership, joint venture, or legal entity of any type between Funding Partner and GAMMA, or to constitute one Party as the agent of the other. Moreover, each Party agrees not to construe this Agreement, or any of the transactions contemplated hereby, as a partnership for any tax purposes. Each Party shall act solely as an independent contractor, and nothing in this Agreement shall be construed to give any Party the power or authority to act for, bind, or commit the other Party.

5

10.6. Cumulative Remedies. No remedy referred to in this Agreement is intended to be exclusive, but each shall be cumulative and without prejudice to any other remedy referred to in this Agreement or otherwise available under law, equity or otherwise.

10.7. Successors and Assigns. This Agreement shall be binding upon and inure to the benefit of the Parties and their respective successors and assigns.

10.8. Assignment. This Agreement may not be assigned, in whole or in part, by either Party without the other Party’s prior written consent; provided, that either Party may assign the Agreement without such consent to an affiliate or a successor to all or substantially all of the assets of the business, whether by sale, merger, operation of law or otherwise. A Party who assigns this Agreement to an Affiliate will remain responsible for and ensure the performance of any and all obligations of the Affiliate under this Agreement.

10.9. Notices. All notices or other communications under this Agreement shall be in writing and shall be deemed to be duly given when (a) delivered in person or (b) deposited in the registered mail or private express mail, postage prepaid, addressed as follows:

If to Funding Partner, to:

[-]

If to GAMMA to:

[-]

Any Party may, by notice to the other Party, change the address to which such notices are to be given.

10.10.  Dispute Resolution. In the event of any dispute under this Agreement, the senior management of each Party will meet to resolve the dispute. If the dispute is not resolved by senior management within thirty (30) days after escalation, either Party may make a written request for formal dispute resolution and specify therein the scope of the dispute. Within thirty (30) days after such written notification, the Parties will meet for one day with an impartial mediator and consider dispute resolution alternatives other than litigation. If an alternative method of dispute resolution is not agreed upon within thirty (30) days after the one day mediation, either Party may pursue any right or remedies available under law, in equity or under this Agreement. Notwithstanding the foregoing, neither Party shall be precluded at any time from seeking injunction relief against the other Party.

10.11.  Force Majeure. No Party shall be deemed in default of this Agreement to the extent that any delay or failure in the performance of its obligations under this Agreement results from any cause beyond its reasonable control and without its fault or negligence, such as acts of God, acts of civil or military authority, embargoes, epidemics, war, riots, insurrections, fires, explosions, earthquakes, floods, unusually severe weather conditions, labor problems or unavailability of parts, or, in the case of computer systems, any failure in electrical or air conditioning equipment. In the event of any such excused delay, the time for performance shall be extended for a period equal to the time lost by reason of the delay.

10.12.  Counterparts. This Agreement may be executed in one or more counterparts, each of which shall be deemed an original, but all of which together shall constitute a single instrument.

10.13.  Headings. Any section headings contained in this Agreement are for reference purposes only and shall not affect in any way the meaning or interpretation of this Agreement.

10.14.  Applicable Law and Forum. This Agreement shall be construed and interpreted in accordance with the laws of the State of Israel, excluding Israel’s conflicts of law provisions. All disputes and litigation arising out of or relating to this Agreement, including without limitation matters connected with its performance, shall be subject to the exclusive jurisdiction of the courts of the State of Israel. The parties hereby irrevocably submit to the personal jurisdiction of such courts and irrevocably waive all objections to such venue.

[Signature page follows]

6

[SIGNATURE PAGE TO NRE FUNDING AGREEMENT]

IN WITNESS WHEREOF, this Agreement has been signed on behalf of the Parties hereto by persons duly authorized in that behalf:

/s/ Guy Zyskind		/s/ Guy Zyskind
Gamma Research and Development LTD.		Enigma MPC Inc.
Name:	Guy Zyskind	Name:	Guy Zyskind
Title:	CEO/CTO	Title:	CEO/President
Date:	September 1, 2020	Date:	September 1, 2020

7

Appendix 1

Development Plan

The below Development Plans are indicative and can be changed in GAMMA’s discretion.

Secret Network v1 (SNv1)
(Due by June 30, 2020)

In version 1.0, a production-ready, fully functional, blockchain network that is resilient against arbitrary byzantine faults would be developed (Secret Network v1 or SNv1). SNv1 would be a fully permissionless network, without any gate-keepers who need to white-list specific trusted nodes. For that reason, a secure sybil-resistant mechanism has to be included, and a native coin (SCRT or “Secret”) needs to be built to help secure the network and serve as the incentivization layer for nodes (also known as validators).

The main features and requirements for SNv1 are listed below

- Tendermint or equivalent PBFT consensus engine that provides strong consistency (i.e., finality within one block)

- Sybil resistance in the form of a proof-of-stake mechanism

- A native coin (SCRT) that is used in conjunction with the proof-of-stake mechanism

- Payments and account support – the ability to send SCRT from one account to another, and storing that information on a distributed ledger. Support for ECDSA standard and multi-sig accounts.

- Staking and delegation support:

- Support up to 50 validators staking concurrently

- Allow any user to delegate their coins to validators of their choice, including re-delegation

- Governance – allow users to initiate new governance proposals on which all coin holders can vote on with their SCRT coins (1 SCRT = 1 vote)

- The network should aim to support at least 99.999% uptime, unless in extreme cases such as network upgrades, unforeseen issues, or breaking of any of the base underlying security assumptions.

8

To support the features above, several components should be developed. These are described in detail below.

Secret Daemon (node server-side deployable)

The main servlet application deployed by validators and full nodes. Daemon should act as interchangeable agents – i.e., the network does not rely or distinguish between one node or another. Collectively, these daemons comprise the network, facilitate and validate transactions, mint new SCRT coins, and reach consensus over the historical state of the network (its database and/or distributed ledger).

Secret CLI (client)

A command-line interface (CLI) that allows users to interact with the network. Specifically, users should be able to:

1. Create a new wallet or connect at least one secure hardware wallet (e.g., Ledger Hardware Wallet).

2. Send payment transactions.

3. Propose and vote on governance proposals.

4. Query the ledger for historical transactions and account balances.

5. Create a validator and stake.

6. Delegate/re-delegate stake to lower the barrier of entry and increase participation and decentralization

Block explorer (Ledger UI)

A block explorer showing all transactions, blocks, validators and other important metrics should be built.

Testnet (Staging environment)

A testing environment should be built and maintained to test network functionality and ensure it performs according to the specification.

9

Secret Network v2 (SNv2)
(Due by December 31, 2020)

In Secret Network v2 (SNv2), the plan is to develop privacy-preserving smart-contracts functionality, called Secret Contracts, on top of Secret Network. Secret Contracts elevate the network from a payments-only blockchain, to a secure, privacy-preserving decentralized cloud, solving the long-standing problem of achieving privacy in the context of blockchains specifically, and of applications in general. The solution involves the usage of specific secure hardware called Trusted Execution Environments (or TEEs). Specifically for SNv2 – we will develop support for Intel’s Software Guard Extensions or SGX, which are available on all Intel processors since Skylake microprocessor architecture was introduced several years ago. While the current implementation works for SGX, the concepts and technology developed could be extended to other TEEs.

A secret contract is a unit of code that can be executed through nodes in a network who remain oblivious to the data they are computing over (i.e., they are essentially computing over encrypted data). Each Secret Contract (or a collection of these) act as the backend of a single decentralized application, known as a secret app.

Cryptographic protocols

To enable privacy-preserving computations, we will need to research, design and develop the following cryptographic protocols that will be used in conjunction with TEEs.

- One-shot attestation protocol: Before a new node can join the network, their enclave needs to be provisioned with the secrets necessary to encrypt/decrypt ledger information. For that reason, each node must first register its enclave to the network, while proving, using the enclave’s remote attestation mechanism that it is running a genuine TEE. This registration process would also include generating fresh keys to allow for a streamlined remote attestation procedure in the future, that do not require interacting with Intel server’s, in particular – the IAS.

- Secret (seed) sharing protocol: We will design a network-wide secret-sharing protocol that allows the network to agree on shared true randomness. This protocol needs to ensure that the determinism invariant across the network is maintained, that the randomness is uniformly and independently distributed and that no one but the enclaves themselves have access to that randomness.

- Key derivation protocol: With the seeds shared, we will develop a key-derivation protocol that ensures unique keys are deterministically (and yet securely) generated for all aspects of the network: input keys, output keys, state keys, pseudo-randomness, etc.

- Encryption/decryption protocol: Authenticated encryption/decryption protocols should be built and optimized to fit a system with potentially millions of users, thousands of nodes, and large long-lived data-sets. Most importantly, the protocols need to ensure the determinism invariant holds in the network, and that no information can be leaked by a malicious host locally interacting with their enclave. Finally, the protocols should be optimized and be built on software implementations that utilize AES-NI instruction set. There are three family of encryption/decryption protocols that need to be supported:

- Input encryption/decryption – inputs are arguments user share with each computation request. They need to be client-side encrypted and must only be decrypted inside of the enclave.

- Outputs encryption/decryption – outputs are results users should privately receive from a computation. They should be decrypted with keys only the requesting user has.

- State encryption/decryption – state is the internal database of each contract. It is long-lived storage that needs to remain encrypted, sealed and replicated on each node in the network, such that even the untrusted hosts themselves can’t read it.

10

Contract Deployment and Development

For SNv2, we will develop a platform that allows deploying Secret Contracts written in Rust. Secret Contracts can use general-purpose Rust libraries, assuming these fit within the gas limitations and are enclave-friendly.

Writing a contract will be simplified similar to how smart contracts in Ethereum work. Specifically, users will be able to interact with the contract by sending compute transactions that manipulate the state (and therefore cost gas), or queries that only require read-access to a contract’s state. A contract state is its internal database that gets persisted by the network, and which the network reaches consensus on.

Code Execution

With the cryptographic protocols in place and contract development and deployment mechanism, we will develop the architecture necessary to bring Secret Contract functionality to life.

At a high level, the following execution stack needs to be developed:

1. Compute Module: This is the piece that connects the blockchain itself (users sending transactions, network reaching consensus over blocks, eventual reading/writed from the replicated storage, etc..) and the computation layer. It’s the first layer in the stack which takes in a user transaction, unfolds it, and dispatches it to the next layer.

2. Virtual Machine: The main layer which commands a function execution in a given contract. This occurs outside of the enclave and is considered untrusted code.

3. Web Assembly (WASM) Runtime (trusted): This layer takes in the pre-processed computation data, ensures that it can be trusted, and does additional pre and post processing after execution – mainly key generation, derivation, encryption and decryption.

4. WASM Interpreter (WASMI): The final layer which actually executes the WASM bytecode. The interpreter is selected and modified to specifically fit the requirements of a TEE.

11

Upgrading existing components

Secret Daemon, Secret CLI, Block explorer and Testnet would all need to be significantly modified to support all new functionality. This includes, among others:

- Cryptography libraries and protocol support

- Supporting a node registration procedure that includes one-off remote attestation, secret sharing and and key derivation protocols

- Supporting smart contract deployment, execution, and querying, with encryption pre and post processing

- Supporting visuals in the UI and CLI to convey this data

Additional components

To make it easier for developers, a client-side SDK called SecretJS would be developed. SecretJS would mirror the functionality of the CLI, but would make it programmable in Javascript. This would make developing secret web-based applications possible.

Secret Network v3 (SNv3)

(Due by September 30, 2021)

Secret Network v3 (SNv3) would focus on interoperability and creating additional services to complement the Secret Network ecosystem. In addition, features and improvements that benefit the security and scalability of the network will be added.

Bi-directional Ethereum/ERC-20 ←→ SCRT bridge

In order to expand the Secret Network ecosystem (and its privacy benefits) to other chains, a bi-directional bridge would be developed, allowing converting native ETH or ERC-20 tokens into pegged synthetic Secret Tokens (see below) on Secret Network.

12

The bridge will include the following components:

1. A smart contract on Ethereum to deposit/withdraw ETH or ERC-20 tokens (separate contract for each asset).

2. A module on Secret Network to handle incoming requests to mint/burn synthetic Ethereum-based assets.

3. A Secret Token contract issued for each synthetic Ethereum-based asset.

4. A small off-chain small network of operators (e.g., up to 5 operators) that listen to events occurring on both networks, and facilitate the counter-operation on the other chain through a robust t-of-n multi-signature mechanism.

DeFi Services

We will develop a list of bare-bone Decentralized (or Open) Finance building blocks. These can then be used and composed with other services that developers on Secret Network build. The following services will be developed

1. Secret Token Standard: an ERC-20 equivalent token standard that allows the issuance and ability to transfer tokens from one party to another. The uniqueness of Secret Token Standard as opposed to other standards like ERC-20 is rooted in its privacy guarantees. Secret Tokens ensure that all information about senders, receivers, and amounts being transmitted are completely encrypted. Each user can only observe their own balance and historical transaction history, or give that permission to parties of its choice (e.g., government authorities).

2. Automated Market Maker (AMM): an automated market maker is an on-chain exchange that requires no counter-party, and instead relies on pricing according to a fixed curve, and liquidity pools. The idea would be to create a privacy-preserving variant of an AMM-based exchange.

3. Staking Derivatives and Staking Pools: Staked tokens are used to secure the network in Proof-of-Stake networks (like Secret Network). However, as a side effect, these tokens are locked and become illiquid. Staking Derivatives essentially propose treating staked tokens as collateral, and issuing a liquid derivative token to compensate for that. In practice, the idea is to develop a pooling contract that allows different participants to delegate their tokens to the contract itself. The contract, through on-chain governance, will be able to decide how to delegate the aggregated stake to different validators. In return to this, participants will be issued staking derivative tokens, that are liquid and could be used in other financial applications.

4. Fair, Decentralized Poker: We will develop a decentralized poker application that is unique in that it requires no trusted dealer (and is therefore provably fair). Using the privacy-preserving features of Secret Contracts, we can ensure that the game is playable since each party can keep its cards a secret until the appropriate time.

13

Pre-compiled contracts

Pre-compiled contracts are functionalities that are natively compiled to machine-code and treated as a single-line external opcode in the WASM code. This, in turns, means that executing these functionalities happen natively inside of the enclave, without running them through the interpreter. Adding this functionality would add significant performance gains and lower gas costs associated with executing recurrent computationally-expensive tasks.

Multi-signature upgradability and reproducible builds

Secret Network upgrade policy is tightly related to the sealing signing policy, which uses MRSIGNER. In order to improve this and significantly weaken the trust requirements, we will develop a multi-signature alternative to MRSIGNER, as well as a provable reproducible build mechanism to ensure that signed code updates are verifiable.

Upgrading existing components

Similar to previous releases, the daemon application, clients, UI and testing environments would be upgraded to reflect and accommodate these changes.

Secret Network v4 (SNv4)

(Due by June 30, 2022)

Secret Network v4 (SNv4) will further expand the types of functionalities and integrations that the network will support. Specifically, we will add Inter-Blockchain Communication protocol support, allowing bridging to other chains, predominantly in the Cosmos ecosystem. We will further expand our bridge support, to include other chains such as BTC and others, and we will add Secret Oracles support – the ability to fetch authenticated data using TLS directly on-chain – a problem currently plaguing all blockchains, and process that data in a privacy-preserving manner.

Inter-Blockchain Communication (IBC) Protocol Integration

Inter-Blockchain Communication Protocol sets a combined standard that allows moving data, assets and RPC-like executions across different chains. We will research, implement and optimize the IBC specification to fit Secret Network, and connect it with at least the predominant Hub chain at the time, to allow inter-connecting to all other chains in the ecosystem.

Through this, we will aim to support both moving tokens between one chain to the other, and specifically, supporting bridging assets from other chains so that they are represented as Secret Tokens on the Secret Network. In addition, we will add support to bringing Secret Contract functionality to other chains as well.

Additional Bridges

We will add support to bridging other major chains with Secret Network, by expanding the previously built ETH bridge. As this process is manual and custom-made for each chain, we will at least support BTC (Bitcoin), and potentially up to two additional chains.

14

Secret Oracles

Smart (and Secret) Contracts in the context of blockchains are highly resilient and trusted, but they require deterministic and terminating execution. For that reason, fetching data from regular web services is prohibited. Most systems proposed today require trusting an intermediary to bridge data coming from off-chain web-services and sending them as inputs to the contracts.

Instead, we will develop an embedded Secret Oracle functionality, that supports TLS connections from within a secret contract execution, allowing fetching data from outside sources. In addition, we will offer solutions to potential non-determinism and non-terminating executions (e.g., timeouts) that may arise as a result.

As an alternative to this solution, we may develop an off-chain solution that acts as a trusted intermediary, by leveraging the correctness properties of TEEs. In this solution, we will maintain an on-chain registry of trusted oracle operators who have proved their authenticity using a remote attestation-based registration process. These operators will serve as intermediaries who can provide authenticated data from web services to the contracts themselves, without the risk of them tampering with the data. Through incentives and competition, this mechanism should also provide the required liveness property.

Security and Infrastructure Improvements

We will add the following security and infrastructure improvements:

● More granular attestation inspections: ensuring proper group policies are followed, as well as allowing the network to require nodes to re-register. Also, attestation would have expiry dates and will need to be renewed.

● Enclave block header validation: allow enclaves to validate the chain-headers to ensure they are following the correct chain.

● Enclave light-client state validation: enable enclaves to validate the validator set and probe existence of specific items stored in the state of a given block.

● Tamper detection: allow enclaves to detect if someone is trying to take them offline.

Upgrading existing components

Similar to previous releases, the daemon application, clients, UI and testing environments would be upgraded to reflect and accommodate these changes.

Privacy Preserving Contact Tracing (PPCT)

(Due by December 31, 2020)

Separately from Secret Network (but leveraging some or all of its infrastructure), we will develop a privacy-preserving contract-tracing application (PPCT). PPCT is essentially an API which connects to a privacy-preserving storage and private computation service, so the contact-tracing application could be extended to other use cases as well.

In its essence, PPCT will store encrypted data from users, particularly location-data relevant for contact-tracing, will performs analysis on that data, and will allow for two types of outputs: an individual analysis, which is custom-generated and accessible only for each user, and a global analysis, which all users can access. Users opt-in to share data with each analysis.

15

Appendix 2

Project Expenditure Estimate

This Appendix 2 stipulates the process related to the estimation of the Project Expenditures and it supersedes and has precedent over the terms set out in the NRE Funding Agreement (“Agreement”). Project Expenditures due from Funding Partner are to be used only to fund the projects outlined below for Secret Network (v1 – v4), with use of Funding Partner funds and identified in the Schedule 1 below.

Estimation:

GAMMA will update every year of the funding period and communicate before the end of each year, the updated estimate covering until the end of the funding period and an explanation of the changes. GAMMA’s preliminary estimate is as follows in Schedule 1 below.

SCHEDULE 1

Milestone	Estimated due date	Amount
Secret Network v1	June 30, 2020	NIS	7,600,000
PPCT	December 31, 2020	NIS	650,000
Secret Network v2	December 31, 2020	NIS	7,600,000
Secret Network v3	September 30, 2021	NIS	11,400,000
Secret Network v4	June 30, 2022	NIS	11,400,000
Total Project Funding		NIS	38,650,000

The Parties acknowledge that the numbers in the table in Schedule 1 are illustrative and that Funding Partner agreed to a total of NIS 38,650,000 as set out in article 2.1 of this Agreement.

The Project Expenditure estimate and the Development Plan will be updated yearly in good faith through mutual discussions with Funding Partner.

GAMMA and Funding Partner will create a Technological Review Board (TRB) including only software personnel designated by each Party and responsible for creating and monitoring the Development Plan.

Notwithstanding any delays by GAMMA, Funding Partner will abide by its commitment as stipulated in the Development Plan as determined by the TRB, including but not limited to the stipulated technical support, specification agreement, etc,.

16