Proposal to Add Tellor as an Oracle (part deux)

Greetings AMPL governance community, Tellor team here again, reaching out with an update on your feedback and hopefully making a good case to include us in the oracle!

This post summarizes ACCP-4 30, a proposal to add Tellor as an additional oracle to the Ampleforth system, and focuses on the reasoning behind it. Please refer to the actual proposal for more details.


The goal of adding Tellor is to further decentralize the protocol and create a more robust, censorship-resistant price feed. Tellor is a decentralized oracle that uses a network of staked miners who compete to fetch off-chain data and place it on-chain.


We propose that Ampleforth will use Tellor to bring on two values: the AMPL/USD value and the US Personal Consumption Expenditures (a key measure of inflation). The values will be medianized with the current price feeds provided by Chainlink and the Ampleforth team.


In order for AMPL to do its daily “rebase,” it requires a price of AMPL/USD on-chain so that the protocol knows how to adjust the supply. It doesn’t peg directly to the dollar, but rather an inflation-adjusted dollar. Using the US Personal Consumption Expenditures Price Index, it can track the value of the US dollar versus costs. This means that AMPL will still hold a stable value versus goods and services, even if the US dollar collapses in value. There is no reliance on traditional banks or lenders of last resort to guarantee liquidity.

As an oracle that specializes in decentralization and censorship-resistance, we believe adding Tellor into the system greatly helps Ampleforth’s own efforts of decentralization and adds further security and robustness to the price feed.

Additionally, AMPL currently relies on only two feeds (the AMPL team’s feed and LINK). Since, there is currently just an average taken of the two, any one oracle provider can maliciously attack the system. By adding a third oracle, the AMPL system will be able to take a median of the three values, meaning that you would need 2 of the 3 oracles to be corrupted in order to break the system.


In order for the Ampleforth community to fulfill their vision as a decentralized financial primitive, the censorship resistance of the protocol must be the first and foremost priority. The communities of Tellor and Ampleforth have similar drives towards and beliefs as to what constitutes a decentralized protocol and the ability of the two projects to work together will help further the entire space.

Tellor’s system is a completely on-chain data feed that can be accessed by Ampleforth smart contracts. The design for integrating Tellor into Ampleforth includes creating an adaptor that pulls values from Tellor and pushes them to Ampleforth’s oracle medianizer, and configuring this adaptor as a new provider in the medianizer.

Tellor added the AMPL/USD price calculation in mid 2020 and has been updating it since and they have also created scripts for automating the price updates before they are needed by the AMPL system. More recently (summer of ‘21), we have been working directly with the AMPL team to ensure good data quality of the AMPL prices pushed on-chain. Over the past few weeks, the Tellor feed has been closer to AMPL’s than LINK and is done in a completely open source and censorship-resistant manner.

5 Likes doesnt have an ssl certificate. That should be renewed. Otherwise adding additional oracles is always great


It does make sense to add multiple oracles. The reason is simple; you make projects more decentralized by having more nodes, more participants, which is the case with price feed as well, but in this case participants are oracles. This way we are actually making a more abstract decentralization, with multiple levels. I like the idea!

As for Tellor itself, it’s completely decentralized, and with Tellor X at our doors, lowering the entry price, it will further increase the potential number of validators.


Absolutely makes sense to add Tellor as another oracle. They are far more decentralized than Chainlink is as well. Don’t get me wrong. I love chainlink, just stating a fact about Tellor being much more decentralized. I’m ecstatic to see TellorX is in audit. While auditing slows the launch, I 1000% agree that it is a necessary step & I believe it will produce tangible concerns & actionable steps to code that can be addressed before it goes live. I also believe Tellor’s philosophy’s as a project align very well with the Ampleforth communities philosophies. Lastly, I believe the integration of Tellor to Ampleforth would be great for both protocols.


Hey everyone, thought I’d share what I know about Tellor and my perspective.

It’s a relatively simple premise - a decentralised oracle where agents are incentivised to promptly supply accurate data - but when examined in detail there’s a lot to cover, and despite how it looks the following is a short overview.

Before I get into it I’d like to cover a couple more things. Back around May earlier this year when the initial proposal was raised I had several concerns and argued against the integration. In that time the project has announced TellorX, which is a substantial upgrade to how it works. As such I’ll outline how Tellor works currently, what my concerns with that are, how TellorX affects that, and what impact that has on my concerns.

How Tellor works

