Innovators

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.

Types of Submissions

There are two types of Submissions that Innovators can make to TIG:

Code Submissions

Code Submissions involves optimising code-implementations of existing algorithm methods or implementing an entirely new one for Benchmarkers in TIG. This can involve optimising the performance of code previously submitted by another Innovator, or implementing an entirely new algorithmic method.

Innovators can submit their code implementations of their algorithm methods or optimise existing ones.

Advance Submissions

Advance Submissions involves novel algorithmic methods for solving TIG’s proof-of-work challenges. An Advance Submission will often yield such a significant performance enhancement that even unoptimised code of the new method outpaces the most optimised code of an existing one.

Innovators can make an Advance Submission by submitting their novel algorithmic method to the Innovation Game, which is then evaluated by the TIG Foundation.

Decentralised Repository

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.

Innovators must pay a fee to make a submission (10 $TIG for Code Submissions, 250 $TIG for Advance submissions). This is deducted from their Available Fee Balance. Check Making Top-ups to top-up your balance.

To address the possibility of piracy and to provide an opportunity for IP protection, TIG implements two mechanisms:

Push Delay Mechanism

When an Innovator submits an algorithm:

Submissions are committed to a private branch. If the submission is a code submission, it is compiled into a shared object for execution by Benchmarkers through tig-runtime.
At the start of round X + 2 (where X is the submission round), the branch is pushed to TIG’s public repository
Submissions can start being adopted by Benchmarkers for OPoW once “active”:

Code submissions: Active at start of round X + 4.
Advance submissions: Active at start of round X + 4 if it has 50% yes votes.

This delay protects Innovators by giving them a head start before others can optimise their work.

Merge Points Mechanism

Once active, for every block in which a submission achieves sufficient adoption (25% for Code submissions, 50% for Advance submissions), it earns a merge point alongside a share of the block reward based on its adoption.

At the end of each round, for each challenge: the Code and Advance submission 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.

Once merged, the Code and Advance submissions earn rewards every block as long as their adoption is above 0%.

This mechanism deters piracy by requiring significant Benchmarker adoption before an algorithm can earn rewards. This discourages the use of algorithms that are merely slight modifications of existing high-performing merged algorithms.

Verifiable Execution

TIG ensures that the correct distribution of rewards amongst algorithms through verifiable execution which deterministically emits a solution, runtime_signature and fuel_consumed:

solution: This is the output of the algorithm and might not be a valid solution.
runtime_signature: Updated on certain opcodes using stack values, resulting in an unpredictable value that can only be reproduced by actually executing the algorithm on a given challenge instance.
fuel_consumed: Updated using hardcoded values on certain opcodes, allowing termination of executions that take too long. Current fuel limits is set such that execution is approximately a max of 5-10s on most hardware.

TIG can re-execute algorithms to detect mismatches with proofs submitted by Benchmarkers. Any differences signals fraud, where the Benchmarker claims to have used algorithm “A” whilst they actually used algorithm “B”.

TIG Implements verifiable execution via its high-performance native runtime.

Probabilistic Verification Code Submissions