Update tech explainer.

docs/tech/1_basics.md

@@ -2,14 +2,14 @@
 
 ## 1.1. Overview
 
-The Innovation Game (TIG) is the first coordination protocol designed specifically for algorithmic innovation. At the core of TIG lies a novel variant of proof-of-work called optimisable proof-of-work (OPoW).
+The Innovation Game (TIG) is the first and only protocol designed specifically to accelerate algorithmic innovation. At the core of TIG lies a novel variant of proof-of-work called optimisable proof-of-work (OPoW).
 
-OPoW uniquely integrates multiple proof-of-works to be featured, "binding" them in a manner prevents centralization due to optimizations of the proof-of-work algorithms. This resolves a longstanding issue that had hindered proof-of-work from being based on real-world computational scientific challenges.
+OPoW uniquely features multiple proof-of-works, “binding” them together in a manner that prevents centralisation due to optimisations of the proof-of-work algorithms (see Section 2.1 of the TIG white paper for details). This resolves a longstanding issue that had hindered proof-of-work from being based on real-world computational scientific challenges.
 
 TIG combines a crypto-economic framework with OPoW to:
 
-1. Incentivise miners, referred to as Benchmarkers, to adopt the most efficient proof-of-work algorithms contributed openly to TIG. This incentive is derived from sharing block rewards proportional to the number of solutions found.
-2. Incentivise contributors, known as Innovators, to optimise existing proof-of-work algorithms and invent new ones. Their incentive is tied to sharing block rewards based on adoption of their algorithms by Benchmarkers.
+1. Incentivise miners, referred to as Benchmarkers, to adopt the most efficient algorithms (for performing proof-of-work) that are contributed openly to TIG. This incentive is derived from sharing block rewards proportional to the number of solutions found.
+2. Incentivise contributors, known as Innovators, to optimise existing proof-of-work algorithms and invent new ones. The incentive is provided by the prospect of earning a share of the block rewards based on adoption of their algorithms by Benchmarkers.
 
 TIG will progressively phase in proof-of-works over time, directing innovative efforts towards the most significant challenges in science.
 
@@ -32,7 +32,7 @@ A round spans 10,080 blocks, approximately equivalent to 604,800 seconds or 7 da
 
 TIG’s token emission schedule comprises 5 tranches, each with the same total emission of 26,208,000 TIG, but successively doubling in duration (measured in rounds):
 
-| **Tranche** | **#Rounds** | **Emissions per block** | **Emissions per round** | **Start Date** | **End Date** |
+| **Tranche** | **#Rounds** | **Token emissions per block** | **Token emissions per round** | **Start Date** | **End Date** |
 | --- | --- | --- | --- | --- | --- |
 | 1   | 26  | 100 | 1,008,000 | 24 Nov 2023 | 30 May 2024\* |
 | 2   | 52  | 50  | 504,000 | 31 May 2024\* | 30 May 2025\* |
@@ -42,10 +42,12 @@ TIG’s token emission schedule comprises 5 tranches, each with the same total e
 
 \*Approximates
 
-Post tranche 5, rewards are solely based on tokens generated from license fees paid by commercial entities purchasing licenses.
+![Cumulative token emissions schedule](../images/emissions_schedule.jpg)
+
+Post tranche 5, rewards are solely based on tokens generated from TIG Commercial license fees.
 
 ## 1.5. TIG Token
 
