Innovators

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 Algorithm Submissions

Innovators can submit two types of algorithms:

Code submissions

Code submissions are implementations of algorithm methods for use by Benchmarkers in TIG. This can involve optimising the performance of code previously submitted by another Innovator, or implementing an entirely new algorithmic method.

Read more about Code Submissions.

Breakthrough submissions

Breakthrough submissions are novel algorithmic methods for solving TIG’s proof-of-work challenges. A breakthrough 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.

Read more about Breakthrough Submissions.

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, 250 TIG for breakthroughs). This is deducted from their Available Fee Balance. You can top up via the Benchmarker Dashboard

To address the possibility of piracy and to provide an opportunity for IP protection, TIG implements a “push delay” and “merge points” mechanism:

Push Delay Mechanism

When an Innovator submits an algorithm:

  1. Submissions are committed to a private branch. The code is compiled to WebAssembly (WASM)

  2. At the start of round X + 2 (where X is the submission round), the branch is pushed to TIG’s public repository

  3. Algorithms can start being adopted by Benchmarkers once “active”:

  • Code submissions: Active at start of round X + 4
  • Breakthrough 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

For every block in which an algorithm achieves sufficient adoption (25% for code, 50% for breakthroughs), it earns a merge point alongside a share of the block reward based on its adoption.

At the end of each round, the code and breakthrough 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.

Once merged, the code/breakthrough earns reward every block as long as their adoption is above 0%.

This mechanism aims to deter piracy by requiring a significant % of Benchmarkers to use an algorithm before it can earn rewards.

Verifiable Execution

TIG ensures that the correct distribution of rewards amongst algorithm 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”.

Currently, TIG only implements verifiable execution via a custom WebAssembly Virtual Machine. The WASM blob for an algorithm can be obtained via:

https://raw.githubusercontent.com/tig-foundation/tig-monorepo/<branch>/tig-algorithms/wasm/<branch>.wasm

where <branch> is <challenge_name>/<algorithm_name>

In the near future, TIG will support verifiable execution for native CPU and GPU hardware by integrating into the compilation process.