Updating parameters & links in docs.

docs/tech/1_basics.md

@@ -34,8 +34,8 @@ TIG’s token emission schedule comprises 5 tranches, each with the same total e
 
 | **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\* |
+| 1   | 26  | 100 | 1,008,000 | 24 Nov 2023 | 1 June 2024 |
+| 2   | 52  | 50  | 504,000 | 1 June 2024 | 31 May 2025\* |
 | 3   | 104 | 25  | 252,000 | 31 May 2025\* | 29 May 2027\* |
 | 4   | 208 | 12.5 | 126,000 | 30 May 2027\* | 24 May 2031\* |
 | 5   | 416 | 6.25 | 63,000 | 25 May 2031\* | 14 May 2039\* |

docs/tech/2_challenges.md

@@ -73,7 +73,7 @@ The Pareto frontiers mechanism works as follows:
 3. Update the total number of qualifying solutions.
 4. If the total number of qualifiers is below a threshold, repeat the process.
 
-\*The threshold number of qualifiers is currently set to 1,000.
+\*The threshold number of qualifiers is currently set to 5,000.
 
 Notes:
 

docs/tech/3_innovators.md

@@ -39,7 +39,7 @@ Upon submission, algorithms are committed to their own branch and pushed to a pr
 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 + 2.
 
 ### 3.2.2. Merge Points Mechanism
 

docs/tech/4_benchmarkers.md

@@ -138,6 +138,6 @@ Every block, 85% of block rewards are distributed pro-rata amongst Benchmarkers
 
 ### 4.4.1. Cutoff Mechanism
 
-To strongly disincentivise Benchmarkers from focusing only on a single challenge (e.g. benchmarking their own algorithm), TIG employs a cutoff mechanism. This mechanism limits the maximum qualifiers per challenge based on an average number of solutions multiplied by a multiplier (currently set to 2.5).
+To strongly disincentivise Benchmarkers from focusing only on a single challenge (e.g. benchmarking their own algorithm), TIG employs a cutoff mechanism. This mechanism limits the maximum qualifiers per challenge based on an average number of solutions multiplied by a multiplier (currently set to 1.5).
 
 The multiplier is such that the cutoff mechanism will not affect normal benchmarking in 99.9% of cases.

swagger.yaml

@@ -17,6 +17,11 @@ info:
 servers:
   - url: https://mainnet-api.tig.foundation
   - url: https://testnet-api.tig.foundation
+tags:
+  - name: GET
+    description: There is a rate limit of 60 requests per minute per IP address.
+  - name: POST
+    description: There is a rate limit of 20 requests per minute per IP address.
 paths:
   /get-algorithms:
     get:
@@ -275,8 +280,6 @@ paths:
           * The transaction should emit a `ProxyCreation` event. [Example](https://basescan.org/tx/0xa61a5d1e4deaf4f4c42ede0ad412e4ca02f5b3d38ebff61f56e8e8d16153d4e6)
           
           * `<signature>` can be produced by any current owner of the multisig
-          
-        * If header `X-Aws-Waf-Token` is invalid, a `405` error will be returned where the body is HTML for completing a captcha
         
       requestBody:
         content:
@@ -290,11 +293,6 @@ paths:
                   $ref: '#/components/schemas/Signature'
                 gnosis_safe_setup_tx_hash:
                   $ref: '#/components/schemas/TxHash'
-      parameters:
-        - in: header
-          name: X-Aws-Waf-Token
-          schema:
-            type: string
       responses:
         '200':
           description: Success
@@ -305,8 +303,6 @@ paths:
                 properties:
                   api_key:
                     $ref: '#/components/schemas/MD5'
-        '405':
-          description: Complete captcha
   /submit-algorithm:
     post:
       tags: