tellor

a community, an oracle, unstoppable

Introduction

The Tellor oracle system is a fully decentralized community focused on securely placing data on-chain.
The oracle mechanism works by using simple crypto-economic incentives to secure data through staking
and dispute mechanisms, while the community is bound by a token which utilizes anonymous
governance system and monetary incentives to reward data reporters and development of the network.

The Oracle

Tellor pushes the horizon of the oracle far past arbitrary price data. The Tellor oracle is a protocol for
answering on-chain any question of any format.

At a high level, Tellor is an oracle system where a bonded set of “reporters” answer questions on-chain
for others to use freely. To create a properly incentivized system, Tellor mints a native token, “Tributes”
(TRB). Rewards in TRB incentivize reporters to submit data using both peer-to-peer payments and
inflationary rewards. Using TRB, parties can “tip” a specific question or “query” they want updated,
then reporters can choose whether the reward for fetching the data is worth the cost of placing the value
on-chain. The security of Tellor comes through a deposit of TRB that acts as a bond or stake requirement
in order for reporters to participate in providing data. The reporters risk losing this stake if they submit
data that is successfully disputed.

Data Submission

To become a reporter, an address will deposit the specified minimum bond amount for the chain. Those
TRB are locked (they act as a bond) until the reporter requests to withdraw them. The reporter then must
wait one week before they can withdraw. For Ethereum it is 100 TRB or $1500 USD in TRB, whichever
is greater in USD value. The minimum bond amount varies by network partially based on the speed of
the chain. The minimum USD amount is implemented to provide users a minimum amount of security on
the system.

Once the reporter has submitted their deposit, a reporter can submit values for any query (e.g. ETH/USD,
Bitcoin block header information, weather data). After a reporter submits a value however, they must
wait a certain time period (a configurable variable, starting at 12 hours), before submitting again. This is
both to allow time for disputes as well as to increase the number of reporters in the system.
Reporters can choose to submit values for any ID they want, but in practice will likely pick the ID with
the highest tip. ID’s can be updated as frequently as they want. Reporters are rewarded in two ways:

● Tips
● Time-based inflationary rewards
● All bonded reporters get 2% of tips and time-based rewards

Time-based inflationary rewards are a growing amount of tokens that resets after each mining event.
These rewards start at zero and grow at a constant rate of .5 TRB per 5 minutes.
When an ID is reported, the time-based rewards go to that reporter and then the amount for the next
report restarts at zero. These rewards help ensure liveness by keeping the Tellor system going in times of
low demand and in times of higher gas prices, allowing reporters to better predict returns.

For parties needing data more frequently than when the time-based rewards are greater than the gas costs,
they can simply add tips. The Tellor oracle can therefore be as fast as needed, parties will just need to
pay for tips to cover expenses of the reporters.

The Data

Each request for data is given an ID on-chain, but specifications for the data are off-chain. Tellor uses a
method for hashing a given query’s specifications and the resulting hash is the bytes32 ID. This
flexibility allows anyone to define a data specification and have a method for parsing the data for
reporters to read.

Data (returned values from reporters) are submitted as bytes, meaning any data type or number of
variables can be pulled in a single query. An example of this type of data could be that a new request ID
could be a BTC blockheader, a simple price (e.g. ETH/USD), or even an array of prices (e.g. [ETH price,
BTC price, SPX price, VIX, EUR/USD]). The more data batching the system can provide in a query, the
more efficient the system becomes (more values per transaction).

Reporters get to select which values they submit for. Some data requests may be very vague (e.g. the
price of BTC/USD), but some may be more specific or manual (the rainfall in inches in Nairobi as
measured by one website). Community members can propose (and tip on) new queries under the guide
rails of Tellor’s data specifications. These specifications will provide clarity as to data definition for those
needing to verify the validity of the data. If reporters do not feel comfortable submitting or supporting a
certain query (e.g. if you need a paid api feed), the reporter does not have to submit for it. Parties who
wish to build reporter support for their query should follow best practices when selecting data for their
query (publish data specification on github, promote/ educate in the community), but will also need to tip
a higher amount to incentivize activity.
Disputes

Tellor data values can be used as soon as the data is placed on-chain, however the longer a user waits
once the data is submitted on chain, the more probable it is to remain, and therefore be secure; assuming
any value that remains on-chain is valid due to economic incentives to dispute invalid ones. Values are
able to be disputed and taken off-chain for the same time frame as the reporter lock (12 hours).

