This article will lay out the formulas and thinking behind Tellor security. It should give you a solid understanding of the current crypto-economic guarantees underlying the system and even the best ways to attack it and how much it will cost. For a more general overview of Tellor and how it works, check out our whitepaper.
A word on finality and forks
Tellor is a sovereign L1. It has its own sets of validators and its own nodes which maintain data and perform execution for the chain based on the consensus of the CometBFT consensus mechanism.
A formal proof / discussion on CometBFT security can be found here.
Tellor will be secure up to certain points using this consensus mechanism (e.g. 2/3rds of the nodes being malicious), however like all L1’s, Tellor is sovereign and the ability to fork is preserved. What this means is that even if the chain is compromised (or a bug is found in the code), the nodes can choose to not follow that portion of the chain and perform an action that does not follow strict consensus rules. For example, if someone bought 90% of the Tellor tokens, and started validating only empty blocks, it is unlikely that the Tellor community (other nodes/token holders/ users) would continue to use this chain. They would likely do a “hard fork” where that one party with 90% of the tokens would be removed, and the chain would continue as if they didn’t exist.
What this means is that Tellor is impossible to break forever. If it’s obvious that something bad has happened, a chain (or even a subset of honest users) always has this option and it’s a powerful one that pushes ultimate security to the social level.
That said, it is a backstop that should very rarely (if ever) be used. It’s very manual and if done often, can cause more harm in terms of moral hazard, as it being seen as an option can deter more preferred security practices. For Tellor it serves as an almost game theoretic back stop that allows Tellor to secure more value than that of strict crypto-economic formulas (which this article will show). It’s why you don’t see many attacks on L1 PoS or PoW….the theoretical ability to fork makes attacks uncertain at best.
Knowing this, all security must be analyzed in conjunction with the implementation or usage of the Tellor protocol. Even if forking at the social layer is an option, if funds change hands or protocols are drained before the fork can happen, then the ultimate state ultimately does not matter. For those reasons, this article will analyze attack costs purely regarding the crypto-economic (not social or implementation layer) security of the consensus mechanism and the design of Tellor.
Cost to break
Most of the “cost to break” analysis must be done on an individual implementation level. There is no one way to use Tellor, however we will try to walk through standard implementations and go through how the chain can be broken in various ways. That said, if you implement an oracle incorrectly, you can still be wrecked even if Tellor is working as designed. For that reason, feel free to contact us if you have any implementation concerns and definitely do your own research and analyze each project using Tellor carefully.
Now for the attacks!
Cost To Break Attacks:
- Malicious Upgrade of Tellor Chain
- Submitting a bad value – Tellor comes to consensus on bad value
- Submitting a bad value – optimistic usage
- Cost to Break Implementation contract
Cost To Censor Attacks:
- Break finality by removing consensus
- Disputing every value that comes through (freezing out all reporters)
- Censoring on the user side – Forks
- Censoring on the user side – Optimistic Values
Variables:
CTB = Cost to Break
ST = number of staked tokens (by validators or delegated to them)
P = price of staking token
Malicious upgrade of Tellor Chain
This is the base attack of breaking a Cosmos chain. The TLDR is that it’s the cost to break the consensus mechanism (you own the validator set and can make blocks say whatever you want or even revert past blocks). Of course, should this happen, we would undoubtedly fork, but since a fork of this magnitude would not be instant and likely break (or at least pause) user systems, this number should be known.
This analysis is relatively simple, it’s the cost to obtain ⅔ the validators for the chain. Assuming you cannot kick current validators out of the set, it would be:
CTB = 2 * ST * P
This simple calculation says that if your validator set has 30M staked, it will cost 60M to make them a ⅓ minority where you control the chain. For most chains this calculation wouldn’t be that much money (relative to the billions secured by Ethereum), but there are few caveats that make this attack unlikely in the Tellor system:
- Delay in staking period – there is a limit of 5% on the amount that the validator set can change in a given 12 hour period. In order to stake change the validator set to control the chain, you would need to stake the max 5% for 23 periods or 12.5 days. During this time, the attack would be clearly coming (almost all larger validators are known in these ecosystems), forks could be created and messaged to users downstream. If you wanted to sneakily do this, you would need to bribe the current validator set to give you private keys of their validators off-chain, an attack which could happen but would likely be heard of and dispelled by honest validators.
- Liquidity issues – Now lets say you do still want to buy up this large amount of tokens. This is no easy feat. In doing so, you will likely drastically increase the price of the attack (since you’ll be pushing up the price). Liquid tokens with large market makers and high liquidity relative to their market cap are actually at a higher risk of attack here (less price impact). That said, this would be one of the most challenging limitations in performing this attack, not to mention that most CEX’s now cooperate with authorities and the anonymity of the attacker would most likely be compromised.
- Honest party majorities- Believe it or not, once ⅓ of a given token’s total supply is staked by honest parties, this attack becomes impossible! This is because the attacker would actually need to purchase tokens from already staked honest parties. This happens in most Cosmos chains and would practicality nullify the attack.
This attack vector is highly unlikely. PoS chains are rarely attacked for many of the reasons above and as long as users are cognizant members of the community watching for attacks, it can be easily handled should a situation arise.
Submitting a bad value – Tellor comes to consensus on bad value
This is the same as breaking consensus. For Tellor to come to consensus, this means that ⅔ of validators would need to be compromised by bad actors. As noted above, this is a highly unlikely/ costly scenario.
Submitting a bad value – optimistic usage
For an optimistic usage, the cost to break is relative to the implementation. Similar to older versions of Tellor, users relying on optimistic usage will use a delayed price feed that is subject to dispute. In most cases, bad values are disputed very quickly and the parties are secure up to the point of consensus (e.g. breaking the Tellor chain) and disputes are only censoring the time to usage. That said, if your query is under-reported (e.g. no reporters support it or know how to report/dispute it), the cost to submit a bad value may be very low if no one is monitoring the chain for disputes.
The way the Tellor system works, if a party is staked for some amount TRB and submits a bad value, you can “flag” the bad value by disputing it (equal to his stake if you want to slash him completely). This means if your attacker has more tokens than the honest reporters (willing to dispute), he can submit bad values. So if only 100 TRB worth of honest stake knows how to dispute your query, an attacker could theoretically submit bad values if they have >100 TRB. This of course assumes that the honest parties would not garner support from other honest reporters or buy more TRB, but the cost is still very much dependent on the support of honest parties vs that of the attacker. For most queries supported and used by projects however, we hope to achieve consensus (>66% stake) supporting a given query so as the cost to break is the same as breaking the chain itself.
Cost to Break Implementation Contract
This attack doesn’t have an exact cost, but needs to be talked about. Since implementing an oracle isn’t a one sized fits all solution, each implementation will have its own risks, but there are some common best practices with a generic “cost to break” model.
When values are used on consumer chains, they are bridged from Tellor using a trustless light client bridge. What this means is that if the Tellor chain finalizes a block on something (like a price or value or even decides to upgrade) , the consumer chain can be alerted via a signed message (produced every block) and can react.
As part of being a good user however, you should have an ability to handle contentious forks of the Tellor chain (in case of the attacks above or a bug in the chain code or light client bridge). A good example of a mechanism to handle it is a system similar to Subjectivocracy. In this model, any user can burn a large amount of native currency to freeze the system (like 1M+ depending on the system’s needs). Once they do this, the system falls back to the social consensus of its own token holders (e.g. ETH holders). This can be done by either using a Schelling game on that system (deposit ETH into winning fork for a week and winner has the most), but a likely better/faster approach could be just using restaking and/or allowing the validators to choose. Restaking is dangerous when used often, as it can overload the social consensus layer of the base chain. In this case however, contentious forks of the Tellor chain are theoretical and only very rarely (likely never) happen. This fork selection could be considered a proper use of the consumer chain social layer and would provide a strong, game theoretic, fallback for all oracle users. If this piece is added, the oracle can secure as much as the consumer chain itself.
Cost to censor
Break finality by removing consensus
To break finality on the chain, it is half as expensive as breaking the chain itself. The reason is that ⅔ of validators need to sign off on blocks honestly for the chain to reach consensus. Therefore, if you reach > ⅓ of validators, you can essentially halt the chain from producing blocks..
The cost to get ⅓ of validators is:
CTB = .5 * ST * P
So it’s a lot cheaper than actually breaking the chain (4 times cheaper), but it faces many of the problems described in the main breaking section. Additionally, censoring attacks can be problematic for the user, but if properly implemented, the bridge contract should allow for a guardian to take control of the oracle should the chain freeze (as a best practice, this is how the Tellor token bridge is implemented; the team takes control after 21 days of inactivity).
Disputing every value that comes through (freezing out all reporters)
One option to stall a Tellor user is to simply dispute every value that comes through.
So in plain English, the cost to dispute is the base dispute Fee, but it doubles with each open dispute on that queryID. The cost to dispute a vote result also doubles each time. The max cost of the dispute is the reporter’s stake (a major dispute), but values are flagged for even minor disputes (5% of the stake). This might be a lot or it might be very little depending on who the median reporter is for the query. For a cycle list query (very large one with broad support), it is likely that this amount will be very large and since the query is supported by every reporter, you will end up losing every time the query is reported for (every few seconds for cycle list queries). This means that if there are 100 reporters with an average stake of 1000TRB, you will need to submit an average of 5%*1000TRB every time that query is submitted for.
In order to prevent this attack, submitting more frequently and having more/larger reporters support your query is essential. For most price queries, the system can be pushed to report the feed nearly every block and stakes can be increased to make the attack even more costly (the disputed reporter gets the malicious dispute fee, so they’re very happy about this attack).
This said, the cost to censor a given report for a block or two can be relatively cheap, especially for queries with limited reporters. It’s important for your protocol to know the tradeoffs and potential censorship that can happen on both the Tellor chain and consumer chain.
Filling up every block with transactions (Tellor or consumer chain)
Similar to any other chain, you can always fill up the blocks in a given chain to prevent others from getting in. Assuming an honest validator set (not done via a private mempool with a handful of parties (ahem Ethereum)), transactions are included based on the amount of gas the party is willing to pay. To prevent all other reports or dispute transactions, you would need to submit enough transactions to fill up a block and pay more than every other transaction looking to get included. This means that if 50 transactions fit in a block, you need to pay:
Max cost of other transaction in mempool * 50 per block.
Since Tellor has ~2 second block times, this means that it could be very expensive very quickly to censor the chain. Additionally, if detected, you could just up your submitted gas to a higher amount (e.g. 100 dollars) and the party would be burning TRB at a very high rate to keep the attack up.
Note that this attack holds on the consumer chain as well. If you’re on a slow chain with minimal usage, this could be more of a danger to your protocol. Also note, that if the validator set of your chain is centralized (e.g. a sequencer), they can censor your transactions at almost any time (depends on the specifics of course).
Censoring on the user side bridge contract
Censoring on the user side through the bridging contract is very dependent on the setup of the user side. Users will need to be careful that malicious forks or pauses cannot be called, even if it won’t break the contract. In the example of the Tellor bridge, the team could pause bridge withdrawals for 21 days by burning a large amount of tokens. In our case it’s limited to the team, but other set ups might not be. Attackers could censor the oracle by paying to pause, even if they know the chain is fine. Other systems that require government votes or even admin keys to settle or pause something are at risk if any user can kick this process off. As always, there’s a tradeoff between being able to react quickly to a legitimate concern versus someone being able to censor via calling this action.
Censoring on the user side – Optimistic Values
Censoring optimistic values is identical to the current Tellor. If a value is bad, anyone can dispute it. This means that if you’re waiting for a value that’s 15 minutes old, someone could dispute it at the 14th minute and force you to submit it again.
The cost per dispute is just 5% of the reporter stake of the median value. This might be a lot or it might be very little depending on the query. In order to prevent this attack, submitting more frequently and having more/larger reporters support your query is essential.
This attack would make sense if there are a limited number of reporters for a given query and the user has a longer delay for consuming the oracle data. Since reporters can submit frequently on reports for little cost, it would also be relatively trivial to prevent this attack if it was known to be happening (you’d just report as often as you could).
Conclusion
It costs a lot to break Tellor.
If you’re actually talking about getting bad values on-chain, it will likely cost you in the tens or hundreds of millions of dollars to control the Tellor chain. The Tellor network is secure for participants who use the lack of finality in the system properly, allow for disputes to settle and for proper wait time(or confirmations) between reports if the system comes under attack. The best way to protect your protocol is by acknowledging its vulnerabilities and adding processes to mitigate risks. A good design and transparent, measurable security of its own and third party components are only a few of the key items to consider.
If you need data in your smart contracts and you’re thinking about using Tellor, reach out to us and we’d be happy to discuss the pros and cons as well as the necessary steps to building a robust, high-quality data feed for your system.