Youtube link: https://www.youtube.com/watch?v=XMHvximi5rk&t=2s&ab_channel=Tellor
Project website: www.tellor.io
https://twitter.com/WeAreTellor?s=20
Discord: https://discord.com/invite/n7drGjh
https://www.reddit.com/r/TellorOfficial/
This bi-weekly call will focus on reporting-related questions and topics. In this particular call, the team went over some issues that were raised by the reporters; front-running, profitability, future updates etc.
Whole discussion
Nick: Hey everyone, welcome to the, first ever, I guess, Tellor reporter’s call. We’re going to try and do these on a bi-weekly basis. We’re just going to be recording and talking about some of the issues that reporters are facing, some of the things that you guys might want to bring up and if you wanted to hop on, we can literally walk you through setting it up. I know Owen or we already posted a video on that, but if it didn’t actually work for you guys or you have other issues, we’re happy to do it again. I guess we can kind of talk hot topics, in the reporter sphere today. So, as far as stats go, we’re up to I think as of yesterday, 73 staked reporters, which is an awesome number. Definitely gone up I think threefold since we launched Tellor X, so we have three times as many people staked with Tellor X and you can tell even in our discord, life is back in the reporter’s channel. It’s, people are coming in, they’re starting to try it out and run some software, so that’s super exciting, but as far as what are the issues currently, that we’re dealing with... as a lot of you know, people come on and they try and run it, and then sometimes they just never submit, or when they do submit, they lose money. That seems to be okay, what can we do about it? I don’t know, does anyone maybe, like MikeSr, Tally or Owen, do you guys want to explain? Why are they never submitting and this is like the frequently asked question I guess of the reporter’s channel. Why are they losing money or why do they never submit?
MikeSr: Well, I would just say that at a high level, I think that we want to try to keep it safe for people, so we have some profit calculations that are generally, maybe even would call that aggressively safe. If you use the default command line options, it might, the profit, the default profit that it’s looking for may never be achievable, so I think that’s one of the reasons why people’s reporters might never submit. That’s something that we’re working on, improving, trying to get the profitability calculations a little bit more accurate, do a little bit better reporting as you’re running the software to see what’s going on and I just encourage people if they are having issues, just to always report the command line, that you use to run the reporter. That can give us a little better idea how to help to know what you’re shooting for and help us find problems a little more.
I guess Spuddy, if you had anything to add... So, Spuddy is kind of our, he’s the person who is an active miner or an active reporter on the Tellor team. We’ve all submitted on the Tellor team, but Spuddy’s really our liaison as far as he does this for a living. How are things going? What would you say? Are kind of current issues on the network?
Spuddy: I don’t use the profitability flag. I look at etherscan, I look at the oracle contract and then I look at the gas price and after submitting a few times you get an idea for how much it’s going to cost and whenever I try to submit in profit, there’s some front-running happening, somebody else on the network is putting in a transaction at the same time, paying a little bit more gas and theirs goes in first. It doesn’t happen every single time, but everyone’s most of the time.
Nick: Yeah, so those are obviously, I think, we’re working on some fixes for it. I think we’re working on submitting via flash spots. Which is going to really solve some of those front-running issues and then MikeSr was talking about getting those profitability calculations sort of automated, so you’re not sitting there manually trying to do it.
MikeSr: But yeah, the other issue of course, where people are submitting late for a different query than was just, that can be a big loss. So, we’re working on a fix for that to try to synchronize all the reporters, so that if you do wind up submitting, you’ll have a much higher probability of getting a failed transaction, which will cost quite a bit less than a successful late transaction.
Nick: Yeah, sure. I also wrote, there’s a sample failContract, it’s called. The issue that MikeSr was talking about. So, right now if, let’s say we’re both mining on ID number one. If Spuddy and I both submit at the same time, he’s going to go through, and mine’s going to fail because we’re both submitting for ID one. Because the network sort of realizes that okay, I didn’t want to submit for that, but the next one though, if he was submitting for ID one and I was submitting for ID 10 and we both submit at the same time, if his goes through first, he gets all of the time-based reward, and mine still goes through but I don’t get any of the reward, because he just took it all. So, now I lose money because the gas isn’t, I just blew a bunch of money on the gas. I didn’t get any reward, so we’re working on a way to sync those up and make it so it doesn’t happen. I did write a sample failContract, like if you want to prevent that, one way to do it would be to just deploy a new smart contract interface and it checks whether or not any ID, so it checks the time-based reward in a smart contract and then sort of passes it over and that’s one solution that you guys can use. Or you could just wait, I think the next release of pyTelliot here should help alleviate those, maybe not prevent them completely but in most cases help alleviate that. Anything else on current miner issues?
Telly: I was thinking, would be good to discuss the realistic expectation for the frequency of winning a reward. I think considering the current state of the system, most rewards are the time-based reward that’s baked into the protocol, at least through contract funding. I think considering what, there’s like 80 reporters and you can report every 12 hours, I would say the expectation, if you came into the expectations reporter of like I’m going to win some TRB twice a day or something like that, I would even say that is like rash. I’m a reporter like many on the team are reporters as well and many community members further, so I’d say from that perspective, it’s good to be realistic about the state of where TRB is moving in the system and keep an eye on that in terms of expectations about how frequently you might win rewards. If we’re winning rewards every half-hour or something like that, we’d be millionaires, so be patient.
Nick: I think Tally pointed out, this is a competitive thing, so this is not a staking protocol, where everybody wins as we put money in. It’s a competition and people are fighting for it. So, if you come in, know you’re going to probably want to learn the Tellor system a little bit and know the game that’s being played and how to get those rewards.
Spuddy: If you’re someone watching who is new to Telor, it’s good to always stay up to date and know how to report, because things happen, like APIs go crazy. Reporters could get disputed sometime and then if you’re paying attention and you know how to report, there might be a window to something and make a profit and you know, just because it’s not there all the time, that doesn’t mean it’s never going to happen.
Nick: I think the other thing too is, knowing where Tellor’s going. So, the next network we’re going to be deploying on is Polygon and then we’re looking to deploy on Algorand, and then we’re looking to deploy on every chain out there. There’s going to be opportunities to take your TRB, go put it over on that network, stake and become a reporter and similar to Tellor X. I mean probably what the first full week the rewards were really good. For everyone. Because you were the first person over there, so I think it’s going to be similar to going over to these other networks, there’s going to be some good rewards over on these other networks and also, we’re working on setting up different payment structures. Right now, a lot of people, you would either just go through the time-based rewards, that’s the main way that reporters are getting paid, or there’s tips. On Polygon, we’re talking to people who, they just want to get to know some reporters and then they would enter into, say, a service agreement, to where you guys would be reporters for this contract, you would be required to keep the ETH/US dollar price updated say every hour and then you get streamed money every time you do that. And then that would be how a payment contract would work. Or it could look something like whoever is the first person, if you wanted to think about a way to re-do the Ample payment contract, we talked about this, you can put money into a smart contract and say, whoever is the first person to update at 7:30PM every night gets the reward. That’s a different game that’s being played now, and it might be more advantageous to you, if you’re paying attention and especially if you’re the first person to see this game get set up. Just know that there’s a lot of these sort of opportunities coming about and staying plugged in is going to be really helpful.
Spuddy: Even before Tellor X with Tellor mining. You know, there was always changes coming and if you’re paying attention and you’re up to date on how to report, when the changes happen, then you have an advantage over people who are not ready to do that stuff.
Nick: The only question we had was from Krasi on the dispute. So, this has been an issue with Tellor all along. We come into it as far as, okay, what values can be disputed and what values should be disputed? If you think about an ETH/USD feed, let’s say ETH/USD is four thousand dollars. What value can be disputed if somebody in Tellor posts 3900, is that a disputable value? Maybe. IF somebody posts it’s 3 thousand, probably. But what number can you say? Is it a 5% difference? Is it a 10% difference? Do we need hard code it into the ID? All could be potential answers. And we honestly don’t have a good solution for this. It’s really just sort of arbitrary. We had gotten into this discussion a little bit with AmpleForth. They wanted it to be within 1% of their value. Well, if you’re 1% off, sometimes just the way that the exchanges work, and the way that the timing works on the data you’re not going to be 1% off, you’re going to be 2-3% off, and that’s fine. If you’re 10-20% off, that’s a bigger issue. I’d say ultimately, it’s going to have to stay arbitrary and we’re going to want to just make sure that whenever users define what these IDs are. So, whether it’s the data queries or the Tellor feed example repos, where we’re specifying how to make these. We need to document, this is what a good value is, this is what a bad value is, these are some of the thresholds and you can also do something with consistency. So, if you would assume somebody would want to game our system like with Ample, you could place a 1% value. You could potentially make some money if you were doing 2% under every single night. If you could pull the median down, every single night and make sure that it was lower and you could constantly bet against it. You could make some money. I mean, there’s even something to say as far as, maybe you could dispute, maybe one, if it happens, once that’s cool with the disputer, but if it happens three or four times, like hey man, what are you doing? Go fix your software, it’s doing something wrong and these are just issues that we need to work on and talk about as a community because we’re really just all in this together. As far as we don’t want to report, we don’t want to dispute reporters who are trying to do it honestly, but we want to dispute reporters who are not doing it honestly. So, how you identify that in a way that’s not subjective is really hard. If you guys have thoughts, we’d love them.
Tally: I think it would be useful, if any potential users are listening, or would be listening; I would say, it would be uncomfortable for us, as makers of this market to declare for every query ID that in order, in other words, if we were to say for every query ID like this is worthy of dispute, it would be unreasonable, and incompatible with a good degree of their query IDs. Moving forward would be useful for users who request certain kinds of data, it’s useful to know what the data should be and also what the data shouldn’t be and in order to be more specific about what the data shouldn’t be. It’s useful more for them than for us to specify or to define what is worthy of dispute for the sake of what van best meet their data. Maybe others agree or disagree but that’s my thought.
Nick: I mean, you can do with some user data, like whether it’s a specific smart contract. The fairer one we’re working on or even Ample which is relatively specific, but if it’s something broad like the ETH/USD feed, where you could potentially have multiple contracts reading the same value, it can get hairy there.
Tally: Yeah, it’s definitely a good place where we’d want to be more authoritative.
Brenda: I think that’s one of the things with Tellor Flex that’s going to be useful, that each user can actually create their own governance.
Nick: Well not necessarily each user, each chain. I mean, we could have it where maybe we would want to tell users, like you have these broad-based ones of ETH/USD or if you wanted to make it a specific dispute threshold, you could say, the query ID could be like ETH/USD for my project, and it mimic ETH/USD, but we’re okay foregoing those gas savings by being able to piggyback on somebody else updating it and just update it on our own with our own rules. I think maybe you could do something like that, but...
Spuddy: I think communication is important for Tellor, like as a reporter and someone who is thinking about disputing a reporter. If you come to the community and like, hey I see this happening, I think I’m going to dispute it, it might be a good idea to talk it out first, because,
Nick: Well sometimes you get it, but they want it to be a race and you’re going to get right.
Spuddy: It is a contest, yeah. Or you know, after the fact communication could be important, like “Hey, I disputed this value. I’m not really sure if I should have, let’s talk”.
Nick: Yeah, because we have an invalid option that we can vote on, so you know, letting us know why you disputed it and things like that... It’s really important.
Spuddy: You can come and talk to the community and make a case. There’s 48 hours to do this usually, if a value is really obviously wrong, then we want that to be removed. Every time.
Nick: But we just want to talk about it if our... a lot of times it can help too, I think just we need to make better monitoring tools as far as like, is our data, is our ETH/USD price consistently 1% under what ChainLink is putting up on chain? If it is, maybe we should look at, are we calculating out correctly? And just check ourselves on that. Okay, I think that was good.
Brenda: There is a question. I don’t know if you’ve already covered this, but on the reporter side, somebody commented on the pending transactions, and then you commented on the sample quick quarter.
Nick: I think we did. Brenda’s not listening. But if you guys want any of the pyTelliot guys. Do you guys want to go over the current roadmap and what you see is kind of the next pieces of that?
Owen: Sure. Just briefly. For Telliot feed examples, which has like the command line interface for interacting with the actual interval reporter, which is what we are providing to people to report with. There’s just been a few bug fixes, some added command options, for setting the gas limit and stuff that will be in the next release and then also flashbots. So, yeah, I mean we don’t want to guarantee, like everything’s fixed now. If it uses flashbots because there can be unforeseen things that come up when we start using it. And then another thing that to note too is if you’re running it out of the box, it doesn’t have a profitability check, so if you just run it out of the box, you will lose money probably.
Nick: Should we add that in as a default do you think? Like, you have to manually turn it off. If you’re doing that. Because I feel like most people, if you’re manually turning it off, you should know what you’re doing.
Spuddy: Make the flag dash...
MikeSr: Well, the default profit could be just zero, so that it at least would try to break even.
Spuddy: It’s not going to happen, is it?
Nick: No, you guys are going to do a dash-yolo for that one.
MikeSr: One thing we want to do is get up the robustness, I guess. So, if you ever do have any cases where it crashes, so if you look in your user folder, then your home directory under Telliot, you should have some log files under there. When you interact with the blockchain, you can have lots of error conditions and we can’t necessarily test or know every single thing that could possibly happen when connecting to all these APIs and chains, so that’s helpful when you send a report. If you can send along a log file, that’ll give us a better idea of how to add these, continuously improve or increase the number of errors that we’re capturing and handling in the proper way, so that you don’t have to deal with it.
Nick: And Brenda wants to know is when you’re going to support her mac.
MikeSr: Next release. M1 processor release.
Nick: Alright, well, I think that was a great first reporter’s call, anybody else have anything we can...
Tally: Yeah, my last thought is. Well, we can’t force fairness in the system, but what we’re always trying to make fair is that the software is competitive. Relatively speaking. With things like, if pyTelliot is failing to be properly competitive, this is something that we’re trying to really keep our eye on and it’s such a subjectively defined idea to say that it might be not top of the line competitive. This is something that we really want to work on and on the other hand, on the community side requires a lot of input from community members and sort of how it works out for them. What they feel, the ways where the software fails to compete in general and make the market fair. I think I said that around that way, but yeah.
Spuddy: This is all new ground. This is all new territory, you know. There’s nowhere, there’s no other project with a system like this, that we can borrow ideas from. All the ideas are new.
Nick: Well, I mean I was thinking one thing, we could do is, structure, if we do start doing rewards over on Polygon or something and you want a tipping system, you could have. So, there are some proof of personhood protocols, or you know, you have to come to our discord and you get an NFT if you post a message as a person and then in order to be eligible for the rewards, you have to have that NFT and then you could almost add like a de-anonymize it in some ways, but then you sort of limit it from. Because part of the problem with these competition profit-based systems is that they slowly monopolize. So, like one person who’s going to get really good at using MEV and they also mine Ethereum blocks and they’re going to mine every single Tellor block. Yes, the system, I mean the Tellor system actually still works just fine as is as long as you have people verifying it. But you don’t want to try and fight it. You want to spread the wealth to spread making sure that you know... how do you incentivize people to check it? Probably the best way is to give them some rewards from it and have them also be paying it. We’re going to be experimenting with some of those ideas and if you guys have other good ideas too, happy to try them out on all these different chains. So, but thanks Tally.
Tally: Yeah, for sure.
Nick: Well, thanks everyone, we’ll post this up on YouTube and call it a day. See you.