Any party can challenge data submissions when a value is placed on-chain (in Fig. 2, A is a good data
point and B is a bad one). A challenger must submit a dispute fee to each challenge. Once a challenge is
submitted, the potentially malicious reporter (C in Fig.2) who submitted the value is placed in a locked
state for the duration of the vote. For the next two days (E in Fig.2), the Tellor governance contract votes
on the validity of the reported value (D in Fig. 2). A proper submission is one that corresponds to a valid
query as defined off-chain in the Tellor dataSpecs1. Although a correct answer should be known to the
miners, the ambiguity (lack of an exact correctness in this case) of validity is a feature and corresponds to
“correct” being at the discretion or interpretation of the Tellor community.2

Dispute Rounds

The Tellor dispute mechanism allows for multiple rounds of disputes. After the first round, the cost of
each subsequent dispute round increases exponentially:

𝑑𝑖𝑠𝑝𝑢𝑡𝑒𝑅𝑜𝑢𝑛𝑑𝑠𝑖𝑑,𝑡−1
𝑑𝑖𝑠𝑝𝑢𝑡𝑒𝐹𝑒𝑒𝑖𝑑,𝑡,𝑟>1 = 𝑑𝑖𝑠𝑝𝑢𝑡𝑒𝐹𝑒𝑒𝑖 × 2

1
https://github.com/tellor-io/dataSpecs
2
https://medium.com/tellor/subjectivity-in-oracles-f7c3c06f69f1
Where
𝑑𝑖𝑠𝑝𝑢𝑡𝑒𝐹𝑒𝑒𝑖 is the initial dispute fee
𝑑𝑖𝑠𝑝𝑢𝑡𝑒𝑅𝑜𝑢𝑛𝑑𝑠𝑖𝑑,𝑡 is the number of dispute rounds for a specific ID and timestamp

Dispute Resolution

At the end of the voting period, and if no new round is initiated, the votes are tallied. If found guilty, the
malicious reporter’s deposit goes to the disputing party (F in Fig.2); otherwise the fee paid by the disputer
is given to the wrongly accused reporter.

Dispute Fees

The dispute fee is 10% of the bond amount.

𝑑𝑖𝑠𝑝𝑢𝑡𝑒𝐹𝑒𝑒𝑖 = 𝑏𝑜𝑛𝑑𝐴𝑚𝑜𝑢𝑛𝑡/10

Where
bondAmount is the deposit required from each reporter to be able to provide data
If multiple disputes are performed on the same ID, a party might be trying to censor values by disputing
good values. To counteract this, the dispute fee increases with each dispute on the same ID.

𝑑𝑖𝑠𝑝𝑢𝑡𝑒𝑅𝑜𝑢𝑛𝑑𝑠𝑖𝑑−1
𝑑𝑖𝑠𝑝𝑢𝑡𝑒𝐹𝑒𝑒𝑖𝑑,𝑡,𝑟=1 = 𝑚𝑖𝑛(𝑠𝑡𝑎𝑘𝑒𝐴𝑚𝑜𝑢𝑛𝑡, 𝑑𝑖𝑠𝑝𝑢𝑡𝑒𝐹𝑒𝑒𝑖 × 2 )

Where
𝑑𝑖𝑠𝑝𝑢𝑡𝑒𝐹𝑒𝑒𝑖 is the initial dispute fee
𝑑𝑖𝑠𝑝𝑢𝑡𝑒𝑅𝑜𝑢𝑛𝑑𝑠𝑖𝑑 is the number of disputes open for a specific ID

For this reason, it quickly becomes prohibitively expensive for a malicious party to simply dispute good
values to censor a contract from reading them.

Replacement Data Tipping

Once a value is disputed it is taken off chain. For users who do not wish to wait for the result of the two
day (or longer) vote, they can simply request the value again.

Invalid Data Query

Votes can be settled in one of three ways, true, false, or invalid. An invalid result means that the data is
removed from the chain, but the reporter and the disputer do not lose tokens. An example of this would
be a prediction market on who is the president the day after an election. If the election is not settled (the
winner is unknown), but the oracle places a value on-chain before the result is known, it may end up
being right, but at the time of the dispute/value submission, it isn’t. This could be a case where the
community decides to rule on the dispute as invalid. Leaving this option of ambiguity to the community
affords the Tellor system more flexibility and reduces the chances that one of two honest parties (a
disputer and a reporter) are punished.
Governance