At the heart of Tellor are the “miners”. Anyone can be a miner, and they do so anonymously. Miners are responsible for putting data onto the blockchain.

The following is a rough breakdown of the system with a few more numbers attached. It doesn’t cover every last detail, and it’s written from memory so please correct me if any numbers or described mechanics are wrong. For reference, 1 TRB (Tellor’s token) is worth ~50 USD. Anyone interested in a more accurate and more detailed breakdown can read the whitepaper documentation.

  • Miners put up 500 TRB as a “stake”
  • Miners perform Proof of Work calculations (PoW), when they solve the challenge they are then eligible to submit a new data feed value. In exchange they earn TRB for doing this successfully
  • The PoW is to add Sybil resistance to value submission - a miner can try to submit two values, but then they need to split their PoW power and thus reduce their chances of success accordingly
  • Miners are capable of submitting wrong values, these values are capable of being considered the true value by the oracle contract
  • To prevent this, submitted values are open to be disputed by anyone for a short time. A disputer puts up 400 TRB as their “stake”
  • The outcome of the dispute is determined by any interested TRB holders voting on the issue. The amount of TRB a voter had during the block the value was stored on-chain dictates their vote power
  • If the miner wins, they keep their stake and collect the disputer’s stake. If the disputer wins they keep their stake, and get the miner’s stake
  • Votes can be disputed too, with a mechanism that goes through a series of escalations that requires greater participation to conclude the vote rounds
  • The feed’s value is actually comprised of the median of 5 values submitted by different miners
  • There are a fixed number of feeds that can be mined per “tellor block”, and which ones are picked is determined by which feeds were last “tipped”
  • Tipping a feed consists of paying TRB to make that feed higher priority, and the tip itself is dispersed as bonus rewards to the miners


1. Observed miner behaviour deviates from financial incentive mechanism

Miners have demonstrated on several occasions a lack of care with the data they submit. Whilst you would think the threat of losing 500TRB for getting it wrong would act as a proper incentive to get it right that has not always translated into reality. The most recent incident saw miners warned in the discord server that for a specific feed the default configuration they use relies on an API that is returning out of date data, as evidenced by the timestamp included in the API response. Two days later several miners lost their stake because they continued to report objectively wrong values for this feed.

This issue is partially compounded by the mining software including the aforementioned default configuration. It was intended to serve as an example, and as such usually has only a single source API for each feed - something that means that there can’t be any error detection done. Unfortunately many miners do not customise their setup, instead relying on this default configuration and thus falling foul to any naturally occurring issues with the APIs it specifies.

2. Miners incentivised to protect stake rather than pursue true feed value

For the disputes miners are more likely to act to secure their stake than to accurately judge the values based on their merit. The Tellor team’s large multisig wallet has been required to enforce correct arbitration of disputes on some occasions. This issue is again exacerbated by the use of the default configuration mentioned above, as it means multiple miners report the wrong values and look at one another and assume they’re correct since other miners agree with them.

3. 51% of TRB supply attack

Controlling half the TRB supply allows for the submission of false data. Tellor has argued that it is cheaper to censor the oracle by attacking Ethereum network directly rather than trying to compromise Tellor, however this hinges in part on the premise that malicious data submissions are always stopped at the dispute level. My counterargument is that smaller users will not be prepared to risk losing their dispute stake by trying to win a vote when their opponent visibly has more TRB than them by a large margin. An attacker can also split their large TRB holdings across multiple wallets to give the impression that multiple users agree with their malicious submission being valid and partially disguise the nature of their attack. User participation is also always low for disputes - some TRB will be locked up in staking pools, etc, and other users will simply not pay attention, meaning it is likely far less than 51% of the TRB supply is required for an attack.

4. PoW reduces miner quality

PoW is a needless burden, it just makes it harder for less wealthy users to participate in the core of the project. The Sybil resistance that the PoW adds is ultimately unnecessary, as a determined attacker could simply scale up their mining power at the current levels of competition.

In a similar vein the 500 TRB stake is also high and acts as a barrier to entry. This value was more reasonable when first implemented as TRB had far lower market value at that time.

5. The “tellor block” system doesn’t scale

The limited number of feeds per “tellor block” means poor scalability if Tellor were to significantly grow the number of projects dependent on it, with those projects competing at high tipping bids. Whilst this has a positive impact on the value of TRB, it comes at a cost to the downstream projects themselves, and ultimately some might decide it’s prohibitively expensive and use an alternate oracle. Tellor’s security mechanisms work best at scale, so this isn’t ideal from that perspective either.

