Skip to main content

The Tellor technical design is a carefully designed crypto economic mechanism for providing measurably secure values on-chain. The staking amount in the current Tellor technical design is the amount of Tributes that a party needs to deposit before they can mine. The dispute fee is the amount of Tributes parties need to dispute given values. These variables are necessary for a secure system, but the exact amount necessary and behaviour of these variables is non-obvious. This article attempts to lay out our reasoning as to the amount and behavior of these variables as well as the responsibility of staked vs non-staked parties.

Securing the Challenge

In a system of honest miners, both the staking amount and dispute fee are unnecessary. Unfortunately, malicious parties do exist and these variables play a critical role in the security of our system. The mechanics of the system are that parties must deposit the stake amount to mine and pay the deposit fee to report a malicious miner. Then, upon the close of a successful challenge (a dispute), the staking amount of the malicious miner is paid to the disputer. Conversely, in the case of an unsuccessful challenge, the fee the disputer paid is given to the challenged miner.

The goals of the staking system are as follows:

  • The staking amount acts as a penalty for malicious miners
  • The staking amount serves as a bounty for reporters in the system.
  • Locks miners for a certain period of time (during dispute and voting period), so they cannot leave the system after submitting a malicious value
  • Locked Tributes benefit the token price by reducing the circulating supply

Therefore, we want the total amount staked to be very high (lower circulating supply => higher price). We conversely want as many parties staked as we can (more independent miners => more decentralized). The stake amount must be low enough to allow many parties to be able to mine, but high enough to be a penalty for misreporting. Since more miners and contributors to a system likely implies that it is more decentralized and collusion resistant, it is obvious that it is more beneficial for the system to have 100 parties staked with 20% of the tribute supply than 5 parties staked with 40% of tributes supply, but non-obvious as to the exact elasticity of the mining supply.

The dispute fee’s goals:

  • Encourage parties to dispute
  • Discourage parties from disputing correct values (spamming our system by forcing votes / locking miners for one week)
  • In the case of a failed dispute, the dispute Fee should cover the miner’s lost profits during the voting period (If he cannot mine for 1 week, what should he be paid?)

The dispute fee should at a minimum compensate the miner for locking his stake amount (cannot mine out of that account). Since the mining is off-chain however, the hash power pointed at that address can simply be shifted to another staked account. Theoretically, one could borrow money, stake again and mine on the new account. The dispute fee then should at a minimum cover the interest costs of carrying this amount for one week (the voting period). To give an example of a possible scenario, setting the dispute fee as 1% of the staking amount corresponds to a yearly rate of 68%, so any honest miner will likely be happy to be disputed in this scenario.

What should the stake amount and dispute fee be?

The issue with setting the staking amount and the dispute fee is that predicting the Tellor Tribute price is very difficult. If we assume that our token in one year will have $2 million market cap, with initial stake amount and dispute fee at 1000 and 100 respectively, that translates to a token price of ~7$ which means it will cost $7,000 to stake and $700 to dispute. This may seem reasonable, but the problem is that we could also be wildly successful and have a $200 million market cap (less than half the current Chainlink market cap). Now suddenly, it costs $700,000 to stake and $70,000 to dispute! This may also be reasonable / desirable from a security perspective, but it also could be prohibitively restrictive to miners and participants in our system.

In the end, we settled on a variable dispute fee, but a constant stake amount.

Stake amount

In the code base for Tellor, the stake amount is set in Tributes. However, as the demand in the system rises, the security (staking amount) should also rise. Because the stake amount is set in Tributes it may seem like a constant value, but (indirectly) it is not. The way it would rise is by being linked to a demand variable, in our case the token price. Hence, as demand increases so would the token price, making it more expensive to stake as the cost of Tributes rise.

The staking amount provides the majority of the security to the system. It makes the PoW secure. The PoW mostly adds complexity and an additional network of participants in the validation of the Tellor system.

Dispute Fee

The dispute fee should be variable (in the code) and based upon the number of miners in a system. The reason being that currently, a minimum of 5 miners are required (hard coded) to add a value. If there are only 4 active miners, the system cannot mine a value. So a malicious actor could dispute all miners in our system to halt it or allow themselves to be the sole miner.

To make it flexible, yet fit our system, we designed it with a minimum as well as a maximum amount (it shouldn’t be free or too restrictive). Tellor decided on a maximum of the staking amount and a minimum of 1.5% of the staking amount. We decrease the dispute fee as the number of miners grows toward the target number of miners. A formula representing our dispute fee is as follows:

Dispute fee= a (1 — c / m)


a = stake amount in Tributes

m = target number of miners

c = count of currently staked miners


The two main challenges for Tellor when setting these variables are finalization of values and how directly related the number of miners in the network affect its security.

Finalization delay

One of the big challenges we face in Tellor is that disputing delays the result from being finalized. This is not a problem as to the validity of Tellor data, but rather just to the usability. Currently, Tellor has 1-day finalization on values. A competitor could theoretically dispute all values and create a system where Tellor now has a 7-day finalization period.