Tellor governance is used to settle disputes. The Tellor governance system aims to balance the voting
power amongst various members of the community, specifically: holders, reporters, users and the team.
TRB stakeholders all want Tellor to continue to grow, but the approach and needs of each group can be
different. Each of these stakeholders’ categories are weighted equally. However, users and reporters can
increase their voting share within their User and Reporter category, based on their system participation.

For Tellor, there are four groups of stakeholders identified in the Tellor system:

● TRB holders
● Reporters
● Users
● Team

Within the TRB holder category, holder weights are measured as the balance of TRB on the chain where
the vote is taking place. For reporters, each submitted data point affords them additional non-transferable
voting power weighted at 1TRB per successful submission. However, reporters must be actively bonded
to be able to vote with their allocated non-transferable voting power. Users are weighted by the number
of tips they have paid into the system. The Team’s multi-sig wallet acts as a tie breaker and helps protect
the integrity of the system in the early days but can and should be forked out as the network matures
(when there are sufficient reporters, users and holders to provide checks and balances among
themselves).

It is important to note that Tellor can be deployed on multiple chains. Although the main Tellor token is
staying on the Ethereum network, users or the Tellor team can launch Tellor on any-chain. However, the
governance(dispute resolution) of that specific chain would be controlled by the stakeholders on that
chain and inflationary time-based rewards only exist on Ethereum.

Monetary Policy

Tellor utilizes a fixed minting policy to incentivize reporters through time-based rewards and protocol
improvements and maintenance. This can only be changed through a fork.

Security

Security is achieved through Tellor’s architecture, which uses a simple bond/dispute mechanism to source
correct values. Ultimate ownership and security in the system is afforded by our governance contract,
which we aim to align incentives from holders, reporters, users and the team.
There are two primary metrics used when determining the security of an oracle:

● How can a bad value get put on-chain? (e.g. BTC/USD is 10M)
● How much does it cost to censor the oracle? (no good values can get through)
For the former, this is the cost to break the governance contract of Tellor. If we assume that a bad value
will get caught (not go through unnoticed), then the bad value would go to a dispute. For the value to be
put back on-chain, the vote would need to settle such that an incorrect value is deemed correct. With
multiple rounds of voting, the malicious party would need to get to the point where they have 51% of the
voting power in the system and for this they would have to take over three of four equally weighted
governance stakeholders (holders, users, reporters, and the team).

Since the governance contract is only partially based on the token weight (token weighted TRB holders,
reporters, users), there are other factors at play.

Where VS = voting shares

VS = total supply + reporter votes + user(tipping) votes + team

Each stakeholder group is equally weighted. The outcome of each dispute vote can be true(for),
false(against), or invalid. The percentage of votes for each outcome within each group is calculated
against the total votes received per stakeholder group and then evaluated to determine the vote verdict.

𝑡𝑟𝑏𝐻𝑜𝑙𝑑𝑒𝑟𝑠𝑜𝑢𝑡𝑐𝑜𝑚𝑒 𝑟𝑒𝑝𝑜𝑟𝑡𝑒𝑟𝑜𝑢𝑡𝑐𝑜𝑚𝑒 𝑢𝑠𝑒𝑟𝑜𝑢𝑡𝑐𝑜𝑚𝑒 𝑡𝑒𝑎𝑚𝑜𝑢𝑡𝑐𝑜𝑚𝑒

𝑊𝑒𝑖𝑔ℎ𝑡𝑒𝑑𝑉𝑜𝑡𝑒𝑜𝑢𝑡𝑜𝑐𝑜𝑚𝑒 = + + +
∑𝑡𝑟𝑏𝐻𝑜𝑙𝑑𝑒𝑟 ∑𝑟𝑒𝑝𝑜𝑟𝑡𝑒𝑟 ∑𝑢𝑠𝑒𝑟 ∑𝑡𝑒𝑎𝑚

Where
outcome is true, false and invalid

After each WeightedVote is calculated for the possible outcomes, they are evaluated to determine the
dispute outcome such that the final verdict is that which is greater than invalid and the other outcome.

If 𝑊𝑒𝑖𝑔𝑡ℎ𝑒𝑑𝑉𝑜𝑡𝑒𝑓𝑜𝑟 > 𝑊𝑒𝑖𝑔ℎ𝑡𝑒𝑑𝑉𝑜𝑡𝑒𝑎𝑔𝑎𝑖𝑛𝑠𝑡 + 𝑊𝑒𝑖𝑔ℎ𝑡𝑒𝑑𝑉𝑜𝑡𝑒𝑖𝑛𝑣𝑎𝑙𝑖𝑑 => 𝑃𝑎𝑠𝑠𝑒𝑑(𝑡𝑟𝑢𝑒)