-The [TIG token contract](../tig-token/TIGToken.sol) is derived from OpenZepplin's ERC20 standard and is deployed to Basechain at the following address: [0x0C03Ce270B4826Ec62e7DD007f0B716068639F7B](https://basescan.org/token/0x0C03Ce270B4826Ec62e7DD007f0B716068639F7B).
+The TIG token adheres to the ERC20 standard and is deployed to Basechain at the following address: [0x0C03Ce270B4826Ec62e7DD007f0B716068639F7B](https://basescan.org/token/0x0C03Ce270B4826Ec62e7DD007f0B716068639F7B).
 
-TIG tokens earned during a round are minted within 7 days following the conclusion of that round.
+TIG tokens earned during a round are minted within 7 days following the conclusion of that round.

docs/tech/3_innovators.md

@@ -1,13 +1,13 @@
 # 3. Innovators
 
-Innovators are players in TIG who optimise existing proof-of-work algorithms and/or invent new ones, contributing them to TIG in order to share in block rewards.
+Innovators are players in TIG who optimise existing proof-of-work algorithms and/or invent new ones, contributing them to TIG in the hope of earning token rewards.
 
 This chapter covers the following topics:
 
 1. The two types of algorithm submissions
 2. Mechanisms for maintaining a decentralised repository
 3. How algorithms are executed by Benchmarkers
-4. How algorithms earn block rewards
+4. How algorithms earn token rewards
 
 ## 3.1. Types of Algorithm Submissions
 
@@ -20,50 +20,48 @@ There are two types of algorithm submissions in TIG:
 
 Presently, code submissions are restricted to Rust, automatically compiled into WebAssembly (WASM) for execution by Benchmarkers. Rust was chosen for its performance advantages over other languages, enhancing commercial viability of algorithms contributed to TIG, particularly in high-performance computing. Future iterations of TIG will support additional languages compilable to WASM.
 
-**Breakthrough submissions** involve the introduction of novel algorithms tailored to solve TIG's proof-of-work challenges. A breakthrough submission is expected to yield such a significant performance enhancement that even unoptimised code of the new algorithm outpaces the most optimised code of an existing one.
+**Breakthrough submissions** involve the introduction of novel algorithms tailored to solve TIG's proof-of-work challenges. A breakthrough submission will often yield such a significant performance enhancement that even unoptimised code of the new algorithm outpaces the most optimised code of an existing one.
 
-Support for breakthrough submissions is on TIG's roadmap.
+Note: Support for breakthrough submissions is not currently in place but will be available in the coming months (pending a sufficiently wide token distribution).
 
 ## 3.2. Decentralised Repository
 
-Algorithms are contributed to a repository devoid of a centralised gatekeeper. TIG addresses crucial issues such as spam and piracy to ensure fair rewards for Innovators based on performance, maintaining a strong incentive for innovation.
+Algorithms are contributed to a repository without a centralised gatekeeper. TIG addresses crucial issues such as spam and piracy to ensure fair rewards for Innovators based on performance, maintaining a strong incentive for innovation.
 
 To combat spam, Innovators must pay a submission fee of 0.001 ETH, burnt by sending it to the null address (0x0000000000000000000000000000000000000000). In the future, this fee will be denominated in TIG tokens.
 
-To counter piracy concerns, TIG implements a push delay and merge points mechanism:
+To address the possibility of piracy and to provide an opportunity for IP protection, TIG implements a “push delay” and “merge points” mechanism:
 
 ### 3.2.1. Push Delay Mechanism
 
-Upon submission, algorithms are committed to their own branch and pushed to a private repository. Following successful compilation into WebAssembly (WASM), a delay of `3` rounds ensues before the algorithm is made public where the branch is pushed to TIG's public repository. This delay safeguards Innovators' contributions, allowing them time to benefit before others can optimise upon or pirate their work.
+Upon submission, algorithms are committed to their own branch and pushed to a private repository. Following successful compilation into WebAssembly (WASM), a delay of 3 rounds ensues before the algorithm is made public where the branch is pushed to TIG’s public repository. This delay safeguards Innovators' contributions, allowing them time to benefit before others can optimise upon or pirate their work.
 
 Notes:
 
 - Confirmation of an algorithm's submission occurs in the next block, determining the submission round.
-
-- An algorithm submitted in round `X` is made public at the onset of round `X + 3`.
+- An algorithm submitted in round X is made public at the onset of round X + 3.
 
 ### 3.2.2. Merge Points Mechanism
 
-This mechanism aims to deter algorithm piracy. For every block in which an algorithm achieves at least `25%` adoption, it earns a merge point alongside a share of the block reward based on its adoption.
+This mechanism aims to deter algorithm piracy. For every block in which an algorithm achieves at least 25% adoption, it earns a merge point alongside a share of the block reward based on its adoption.
 
-At the end of every round, the algorithm from each challenge with the most merge points (exceeding a minimum threshold of `5040`) is merged into the repository's main branch. Merge points reset each round.
+At the end of each round, the algorithm from each challenge with the most merge points (exceeding a minimum threshold of 5,040) is merged into the repository's main branch. Merge points reset each round.
 
-Merged algorithms, as long as their adoption is above `0%`, share in block rewards every block.
+Merged algorithms, as long as their adoption is above 0%, share in block rewards every block.
 
-The barrier to getting merged is intentionally set high as to minimise the likely payoff for pirating algorithms.
+The barrier for an Innovator contribution to be merged is intentionally chosen to be relatively high to minimise the likely payoff for pirating algorithms.
 
-For breakthrough submissions, the vote for recognising the algorithm as a breakthrough starts only when its code gets merged (details to come). This barrier is based on TIG's expectation that breakthroughs will demonstrate distinct performance improvements, ensuring high adoption even in unoptimised code.
+For algorithmic breakthrough submissions, the vote for recognising the algorithm as a breakthrough starts only when its code gets merged (details to come). This barrier is based on TIG’s expectation that breakthroughs will demonstrate distinct performance improvements, ensuring high adoption even in unoptimised code.
 
 ## 3.3. Deterministic Execution
 
-Algorithms in TIG are compiled into WebAssembly (WASM), facilitating execution by a corresponding WASM Virtual Machine. This environment, based on wasmi developed by parity-labs for blockchain applications, enables tracking of fuel consumption, imposition of memory limits, and has tools for deterministic compilation.
+Algorithms in TIG are compiled into WebAssembly (WASM), facilitating execution by a corresponding WASM Virtual Machine. This environment, based on wasmi developed by Parity Technologies for blockchain applications, enables tracking of fuel consumption, imposition of memory limits, and has tools for deterministic compilation.
 
 Benchmarkers must download the WASM blob for their selected algorithm from TIG's repository before executing it using TIG's WASM Virtual Machine.
 
 Notes:
 
 - The WASM Virtual Machine functions as a sandbox environment, safeguarding against excessive runtime, memory usage, and malicious actions.
-
 - Advanced Benchmarkers may opt to compile algorithms into binary executables for more efficient nonce searches, following thorough vetting of the code.
 
 ### 3.3.1. Runtime Signature
@@ -74,6 +72,6 @@ As an algorithm is executed by TIG's WASM Virtual Machine, a "runtime signature"
 
 TIG incentivises algorithm contributions through block rewards:
 
-- `15%` of block rewards are allocated evenly across challenges with at least one "pushed" algorithm before distributing pro-rata based on adoption rates.
-
-- In the future, a fixed percentage will be assigned to the latest breakthrough for each challenge. In the absence of a breakthrough, this percentage reverts back to the Benchmarkers' pool. Given the rarity of breakthroughs, this represents a significant reward, reflecting TIG's emphasis on breakthrough innovations.
+- 15% of block rewards are allocated evenly across challenges with at least one "pushed" algorithm before distributing pro-rata based on adoption rates.
+- In the future, a fixed percentage (we intend 15% of block rewards, see below) will be assigned to the latest algorithmic breakthrough for each challenge. In the absence of a breakthrough, this percentage reverts back to the Benchmarkers' pool. Given the expected relative rarity of algorithmic breakthroughs (compared to code optimisations), this represents a significant reward, reflecting TIG's emphasis on breakthrough innovations.
+- When the rewards stream for algorithmic breakthroughs is introduced, there will be a total of 30% of block rewards for Innovators and 70% for Benchmarkers. Over time, we intend for the percentage of block rewards for Innovators to approach 50%.