Tellor Pull: A New Way To Use Tellor 

Tellor’s newest evolution (Tellor Layer) has afforded the core team the flexibility to build new ways users can integrate Tellor. While the traditional push implementation is still the default use-case, Tellor Pull introduces an added layer of efficiency, allowing the value your protocol cares about to be fetched directly upon the user interaction on a consumer-facing app. Cryptographically attested from Tellor, verified in the same transaction, and applied immediately. 

Tellor Pull does not remove the need for honest reporting on Tellor. It changes when and how that reporting becomes binding for your EVM contract: at the moment of the user call, with proofs attached.

What Tellor Pull enables

User-driven freshness. The caller brings the latest attested report and validator signatures from Tellor into the transaction. The contract does not trust a cached storage slot; it verifies attestations through Tellor’s DataBridge and then executes the logic (lend, repay, liquidate, or settle) in one atomic step.

Verification without a separate update tx. There is no standing requirement for “someone must run updateOracle() before function works.” The pull path bundles “prove this report” and “use this report” into one atomic transaction.

Tellor → EVM as a deliberate bridge. Tellor remains the source of truth for reports and validator sets. The DataBridge on your EVM chain is the trust anchor that checks signatures and policy. Tellor Pull is the pattern that connects those two layers at transaction time instead of relying on a lagging mirror in storage.

Where Tellor Pull fits best (use cases)

Tellor Pull is aimed at protocols where the oracle read must be inseparable from the state change:

• Lending and borrowing – Collateral and debt math should use the price valid when the user borrows or repays, not when a keeper last wrote storage.
• Stablecoins and pegged assets – Mint/redeem and collateral ratio checks benefit from not splitting “fetch price” and “mint” across blocks.
• Cross-chain and bridge-adjacent flows – Any flow where Tellor attestations must match EVM execution without an extra relay hop for the data itself.

If your app only needs a rough index updated once a day, push or cached reads may still be enough. If a single block of staleness can change who wins economically, Tellor Pull is the better default mental model.

Why this matters:

For builders, pull shifts oracle integration from “maintain storage freshness” to “attach proofs when the user acts.” Product flows become simpler to explain: connect wallet, pull latest acceptable report, transact. 

For auditors, the important question becomes: which report type and freshness rules does this integration enforce before submit, and do those match what the contract assumes on chain? Explicit modes and typed non-success results make that boundary easier to review than ad hoc fetches and silent fallbacks.

For users, the win is indirect but real: fewer failed txs and less dependence on invisible keeper infrastructure to make basic protocol actions work.

A push-style integration asks: “What number is in this contract slot?” Whilte Tellor Pull asks: “Can you prove this is the report Tellor attests right now—and if so, run my logic.” Same reporters, same Tellor, different usage method for your protocol.

Going deeper

For integration steps, APIs, sample contracts, and deployment notes, use the following open-source references:

• Sample Integration guide: SampleTellorUserPull (w/ end-to-end borrow example)
• Library: tellor-io/UsingTellorPull (npm usingtellorpull)
• Documentation: Tellor docs

Tellor Inc. — questions and contributions welcome on GitHub or Discord.