Advance Submissions
Advance Submissions in TIG are defined as novel algorithmic methods for solving one of TIG’s proof-of-work challenges. Advance Submissions yields huge performance enhancements, often outpacing the most optimised code of existing methods, even when unoptimised.
See Code Submissions vs Advance Submissions for a definition of what constitutes an Advance submission.
Making an Advance Submission
An Innovator may submit a novel algorithmic method to the Innovation Game for a fee of 250 $TIG (or 260 $TIG if Code submission is included).
After receipt, the TIG Foundation collaborates with the Innovator to discuss the submission’s claims and to clarify any open questions. There is no fixed time limit for this dialogue.
If the Innovator then elects to proceed, the Advance method can be formally entered into the Game for 250 $TIG (or 260 $TIG Code Submission was included). The final package—submitted as a Markdown file—receives a Unique Algorithm Identifier (UAI). If the Innovator chose to submit accompanying code, the code must cite this UAI and will progress through the Code submission’s push delay mechanism.
Check Making Advance Submissions for step-by-step instructions.
Push Delay and Merge Point Mechanism
Similarly to Code submissions, an Advance method progresses through the “Push Delay and Merge Point Mechanism”, which determines the methods state. Below we outline the specific duration requirements and criteria that must be met to advance to the next state. The state of a method determines its visibility, availability in OPOW, and reward eligibility.
| State | Duration | Repository | Process |
|---|---|---|---|
| Pre-Submitted | Not Fixed | None | Discussion with TIG. Innovator decides to proceed → Submitted |
| Submitted | 2 rounds | <CHALLENGE>/<ADVANCE> (private) | Nothing happens during this delay period. State remains synced with Code Submissions |
| Pushed | 1 round | Same branch (public) | The method is publicly visible. Note if an algorithm was also submitted it becomes visible and testable at the same time. After one round → Voting. |
| Voting | 1 round | Same branch (public) | The Voting procedure determines whether the method is an Advance method. This lasts a round. If it receives at least 50% → Active. Else → Inactive. |
| Active | Until merged | Same branch (public) | Benchmarker Algorithms can reference the UAI during OPoW • Every block: if adoption > 0.5 → +1 merge point• End of round: if merge points ≥ 5040 → Merged• Merge points reset each round |
| Merged | Permanent | main branch (public) | • Remains in main branch indefinitely. |
Note:
- A forum post will also be created for discussing the evidence that goes towards Method voting.
- If a Method fails voting, it becomes Inactive and cannot ever proceed to the active state.
- To achieve merged status, a Method must accumulate at least merge points and have the highest merge point count in that round (amongst other Methods).
- If both an Advance method and a Code submission are made together, they will share the same
algorithm_id.
Method states and transitions in TIG
For details on Advance Submission rewards and calculations, see Advance Innovator Rewards.