How TellorX changes how Tellor works

As before this will be a rough synopsis of what I consider the more pertinent aspects of the TellorX upgrade. For more information I recommend reading the whitepaper.

  • Removes PoW entirely, now submitting values is a gas race. Flashbots will surely play a pivotal role. The term “miner” has consequently changed to “reporter”
  • Reporter stake reduced to 100 TRB
  • Dispute mechanism largely the same, but the TRB used to tip a feed grants the tipper some vote power on any disputes that arise (and I think the ability to raise a dispute too)
  • No limit on how many feeds can be reported at any given time
  • Reported data structure moved from numbers to arbitrary byte arrays to permit greater flexibility on how the feeds work


The following explains how my concerns about Tellor are impacted by the changes TellorX makes:

1. Observed miner behaviour deviates from financial incentive mechanism

Tipping granting a modicum of dispute power is likely to help keep third parties engaged with validating the data feeds. Indeed, simply having dependent projects that use feeds around will help as the incidents with bad data have been for feeds that aren’t actively used by other projects. Without going into too much detail, TellorX also made reporting for a given feed “more optional” which means it’s easier for a reporter to avoid reporting for a feed they have doubts about. This too will likely improve miner behaviour.

2. Miners incentivised to protect stake rather than pursue true feed value

Miners forming a cabal to vote together and protect their self interest becomes less viable the more there are, and with the reduced barrier of entry to reporting I would expect to see improvements here too. The other aspects discussed just above also help.

3. 51% of TRB supply attack

The specifics of the TellorX changes have little to do with this, as it can really only be mitigated by growing the marketcap of Tellor as a whole. That said, I think that the improvements that TellorX bring are a step towards growing the project and thus help somewhat in this regard.

4. PoW reduces miner quality

Since TellorX removes the PoW requirement this is no longer a concern.

It will however be interesting to see how reporters react to the gas race / gas bidding instead though. In theory reporters will only bid up to the point of profitability, and thus all have an even chance of success. We might however see deeper pockets attempt to report at a loss for a period to convince other reporters through their sustained lack of success that it isn’t worth bothering with, only to then substantially reduce their gas expenditure after having driven these competitors away. It only takes another user to spot that the cost of competing is low again for competition to resume again though…

5. The “tellor block” system doesn’t scale

Since TellorX removes the limit on how many feeds can be reported at once this is no longer a concern.

Further thoughts

With regard to concern #3 there is one potential way of handling it that’s been raised by various people over the years. Another project by the name of Kleros aims to provide decentralised arbitration as a service - that is to say, a trustless way of having decentralised and anonymous jurors decide on the verdict of a case. Tellor could potentially use such a service to rule on contentious votes, and in doing so would make compromising the outcome harder than simply owning the greater share of the TRB supply. With this as a fall-back for disputes users would have greater confidence in their ability to win provided they are right in challenging a value, and so this would likely have a positive impact on disputes even before they escalate.

The Tellor team have been receptive to this suggestion, but obviously it is a major change and so requires a lot of thought before deciding on it. Something to keep an eye on down the line perhaps.

Another concern raised during the first proposal was feed data quality, and another AMPLer by the name of Duck produced some analysis that indicated the feed suffered from significantly higher variance compared to the two existing oracles than those two compared against one another. In the time since then there has been extensive work to improve Tellor’s AMPL feed and it should in theory now report more in line with the other oracles based on results provided by the Tellor team.
(Unfortunately time is a scarce resource, and Duck has not yet had the opportunity to produce fresh analysis with the new data)


As mentioned in the proposal, AMPL currently relies on two oracles to supply it with the data it needs for calculating the rebase. It takes the median of the supplied data, but with only two values that median becomes the mean, and thus if either oracle feed is wrong it has a direct impact on the value used. Adding a third oracle remedies this, making it such that one oracle submitting an outlier has no impact on the value used which now becomes the middle discrete value.

On top of that, Tellor is an especially good fit for a third oracle as its structure differs greatly from the existing ones. This means that if any of them break (and given enough time it becomes a matter of when, rather than if) it is likely that they break in different ways and thus at different times, allowing for the overall continued smooth operation of AMPL itself.

