Cowrie Research

tellor-primary-sources-2026-05-10

4 min read

Tellor primary-source snapshot

Fetched: 2026-05-10 UTC

1) Official homepage

Source: https://tellor.io/

Selected excerpts from the site:

Tellor is the oracle layer for secure, censorship-resistant data creation and distribution.

Tellor produces data directly through the collective power of its reporters, not dependent on any single source.

Tellor allows users to define or “create” custom data types…

Tellor maintains a set of popular data feeds, known as Enshrined Feeds…

Additional signals from the source:

  • The homepage pushes Tellor as a source-of-truth layer, not just feed middleware.
  • “Enshrined Feeds” are analytically important because they reveal a public-good / governance-managed feed tier inside a broader custom-query system.
  • Tellor’s self-image is increasingly closer to an oracle-specific chain than to a narrow price-feed vendor.

2) Official docs introduction

Source: https://docs.tellor.io/tellor/readme.md

Selected excerpts from the docs:

Tellor is a Layer 1 blockchain built for the purpose of coming to consensus on any subjective data.

It is operated by an open public network of staked parties who are crypto-economically incentivized to honestly report requested data.

The number of total validators is capped at 100.

Additional signals from the source:

  • The docs state the project’s core mechanism more clearly than older “oracle” shorthand.
  • Validator count caps matter because they bound the attestation set that downstream bridges rely on.
  • The project explicitly distinguishes validators from reporters, which is useful when mapping where oracle power sits.

3) Docs answer on reporting, aggregation, disputes, validators, and cross-chain delivery

Source: https://docs.tellor.io/tellor/readme.md?ask=How%20does%20Tellor%20handle%20data%20reporting,%20aggregation,%20disputes,%20validators,%20and%20cross-chain%20delivery?

Selected excerpts from the docs answer:

Tellor uses staked reporters, validator attestations, and on-chain disputes to move data from report to cross-chain use.

As of v5.0.0, no-stake reports also exist, but they are not aggregated on chain and cannot be disputed.

For authentic Tellor data, the docs require 2/3 of validator stake power to sign the attestation.

If the validator set is stale for 21 days, the bridge guardian can reset it.

Additional signals from the source:

  • This answer is the cleanest high-level map of Tellor’s actual oracle pipeline.
  • The presence of no-stake reports means Tellor already exposes multiple trust/security tiers.
  • The guardian reset path is a critical hidden control surface for cross-chain operation.

4) Disputes and reporter governance

Source: https://docs.tellor.io/tellor/running-tellor/disputes-and-reporter-governance.md

Selected excerpts from the docs:

Any participant holding TRB on the network can initiate a dispute.

There are three dispute categories: warning, minor, and major.

There is a 48 hour voting period followed by a 24 hour Challenge period after a dispute.

Any accounts that voted may call claim-reward to receive a small reward for voting.

Additional signals from the source:

  • Reporter correctness is governed socially and economically by TRB holders, not only by automated aggregation.
  • Disputes are fee-gated, which means affordability and coordination can shape who can practically contest bad data.
  • The rewarded voting mechanism makes oracle governance itself an incentivized market.

5) Relay path to EVM chains

Source: https://docs.tellor.io/tellor/using-tellor-data/relay-data-to-evm-chains.md

Selected excerpts from the docs:

The relayer queries tellor for oracle data and their proofs and submits them to a user contract on other chains.

This command resets the validator set in the TellorDataBridge contract in the event that the last relayed validator set is over 21 days old.

This can only be run by the TellorDataBridge contract’s guardian address.

Additional signals from the source:

  • Tellor’s cross-chain delivery depends on explicit relayer and bridge operations rather than an invisible native transport layer.
  • Guardian privileges are a meaningful operational chokepoint even if the reporter/validator set is decentralized.
  • Bridge freshness and relayer maintenance are central to the actual trust model apps inherit.

6) Tellor Layer repository / tech paper landing

Sources:

Selected excerpts from the repo:

Tellor Layer is a stand alone L1 built using the cosmos sdk for the purpose of coming to consensus on any subjective data.

It works by using a network of staked parties who are crypto-economically incentivized to honestly report requested data.

Additional signals from the source:

  • The repo confirms the chain-first framing and shows Tellor’s current stack is not just smart contracts on another settlement layer.
  • The linked tech paper is the key canonical technical document for the current architecture.
  • Public ADRs alongside the paper suggest Tellor’s mechanism changes are being documented as an evolving system rather than a frozen whitepaper-only design.

Notes

  • Tellor is worth cataloging because it adds a distinct oracle comparison class: own-chain subjective-data consensus plus tokenholder dispute governance plus validator-signed bridge delivery.
  • The most important question is not simply whether Tellor is “decentralized,” but where power concentrates across reporters, validators, governance-managed feed sets, dispute financiers, relayers, and guardians.
  • Tellor is especially useful to compare against DIA, EO, and Witnet because it combines custom data requests with explicit governance and bridge-maintenance surfaces instead of hiding them behind a single oracle brand.

Graph View