Limited number of miners

The other issue is that we only have a limited number of miners. If all miners are disputed, the system technically comes to a halt. A competitive miner could dispute all miners to be the only miner himself (now cost to 51% attack is minimal).

The number of current Tellor miners directly affects how fast an attack can be accomplished to halt the entire system. How quickly miners are able to get a loan and re-stake or have a process in place to quickly stand up miners is important. With 100 miners on Tellor if a party disputes all miners in the next 20 cycles, it would take them 3.3 hours to halt the system.

h=m / (s / c)



h = hours

m = number of miners

c= cycles per hour (60 / target time)

The limit to this analysis however is the difficulty factor. If the Tellor system has 100 miners, and all of them are disputed, in order to keep 10-minute blocks, the attacker would need to keep the same hash power as the 100 miners, something that is very unlikely and/or quite costly.

Encouraging more miners

Tellor wants more miners. Any system wants more active participants. The problem occurs though that a higher staking amount => less miners as parties are more incentivized to pool together to only have one staking fee.

How do you encourage multiple miners and not just pools?

When the staking amount gets high (or even before), you will have parties pool their Tributes and hash power together. Now instead of 10 separate miners with 10 separate stakes, you get the 10 miners going through a pool and only 1 stake in the system. Do we care? Obviously, all PoW systems have this problem. The problem is if you use PoS, then you just give control to the big exchanges and whales and/or delegate staking happens. Which one is preferred is not immediately obvious.

Potential Solutions for encouraging multiple miners

Tellor examined a few different models for potentially discouraging pools and encouraging more staked miners. One idea is having miners pay per submission (so not a blanket deposit, but rather a stake per submitted solution). Looking at the idea of paying per solution, this materially decreases security in our system. Attackers likely want to go after one value in our system, so assuming that the per submission fee is cheaper than the overall stake amount, the cost to attack that one value goes down by the percentage difference between the two amounts required to submit in each system. The goal of the staking amount should be that you lose more if you’re malicious. Allowing a party to stake just a small amount and still submit values is potentially dangerous.

Tellor Thoughts

Tellor wants a lot of miners, willing to stake lots of tokens since they will be honest. The ultimate amount of the staking fee should be based upon a number that is competitive with other staking systems, yet high enough to secure our system. It may be hard at first to get miners to have enough tokens (or faith in the system) to stake and then mine on Tellor. In order to support the system Tellor plans to use a portion of the dev-share in order to help initial miners stake in order to kick start the system.

On the dispute fee, we want a variable rate. It should be very costly to dispute miners if there are only a few (we want to prevent spamming of all miners), however relatively cheaper when we have a robust mining community (only enough to disincentivize finalization delays).

Voting in the Tellor system

Like many other blockchain governance systems, Tellor utilizes voting to secure its system. A common question received and thought about by us, is who can actually participate in the vote. One argument is that only staked parties can vote, while other thoughts allow for any party to vote. Obviously voting and incentivizing voting is a problem not unique to the blockchain space, but there are a few options of dealing with voting’s main problems: lack of turnout and the vote and run.

Vote and run

Allowing unstaked voting can lead to a vote and run. The downfall in only allowing staked parties to vote however, is that attack amounts are more easily known. If you have only 10% of your system staked, now a party knows that if they quickly stake 10% and initiate a dispute, they will likely have control. In an open system, the troops can always be rallied to show up for a vote (you could have a social media campaign to encourage voting). The question would then be, does the security of having more parties staked (and locked during votes) make up for the transparency in the cost to break? Over time the general voting percentage is known and can be predicted and it inadvertently becomes transparent anyway.

The biggest issue could be that it acts as a disincentive for voting and with less voting in your system the measured security will likely be lower too. On the other hand it also prevents, vote and runs (hit and run).

Lack of Turnout / Incentivizing voting

There are few options when it comes to incentivizing voting: pay the voters, penalize the non-voters, allow delegation of voting responsibility, or do none of the above.

The Tellor Decision

Anyone can vote. The problem is that you would need a high number of parties staking for your system to be secure. If you have a low amount (say 10K tokens). Now an attacker knows with certainty that they could stake 10k tokens and dispute correct values before the system had a chance to stake more to counteract their influence. With an open system, the attacker would potentially have to stake up to 50% of the token supply as if an attack began, the Tellor community could rally exchanges and large token holders to vote against the attacker (even if they do not normally vote). This would not be possible if they would be required to stake from the beginning.


These decisions were tough. We put a lot of thought into the current design of Tellor and we’re hoping that new methods and designs become available in the future that allow us to update our system to something without so many tradeoffs (us and everyone else I’m sure). Currently we allow everyone to vote, have a fixed staking amount, but a variable dispute fee. Hopefully this article did a good job laying out some of our arguments and we’d love to have you join our Discord to help us work towards an even better system!