Whilst my concerns still apply to the version of Tellor currently live, there are a number of significant improvements in the pipeline. TellorX is moving along and I believe is anticipated to go live towards the end of November. As described above, even after TellorX goes live some of my concerns persist, but realistically speaking it is both highly unlikely that someone will bother to attack AMPL via the oracles at this point in time or that they will be able to affect not just Tellor but also the second oracle required for an attack to actually have an effect. It is also wholly possible to use governance to undo the integration if AMPLers feel it is appropriate to do so at a later date, so we can afford to be a little more bold here and now.

All in all I’m in favour of proceeding with the integration.


Updated AMPL comparison

1 Like

I don’t know where you are getting your data from but it doesn’t align with the on-chain data (see below). Where did you source that from?

Here is the recent on-chain data (thanks to ImagineBeingAtComputers#0001 on discord for scraping it) of the three oracles reporting a 24 hr VWAP.

In this chart I simulated what an actual rebase feed from Tellor would look like by choosing the on-chain data points closest to the AMPL oracle report.

This graph represents the variance of each oracle with respect to the AMPL oracle for each simulated rebase.

You’ll notice that the Chainlink oracle didn’t provide data for a good chunk of time recently. I’m still not clear on why this is. The Tellor data appears to lag significantly behind both other oracles. Given the extreme variance this could cause in an AMPL rebase if one of the others fails to report, I recommend against proceeding with Tellor integration until they either fix the lag or -as Mandalore suggested on discord- set up a recurring tip around the same time as the AMPL and Chainlink oracles report to prove that their data isn’t actually lagging and it’s just not being tipped at the right time. If anyone wants the source data I posted a CSV in the governance channel of the Discord.


Hi all,

I’ve occasionally posted on the Discord and formed my opinion from the discussion there and on this forum. I would advise anyone coming to this post to read Fiddlekins’s summary in this thread. I believe that it’s accurate and reflects my impressions.

Overall, I’m persuaded that the state of oracles in AMPL needs improvement. For example, as Duck proposed, a Keeper to call the Chainlink oracle or a look under the hood of the AMPL oracle. Although the AMPL team are, at now, the people with the most at stake in AMPL, they’re still human. For the dangers of this, look at Tellor’s attempt at a derivatives platfrom or wrench attacks more generally.

However, I’m opposed to a Tellor integration at this current time.

Current faults with Tellor. Although this isn’t a complete list, there’s the possibility of self-disputing, which allows an attacker to reclaim their stake if their attack fails, the current centralisation of Tellor miners and the fact that Binance controls 35% of the Tellor supply. Although these problems are solvable, the Tellor team haven’t publicly acknowledged these problems and moved to meaningfully solve them. Although they did deploy a parachute function to break up any ETH wallet which holds =>51% of the Tellor supply, this is trivial to defeat with two wallets which contain 25.5% of the Tellor supply. The Tellor team have also improved the quality of their data feeds relative to the AMPL native oracle. From Ducc’s recent post, there appear to still be faults with the data.

Future faults with Tellor. When Tellor was launched, it would have been impossible to predict these current problems. Now that Tellor has been used in the wild, exploits have been found and some of them have been patched. Over enough time, eventually I would come around to supporting an integration with Tellor as all the faults were solved.
However, Tellor is updating to an entirely new model called TellorX. Fiddlekins has speculated about the possible use of Flashbots but that’s been a sentence. There has been no serious attempt, both with Tellor in it’s current state or TellorX to wargame an attack. If Tellor is integrated with AMPL and then moves to TellorX, the AMPL ecosystem will be the bug bounty for TellorX.

It’s obvious from the PRL projects that they believe AMPL’s current state is good enough to build some extremely impressive projects and I agree with their assessment. I think that it’s fair to describe AMPL as a potential USD-killer. I admire the mission and dedication of the Tellor community. I just don’t think that AMPL is an appropriate testing ground for their products. With a couple of years of battle-testing and integrations, as Chainlink had to do before integrating with AMPL, I would be a lot more receptive.

tl;dr - get more experience but in principle, yes

Afterthought: If the Tellor team could return to Daxia and Daxia saw wide use, I’d take that as sufficient credentials for Tellor.


Hey @tsar_impersonator , thanks for the post! I think you make some good points, but to just clarify the things about Tellor:

  • self-disputing isn’t guaranteed (it’s a race, so assuming you want to attack AMPL around the rebase, you’d have to hope no one slashes you for a couple hours, so not likely).
  • On the tokens. CEX’s do suck. This is a common problem with any coin and we’re trying to address some of it with TellorX (giving some users/reporters more say), but yeah, if Binance wants to attack Tellor it would be hard. In our own defence, other coins are usually this high held by the team (cough LINK), and more so if CEX’s in general want to fuck us all over it’s probably a doomsday scenario for anything not completely decentralized (which Tellor definitely is a notch up in that category from the other two guys).
    -And on MEV, it’s actually part of the design! Wrote an article here about how it’s inevitable in oracles: So same as arb bots for AMPL, you should try and get the miners on board in my mind!

But I can tell you took some time to think about it, and respect the criticism that we just need more testing. It’s a hard one to ever respond to or in space ever quite get enough of. We’ve been pushing values on chain since Aug ‘19 and there have been hiccups, but it’s getting more robust each day and that’ s all we can continue to do. From a fan of AMPL though, the current design is basically beholden to two separate parties (either one could really mess up the rebase if they attacked it) and you guys would be better adding the number 1 as a third oracle for a median vs the current design. Tellor adds some nice characteristics of decentralization that the other two don’t have, so it works well.

And lastly…man can’t you believe remember Daxia! Awesome to hear and unlikely given our team’s current workload, but maybe in the future!


Hey @ducc , just responding here in the more formal forum about the lag issue and also what you had mentioned in Discord about whether or not we would be able to set up keeper for pushing the data. So on the lag, it was actually a great find and we weren’t really watching it (we are now). But some people pointed out to us that the bnc api updated on a lag. So some of our reporters we’re pushing values before the update. Then, since Tellor takes a median of 5, if you get 3 submission at 00:00 UTC and then 2 at 00:30 UTC w/ the updated values, we were technically in the next day, but the values weren’t updated. Long story short, we’re making sure we mine the correct value and are even using some miners of our own to show that the data works. For the other piece, we can definitely set up a keeper, but we’ll probably just run it ourselves for the time being. In the future, it’s sort of centralized if it’s dependent on us, but we’d want those pieces to come from the AMPL community and not the Tellor team if that makes sense. We’re a system that works even if the team dies and cuts all contact, so making sure you guys can still operate it and keep the values up to date is important. I think longer run, I’d love to see AMPL update the way the oracle works so there’s not as many calls or dependencies on human action, but that’s for another thread.


It’s great you seem to have figured out what the problem is, and thanks for following up on my suggestion. Let me know when the keeper goes live so I can use that as a reference point in my future update (maybe a couple weeks after the keeper starts tipping?) so we can compare before and after.


Hey all,

Glad to see such constructive and detailed discussion.

From my perspective adding more Oracle sources increases the resilience to the system and decreases sensitivity to any particular Oracle source. The AMPL median Oracle was designed to use multiple sources for robustness. Hence I support adding tellor as a third source to the existing two oracle source Ampleforth’s custom oracle and Chainlink’s.

The last time a value can be submitted and be considered for the day’s rebase is 1 am UTC and rebase happens at 2 am UTC. That one hour window is meant for purging values after manual review. Which in Tellor’s case would be triggered by a value dispute on Tellor’s side. The 1 hour review window and Tellor’s dispute mechanism should make adding Tellor as an oracle source a low risk. While providing the added benefit to robustness from one more Oracle source.

It will be exciting to see this go through Ampleforth’s governance process, especially being the first proposal!


Just kicked off a snapshot vote! Spread the word around and get your forth ready!


Hey All,

I made an account on this forum just to contribute to this - because it seems several things are off here.

To be crystal clear - I am absolutely in favour of adding oracles, as that’s what’s healthiest for the protocol long term. But the way this is being approached is glaring with red flags.

I think the most important values we must return to with AMPL - is care, cautiousness, and deliberation when taking taking action. It is these values from the AMPL dev team that’s allowed AMPL to be a successful experiment thus far.

I do not see much of that care, cautiousness, and deliberateness in this proposal.

1) There’s zero detail I could find about implementation timeline and what alternatives were considered.