If 𝑊𝑒𝑖𝑔𝑡ℎ𝑒𝑑𝑉𝑜𝑡𝑒𝑎𝑔𝑎𝑖𝑛𝑠𝑡 > 𝑊𝑒𝑖𝑔ℎ𝑡𝑒𝑑𝑉𝑜𝑡𝑒𝑓𝑜𝑟 + 𝑊𝑒𝑖𝑔ℎ𝑡𝑒𝑑𝑉𝑜𝑡𝑒𝑖𝑛𝑣𝑎𝑙𝑖𝑑 => 𝐹𝑎𝑖𝑙𝑒𝑑(false)
Otherwise, the dispute is considered invalid.

If the system is newly deployed, there will be minimal reporter and user votes. Without the equal
weighting among categories, the system would be a straight token weighted vote, with the cost to get
51% simply being 51% of the market cap or 51%. With equal weighting among stakeholders an attacker
would need 51% of the market cap, tip once and report once.

In a system with reporter and user(tipper) votes, the attack vectors are different. The total number of
reporter votes in the system is the count of all historical mining events among actively bonded reporters.
At a rate of one mining event per minute (a very fast chain), this would indicate 525,000 reporter votes
given each year. With a current supply of around 2M TRB and about 1/10 that many mining events, this
makes even a best-case scenario for the attacker prohibitively expensive to carry out in any manner that is
not a multi-year attack. Since other chains are faster and cheaper than Ethereum, this governance
parameter could be more easily controlled when Tellor is recently deployed to a new chain.
To break the system via tipping, the malicious attacker could recycle the tips so as not to drain liquidity
and increase the price. However, they would have to also take over two more stakeholder groups to be
successful.

Overall, the cost to get a bad value on-chain is prohibitively high. Unless a party was breaking Tellor just
for the fun of it, the much cheaper option is to simply censor Tellor for a certain period of time, as most
use cases require some finality in the oracle (they will not wait for the entire Tellor system to settle a bad
value dispute).

Since any value that is disputed will be put to a vote by all stakeholders the simple cost to censor is:

Cost of a stakeblock time of underlying system (since Tellor is as fast the underlying system)

As long as this value is higher than the cost to 51% attack a given chain (e.g. on Ethereum, to
censor transactions at the miner level), Tellor should be considered a censorship resistant oracle for
use on that network. With current costs at a 100 TRB bond requirement or $1500 and a $15 price,
if you assume even 10 second block times on Ethereum, the minimum cost to break is(it increases
as the price of TRB increases):

100 TRB bond × $15/TRB × (6×60) = ~$540,000/ hr

The cost to censor via disputes is:

Cost to dispute = disputeFee * 2^ blocks per period

Therefore the cost to dispute for even 10 minutes on a 30 second block chain (assuming the
minimum 10 TRB cost at a $50 price):

10 TRB bond × $15/TRB × 2^2×10 = ~$157M

Looking at our formula, we can summarize that security increases when:

- The share of those voting increases

- The price of the token increases

Additionally, a minimum threshold of reporters is also essential to the proper functioning of the Tellor
system. The more parties that are available to submit data, the more decentralized our reporter set will be.
An active and watchful community is also one of the big missing pieces in many protocols. Just because
you are “theoretically” secure if there is an arbitrage opportunity, defi has seen many protocols exploited
because those opportunities are left unfilled. It is the job of the Tellor ecosystem to properly incentivize
and monitor the activity to make sure active diligence is being performed.

Use Cases
The new Tellor system, with its expansion to arbitrary data types, works as an oracle for any piece of
off-chain information. The specific structure of Tellor, with its lack of finality and ambiguously defined
data points make it a unique oracle and one that is not fit for high speed values needing instant accuracy
or trusted endpoints that are not open to any reporter.

That said, there are still a number of use cases that Tellor works well for and we look forward to
expanding our user base and our community around these and even more creative use cases:

- Price feeds (e.g. BTC/USD TWAP)

- Prediction Markets (e.g. who is the current president of the United States?)
- Bridging assets (e.g. bring BTC block headers onto Ethereum) - L2 Security (data availability,
sequencer validation)

Contact

If you are interested in using Tellor, please reach out to us at info@tellor.io.