The proposal implies that we should just switch from a median of the 2 sources, immediately to a median of 3 sources. Why not a ramp as a function of time that allows AMPL to gradually ease in the data feed from Tellor? What about different parameters for that ramp function? Maybe it’s a ramp function combined with a step function? For something that’s supposedly been being worked on for a year, it seems like these are obvious things that would have and should have been considered if we want to preserve the health of AMPL.

2) There are unanswered technical concerns.

I’m not going to re-hash things that have already been said - but it seems like there’s still several open technical questions from the things raised above by @Fiddlekins @tsar_impersonator and ducc . Despite this, it appears the Tellor team went ahead to take a snapshot without fully addressing all of these concerns.

We need to understand that Ampl is just starting to enter it’s utility phase, we have a lot of interesting applications coming out that everyone is excited about. ANY CHANGE TO THE PROTOCOL AT THIS TIME ADDS ADDITIONAL RISK. Again, I am not against improvements, especially oracles. But if we are going to change anything with the protocol, we need to understand the risks and address all of them.

3) The signal snapshot doesn’t even contain an abstain option per the recommended guidelines.

I’m not sure if this was intentional or not, but I have not found a reasoning for it anywhere. The Tellor team has also largely been absent from the Discord and Telegram communities, although I understand they are coming to office hours/Amplitheater today. I’ve seen mentions of the Tellor proposal in the Discord here and there, but not enough discussion if at all. I don’t think this is problem of community either - because I’ve seen the community discuss the kAmpl news and announcements with more detail (granted those are not as large as impact to the protocol).

None of the above is meant to attack the Tellor team, and I hope it’s not perceived that way. I love the initiative they’re taking here to add an oracle; it’s certainly something we need. But it needs to be done in the correct way. The same way AMPL dev team is making sure to have all of our ducks in a row before proposing to add AMPL onto Aave as collateral. We should expect the same from teams wanting to change our own protocol.

I’m hoping the Tellor team can address these concerns, in additional to the technical concerns raised above during today’s Amplitheater.

1 Like

Hey G-Yes95,

Thanks for taking the time to review the proposal I’m trying to address your three main points below:

-1 The proposal is to switch from two sources to three for the median. We have been working with AMPL for a year on data quality and sources. The inclusion of Tellor in their data feed increases the decentralization and security of the oracle. Anyone can be a Tellor data reporter so long as they put up a bond that can be slashed if they provide bad data and the data feed can be further (the base incentivization comes via inflationary rewards) incentivized with tips even during periods when high gas prices are observed, this guarantees liveness. Attacking two of three oracles is more technically and financially challenging so adding a decentralized oracle increases overall security of AMPL, which actually preserves the long term health of AMPL.

-2 We’ll be at the Amplitheater. But on your point, AMPL has a way to exclude data from any of their oracles and although the risk is there for all of their oracles, the security that is gained by adding a data feed outweighs the risk because they have a process to fall back to with any data feed. I think it is a great way to mitigate risk of an oracle attack or lack of liveness of resources(API).

-3 Super sorry! We ran the proposal by the team and asked a few people, but just missed that part. And yeah on the discord/ telegram stuff, we’ve definitely been in there, although maybe not the top posters. It’s a hard balance to both answer questions and then also not drown out any voices/ discussions you guys have since the chats can move quickly. But always feel free to @ us if you want a direct response!

Thanks so much! And yeah we’ll be at the Amplitheater and we can’t wait to talk about it. We’ve loved working the team and the community and we’re excited to get through and work on making the oracle system even better in the future.


Thanks Brenda! Appreciate your reply and for joining the Amplitheater.

I think an overall lesson learned is that with both protocols moving to DAO-like structures, it will be hyper-critical for both communities to do a better job at sharing all pertinent information in an aggregated and thorough format and thru open channels, similar to Fiddlekins post in this thread or even a recorded call between both communities. People have mentioned transparency concerns, but having taken time to look through everything now, it doesn’t seem like that was the case. It seems like this was a case of information & data being dispersed all about, sometimes between individual parties; making it appear as though there were transparency concerns. Again, it’s a community driven responsibility to improve this moving forward. This is especially important for the new-comers that we want to stick around after the party, as Evan mentioned today.

Anyhow, excited to see how Tellor integrates with Ampl moving forward! :facepunch:


Hey guys! Just a heads up, we’ve been talking with the team and we were going to deploy the mainnet Tellor adapter and propose a vote on-chain tomorrow if that works! Let us know if not, but since the snapshot was a) unanimous and b) dominated by a few big players we figured that most people would just leave the vote to them and save their gas. Looking forward to working for you guys and seeing this decentralize upgrade go through!


So final warning for everyone! Kicking off the mainnet vote on Monday!
The contracts on mainnet:
AMPL/USD feed: 0xf5b7562791114fB1A8838A9E8025de4b7627Aa79
USPCE feed: 0x13853a11Bd9539C15758823902A9421bE9887C53

Looking forward to seeing you guys vote and definitely let us know if we can help you with any information