Youtube links: https://www.youtube.com/watch?v=ISBrcVTMQ7g
Official links: https://linktr.ee/Tellor
Nick: Welcome everyone, Tellor360. This is what basically we're going to talk about the next version of Tellor. We've done upgrades basically every year; we've had a year and a month later Tellor v2, then a year and a month later we had teller X. I think so, we're actually thinking about what's the next one going to be, you know, this actually fits with the timeline even though it's like only April, usually we brainstorm it then, do audits then have to build it, lots and lots of testing, make sure everything's good because these are usually bigger upgrades. That said I don't think this is actually going to be as big of one or as big of a build, so it should be a hell of a lot easier. Now just thinking like okay so what's the state of Tellor versus one year ago. Whenever we were making these upgrades basically the price is way down. That sucks but you know we're following the whole crypto market, all the alts are down, it's just kind of a rough period, but still, what's the big bottleneck for Tellor? It's getting actual users. This is kind of a big bottleneck for a lot of people in the space but it's still... but a year ago we have more users than we did a year ago, we have way more potential users than we did a year ago. I mean we have people coming in every day at least trying to use Tellor and coming and talking to us about using Tellor. We have to sort of start pushing them over the finish line. Obviously, a lot of it doesn't have to do with us, it has to do with whether or not they're serious about getting their code through the door but what can we do to make them successful and getting them across the door that's what we have to think about when we're making these changes to Tellor. How can it actually lead to more usage, more usage will sort of drive kind of the whole product demand, the whole community everything will come from and that's always been our theory you know, we want to lead by actual usage. The other things that we should think about a lot of, this has to go down to like the vision of Tellor, you know, from day one we've always been decentralization maxis, well we're kind of in the middle, we're recording, so you're interrupting but it's okay. Nah we just started, come on well guys this is Will in the person. We need to get you, we just started so we're going over current state of Tellor. But the other thing you know from day one we always thought decentralization is important and if you think about just how can we make it overall better; how can we make it faster, how do we make it more secure, how can we make it more decentralized? Those are the three things if there's a way to do it without trading off any of the these the other pieces let's do it so. And lastly, I put this on here just as a something we should think about with every upgrade, how can we simplify it? You know, how can we... a lot of times the death of these big projects that have launched five years ago now on Ethereum and they're just massive code bases that nobody can understand. They have very limited users and basically you have to go use this interface that they put up because it's a solidity version for contract that's 8 000 lines long and nobody's ever going to read it or be able to understand it. We don't want that; how can we make it simpler? How can we make, there can be complexity but how do you keep it around the edges versus easy to understand? Which I think people really like that about Tellor. Okay, so that's the goals. What are, so yeah, I guess we'll write them over here, so we want to be increased users, increase decentralization, increase simplicity or decrease complexity. Those are the goals, the speed is one like, with the current design it's actually a really cool design and the way that it works with speed it's more dependent on the L1 speed than actually on us, I think. The bigger piece with how we can increase speed which we'll get to kind of at the end, is like speed that people can use it at, so you know we tell people have an hour-long delay, you could theoretically reduce that to a block or two away. If we have really good dispute monitors that are on it and that's just going to take time and practice to build those things out but even the really good dispute monitors are, you know, then you have the issue of can they censor your transaction from even hitting the chain just different topics. But the main protocol theoretically can be really fast and it's more of an issue on that one using it, we do have work there, so the main changes. So, these are changes that I've talked these over with Mike and Brenda. I mean we talked about it, like at one meeting and then I like brainstormed in my head, so these are my ideas these are not like gospel we don't have to, these aren't like we're doing this and you guys will have to go build it. If you guys have better ideas, we want to talk about all of them. But just as like a way to kick it off what we see would be good changes for Tellor, without brainstorming from zero these are what we think we should do. Big one, flex on main net. So, I think if you've been paying attention, we all should have seen this one coming. Basically, we have TellorFlex on all the other chains we should make Ethereum main net just match that. It's arguably, they're basically the exact same system, the only thing you take out is like that tipping piece, which would then go over to auto pay, which would then mean our basic Tellor contract, that master contract would basically just turn into a token, which would be cool, we could also make the token match all of the bridge erc-20 tokens, we could remove upgradability and we, well we could, since it would just be a token, you could remove any of the risk of upgradability in there. So, this is actually a big piece that I sort of like. You get rid of that, like I think one of the bigger issues with Tellor right now, is security. Right now, we have upgradability on our contract and if you break that voting mechanism, you can break Tellor, you could upgrade it, you could trash the token price, you could just nullify all the values, you could really trash by removing the upgrade ability, moving to just a Tellor Flex, that you can't do that on, there's actually no way to do that. I mean even in Tellor Flex you know with the current Tellor Flex design, which we'll obviously go and like relook at, but even if you broke the governance on Tellor Flex, it would still be, you actually can't put values back on chain on Tellor Flex, so it would be really hard to actually break it and get bad values through or trash the token price or something by breaking the voting mechanism. On Tellor Flex it just would be impossible, so this would be a huge thing for the decentralization aspect of the protocol. Now I know this will, we'll talk about it a little bit later, but it goes into maybe some messaging bits a little bit you know, we'd maybe, you guys have heard me talking about it on some of the calls, but there's like, you can talk about Tellor as a DAO and then you can talk about Tellor as a protocol and you know this would be a move more in the protocol direction. If you think of a DAO as more of a company, you have full control over everything involving the token and the structure and full upgradability, we're kind of throwing that away in favor of more code is law type stuff, which is cool. So, that said there's two pieces here, the first would be I guess on governance. What does governance look like, I actually really like the structure we have over on other chains: so, it's the 25% team, 25% token holders, reporters and users. You can do that the question I actually, so similar to other chains I like the model. Similar to other chains we can obviously look at weights and things like that just to make sure that there aren't any risks there, you can do some better deep dives into it. Also, how to maybe add users in a better way, versus voting on the array. The other piece would be, would we want to use snapshots? We could use our own snapshot governance, promote voting, that could be cool. The only question is, Tellor oracle would be bringing the snapshot vote on chain to govern it, is there any sort of there might be some yeah weird risk as far as, you know, the feedback loop there. I think it works out but we have to think about it a bit more. So, yeah, a different thing. The other thing for the token, so this kills Brenda, the squeaky marker, how can we, if it's just a token, what can we do, we can take out checkpoints so on main net if you guys have noticed Tellor tokens are like twice as expensive transfer is all a lot of other tokens it's because we've got the checkpoints. Chop them out, super cool. Cheaper. The other thing well you know we talked about it and then okay so if we're removing any upgradability how do we mint tokens? You know, do we still vote on those? That's a really tough one you know, if we want to move towards more of a protocol, it's actually really hard because like if you have ability to mint tokens via the vote it, might as well be an upgrade because you can still basically trash the entire token price, you just minted a billion and then now your reporter's stakes are all worthless. So, you would basically have to get rid of the ability to mint. Now this doesn't mean like we wouldn't... it would be like more the ability to mint at your discretion. Which is different, so we would just move to fixed issues, so you know, right now we have, sort of the team gets paid when we get paid like 4000 tokens a month that's the team's dev share, we could just continue that and then we have the time-based rewards which is like another 4000 something tokens a month. We could continue those but for me I wouldn't want to actually keep time-based rewards. I would actually propose we give say it's like 8000 tokens, I think we give the team that just automatically goes to the team and then the token base rewards go to a pot that the governance controls where it goes so like it would be more of like the DAO structure around that pile of money and we use it to fund basically the auto pay contract. It would have to go to the auto pay contracts. The reason would be, so you could have like tokens to team and then the rest would be to auto pays. Basically, the reason is, right now the time-based. rewards basically they just fund like the same ideas that aren't being requested over and over on main net. Which is wasteful, and there's also no ability for us to put these over on Polygon or on if we get users on Harmony, how can we subsidize users over there? Subsidize a reporter network over there let's use some of these tokens to do that and I think it would be hard to sort of automate this. I think what it's probably going to look like is the buy a vote, they'll delegate, this goes to the team to move over or this go you know you would delegate it to somebody else or to a contractor, to a team member who would then put it over on some other chain, put it into the... I mean if it's on main net and Ethereum, you could obviously fund directly the auto pay contract but this one would be like, if it's on another chain you would kind of need somebody to hold hands there. Would you be fine? Because it just makes it way more flexible. I want to use these, like if we use the time-based rewards, they're paying for liquidity stuff on Ethereum they're paying for AmpleForth, that update every day you know, they're giving it to stuff that is actually used. Whenever we talk to a user and they would say like hey like how much is it going to cost and be like actually we got a bunch of tokens right now looking to help you guys out, why don't you guys come on over and it's free for until these things run out you get a thousand tokens. You could easily do a thousand times you know if currently time-based rewards are giving away four thousand a month give two thousand tokens to a new project to come on board and bootstrap you for six months. Those would be some fun ones. Obviously, there would be no more treasuries, because this is a trade-off. Take a picture or I guess we're recording it. But what are the top level like pros and cons of treasuries are gone? I mean protocol simplicity and the decentralization aspect you have to give ourselves something, the ability to mint at discretion you know, that's what we kind of want to get rid of. The cons, the treasury was a cool system I really liked it. If we could actually see it working of people staking and getting rewards you know, which is kind of missing and Tellor to bootstrap some participation but I think we have another solution. Part of that would be kind of the pros and cons basically like the cons are; we don't get what treasury was supposed to do, which was supposed to drive token demand and sort of soak up some of this excess liquidity which we still have in our token.
Mike: But does any of this architecture address that?
Nick: Getting into it...
Mike: Okay before we move on though, the token rewards. Would we want to build in an, either algorithm for it to self-deprecate...
Nick: The treasuries?
Mike: Not the treasuries for the tokens that go towards subsidizing usage, the 4000 tokens that go towards, like in a world...
Nick: Well, I mean you could, so like it would go to this DAO vote that would put people so like the DAO would, you know if you broke the vote, you could just steal those tokens basically, but like obviously you're not going to be breaking the vote anytime soon. But I think the bigger thing like if let's say we move, you could just move those if you don't want to fund an autopay, let's just burn those 4000 tokens a month, like they could vote on that, you could vote to I don't know, let's send them to some discord users eventually, like if users aren't there, I think these 4000 tokens would be, these are used for user slash like what's the big bottleneck, that's what these things should be going towards. If our big bottleneck is marketing, we'll throw it towards marketing, if our big bottleneck is reporters, we'll do something to fund more reporters, it's more efficient because right now time-based rewards are like inefficient. It's just like super inefficient spray and pray like you're just reporting for whatever, so it's not being used. I mean time-based rewards are good, we have a reporter network I mean, to bootstrap a reporter network it works, you have people reporting and it's, they're not missing those set-based rewards you know. It's very live, so that's good. But at the same time, it's just very improvements but yeah how do we sort of make it not that. Less wasteful I guess you could say. And I mean obviously so since it is still inflationary, so we're minting like 8000 tokens a month or something, we still have inflation in our system but it goes down over time. You know 8000 tokens this year, is going to be more of an inflation percent than next year because it's obviously, you have more tokens such that's the world.
Owen: Before we get like some critical mass, where it's like oh this is there's a thriving ecosystem around this protocol. Essentially making a fixed amount of tokens going to the dev team creates another existential risk because it's, the price tanks or something...
Nick: It does, I mean we've talked about that, but you wouldn't want some risk of like, if the price does tank, then we get 100%, we have 100% inflation to match it, you know. You could always, I mean this was, this goes back to the early days whenever we were honestly discussing the thing that most teams do is you have like a giant pre-mine with the lockup for the founders, you know, and that's how the system funds itself, you mint a million tokens right at the beginning and then Mike, Brenda and I share and dump on you guys all in three years when they unlock, or six months for most projects and then, when the project ends... You know we decided we wanted to do this more, this was like a zCash style dev share model and it just incentivizes you. We felt that it sort of aligns properly, because we want the price to stay high, so we have an incentive to do that, which means that we're going to keep working and we also, we don't have, it wouldn't make sense for us to leave the project or just dump all of our tokens. That's kind of why we lined those incentives.
Will: So, what's been the evolution of dev share because it started with that share, for Tellor Flex or TellorX?
Nick: It's the same, we just, the only thing we took out when TellorX, it used to do a transfer every single time somebody would mine something, that's insanely gas inefficient so now we just have, it just accrues and then whenever we go pull it.
Brenda: The way that it happens and then we just unlock them over time. In November we minted a year worth of dev share and a year worth time-based reward and then we just unlock them over time. And that's why our current supply hasn't really changed.
Nick: I mean functionally it's the exact same.
Will: So, it’s still the same dev share, just doesn’t come from each transaction.
Brenda: I guess we're going to go back to sort of like every month we issue it, so it's not every transaction but it will be once a month, it's minted how would this be done?
Nick: Or we would just have a function that make people pull it like that, but it will be at our discretion versus not every, it doesn't have too necessarily be automatic.
Brenda: Right now, we're minting for two years.
Nick: Right now, I would put like a function in similar to talking about how it would actually work, I would say it would be like you guys get, you know, what time was the last pull, you know every month you get 4000 tokens and then it's a mint every time you pull. If you wanted to pull every minute you could but wouldn't be any tokens you know or you could just wait a year and pull 4000 times 12, something that's probably how I would build it. You're going to have big jumps in the supply and then which is actually super fun one for tax treatment purposes. If we have the ability to mint tokens when we run this function, when do we owe taxes? Super fun. So, one thing we haven't talked about is, anything we can do to make the token better? How can we reward people for holding and staking it? Give it value, obviously we have the staking, but we have auto pay, this is what we want to push people towards, basically we think, I have agreed with Brenda on this one. We would make it so people use TRB to pay, use TRB, we push people to use TRB. Obviously, you can use, if you want to use your own token or something like that you could build something that trades it or converts it or there could be special structures but we want people using TRB for it. And then there is a fee, currently we have 2% fee, we could raise it, could lower it. 2% seems cool, maybe a little higher but what should this two percent fee do? That's the question we were thinking why don't we just pay token holders, so we could use this to pay and I wouldn't even just pay holders, I would pay staked holders.
Mike: They're off exchange well I guess the exchange could stay but I don't know.
Nick: I would just make this stake, you're staked as a reporter, like there's only one got it so you can think as a reporter, you don't even have to report, you're ready to report. Which is good for the system, you don't have to and then you just get a 2% fee and then what I would do is similar to how the treasuries worked which already have the code, you have to vote, or delegate. If there's votes going on you got to report or else you don't get your rewards, that way, we have people incentivizing them to delegate incentivizing them to stake incentivizing the vote. And then what's the benefit of holding this? And the cool, the weird thing about this is, so auto pays on a bunch of different networks same with your staked on a bunch of different networks, you actually have to pick which network you stake on to get rewards, so if you're staked on main net and nobody uses main net, nobody funds main net autopay, you actually don't get any rewards, but if you're staked on Polygon and that's where everyone's using autopay that's where you'll get rewards. It incentivizes people to move and stake your token on the chain that is actively being used, which is good.
Tim: You can only vote if you're staked in this model?
Nick: No, you can vote, well there's reporters, so reporters kind of have, you are part of the reporter's 25% of your staked, but then you can still vote if you just have your token over on the network, but you only get rewards if you're staked.
Spuddy: So, for the rest of us how do you get the vote results from different chains?
Nick: You don't care about all the other chains, because it's not for upgrades anymore, it's just not upgradable. Cool, so a lot of different things you can do with it but that way you incentivize is stake you're incentivized to you know hop on and that way if you have a bunch of staked reporters and moving the Tellor Flex you don't need like a bunch of different addresses, you can have a whole bunch of stakes in one address so it makes it a little bit easier than key management on I mean.
Will: How does auto pay fund dev share?
Nick: It doesn't. That's just the normal tokens itself on stake.
Owen: So, technically you could, the DAO could vote to use the tokens that are minted every month to fund a different contract than autopay, could be like a different payment.
Nick: That's what we said, if we somehow blow up in users and we have 100 users but you know for whatever reason nobody's reporting, we could just, I don't know use it but usually it should work through autopay but you could give more rewards to just reporters or if we wanted to do, we have all these tokens we need, let's give them to marketing let's give them to have a giveaway of some sort or just burn them. Lots of things you can do.
Akrem: Is the stake amount still the same and does the staker have to be? Can you stake less than the report and still earn the fee in this?
Nick: No, I wouldn't, because the reason we want people staked is that way you're able to report. So, like in case the network there's a lot of strong things like if the network goes down or if there's like an attack being ready to report is really good. But yeah, I mean we could talk about; do we want to lower the stake on main net, raise it, main net is a super tough one, because block times are so long but you know we can obviously talk about what the stake on every network is and there we should probably have some sort of formula with that, you know. But it was, right now we just have 10 TRB, it's the same automatic, it's the same on Harmony same one Arbitrum and they're all vastly different chains so we're just sort of hand waving about 10 TRB. Sounds nice because they're all really fast. Usage wouldn't matter probably, more matters like does their chain have finality, how fast is their chain? Usually, the slower the chain the higher the stake has to be how quickly? A lot of different things but maybe making it somewhat formulaic versus arbitrary or maybe arbitrary is and simple is, it's fine you know, it might be we're tens more than enough and keeping that at 10 is way simpler for people to understand. Might very well could be the case, other things we want to do, keepers. We talked about this, you can have them, you can follow the exact same structure keepers are paying them to do something. You could say hey we have verified on AmpleForth we have to run every night somebody just has to run this function or push to so once a value is mined then somebody has to run push on it. How do you incentivize people to do that it's a keeper, you just pay somebody to run this function, it doesn't matter who they are it doesn't matter, you know, lots of people use keepers to automate, you could have an alarm clock on Ethereum, send me money from this address or click this button when it's live. We can create some keeper networks, funding them directly through autopay. So yeah, I'd love to look to if I didn't add this to the sheet but is there a way to tie in MEV with it, both of these so could you pay the miners directly if they included in the block I don't know, good for things to go even faster to compete with some other keepers. That's for research, the other thing is a mixer, this is on the research list, Tim and I have been talking about this one, you could use the autopay as a mixer as well, Tornado cash has this thing where you fund a big amount and then you can take out little amounts privately. You could have like a giant mixing service built into this could be cool basically you have money coming in and money going out to somebody that's I don't know, because you've anonymized at all. Now you have a mixing service get added in, get some more fees. Legal review pending. Okay so, that's it on kind of the token piece questions so far.
Tim: I still kind of wonder if we need checkpointing on in the token because in a vote you can move your tokens around and vote from different addresses with the same token.
Nick: You can, but so the only issue is so there's no checkpointing on any of these bridge tokens so like main net would be different obviously it does increase security but I think that in my mind, what you would say is well you can do that, but at the same time we have multiple voting rounds so it sort of takes it away, because if you knew that somebody was doing that in vote round one, the next you would basically dispute it to another round and then honest people would do that too and it would come down to whoever has the most money. Which always does right in either of the voting scenarios so I think like the game theory works out that it's okay only due to the fact that we have multiple rounds.
Tim: Right, yeah. And if would we possibly want to only let you vote if you're staked because you only get the reporter stake if you have a report put in, so you get like one reporter vote per submission, but anyways kind of like that that Maker blog post that you posted that would be one way to do voting where you have to have one state you could.
Nick: Yeah, I mean right now the token holders who aren't staked or users only have a 25% weight anyway. The question would be could we just chop it all the way off, yeah maybe. Yeah, I think it's a fair.
Tim: I mean then if you're staked then your TRB is locked up for a little bit so you have a little even more skin in the game, because there's a waiting period to unstake it.
Nick: Yeah, I mean, what would be the benefit of having it open to everyone, would be people who don't want stake would be able to vote and smaller people would be able to vote. Not that their vote weight would count for much but give them a say. We'll put it on here, only stakers. Take it out.
Brenda: And I think that has, I like that because it would act as a checkpoint because even if so in a smaller chain where it's actually cheaper to do like the transfer vote or Ethereum might be too expensive I think that definitely works out.
Will: What's the transfer vote, transfer vote then?
Nick: If you could just vote from your address, send your coins to another address and vote from that address.
Brenda: But if they're staked, they can't do that and we don't have to keep track of their checkpoints, balances.
Nick: It's not an issue really.
Tim: And this would prevent or it would make it harder for exchanges.
Nick: Yeah, that was what I was thinking but I mean they could still stay, they could, but they wouldn't want to stake all their tokens because they're in exchange and they need liquidity.
Nick: I mean they don't typically they never do because I mean like if an exchange wanted to be malicious on any of these tokens it would be it would be the nightmare scenario basically. I mean obviously this could help but you know if an exchange that holds 30 percent of our tokens whether they're voting or not they have a say so it's just what it is.
Will: What would the breakout of the 2% be across stakers based on how much they hold?
Nick: Yeah, so it would be based on how much you have staked, there were three they would get a third of 2%. Then it has more... and I mean it wouldn't be much until fees get high basically trivial beyond, but figure out how to track that.
Spuddy: When a value gets disputed on Tellor Flex, I feel like I should know the answer to this but how many of the stakers tokens get locked up?
Tim: One stake, so 10 on the Polygon.
Spuddy: So, the address can't be four but only ten tokens are locked up is that how it is?
Nick: What do you mean why? Like the dispute? The did you feel just few fees is 1 to start out with what about the dis like but it goes up.
Spuddy: As a reporter, if I get disputed, I have 100 TRB staked, Polygons.
Nick: It's your whole stake is locked. Oh no, 1 stake is locked.
Tim: Yeah, even if you have 100 left you just get 10.
Mike: One stake per disputed value.
Spuddy: But then that address is also like...
Tim: That address can continue to report though if they still have other updates like
Mike: Nine other ten states
Nick: And the reason you did that is basically like if they were actually malicious it's sort of trivial to just break it up among 10 addresses so it wouldn't make any difference.
Will: At some point in the future if you ever wanted to change that?
Nick: Yeah, you could I mean this could be so this is this is another great technical yeah, we had could you increase this basically the autopay is a completely separate contract. All it is it says like go report on these seller values and then we're going to pay 98% of it to that reporter and 2% to this other contract it actually isn't connected to the token or the oracle in any way shape or form, it just reads from the oracle um so anybody could do you could have multiple auto pays on different things with different fees somebody could even. This has always been an issue, you could take an auto pay, chop off the fee then what happens or you could chop out using TRB then what happens. It kind of breaks a lot in our system you know, we want people doing it, the basics are I think that if that was the case and a malicious party was doing that because, you would want it to be fair. I want people to use TRB because it's, this is an ecosystem, we're trying to support the network, you can get over it in 2% fee, it's not extractive. Where supports this whole ecosystem. That's what I, mean so like basically what you would say is if you fork us and are using autopay on your query IDs, we may or may not vote on your disputes we may or may not vote correctly on your disputes and you would have to like hold that threat over them to say, go pay the fee or else you're going to get... not going to cooperate like listen our team all has a big portion of this vote and all of the other reporters who are paying honestly and the other users are probably going to not like this either. So, go play next. And I think just the threat of it is like plenty but you know I think if this was a 50% fee, yeah could be you know maybe people would come up with some different systems you know but 2% fee not that bad.
Will: That's on everything like if somebody were to auto pay and they wanted to auto pay a lot in advance it wouldn't be like a discount in me, okay.
Spuddy: Yeah, well, they have to buy tokens.
Mike: Yes, if they made their own auto pay, they would miss out on these token rewards that are funding from the contract right.
Owen: Well, they're basically just where they could just campaign to the DAO side. Yeah, it could give us this we could find this auto pay any phone anyway yeah but yes.
Nick: I mean that would be like I don't think it would be an issue but you can play with the game. Alright so other things, just a few more things so Telliot. How do we make Telliot better? I think the bigger thing, we want to monitor disputes better that's like the biggest thing, a large portion of our security comes from our ability to monitor disputes and properly dispute them we want to make Telliot or some software really good at this and we got to get better. We know we do as far as monitoring our network goes to help security. Other than that, probably just simplicity/ease of use. As we grow and go on a lot of other chains, we want to make sure that Telliot is easy to use for everyone. Like any software obviously, you know we don't think there's any massive changes we can do but you know maybe we could rebuild it from scratch this year. Maybe not, lots of things we can think about but it's not any really big changes as far as you know. The last one when we went from proof of work to proof of stake, there was like really big technical changes but obviously since we're, we already use a Tellor Flex on Telliot so it's not like we have to change too much for it to work on the next version. I know we had talked in the past about a peer-to-peer database, these are some things that we can think about in general. Just how can we sort of be better stewards of the space because like we have you know; we could actually have Telliot and another and our system actually be more of just a standard pricing tool so right now a lot of people come to us like what should we use is the bitcoin price what, should we use for the bct price or the cny price. These are really hard questions because what is the bitcoin price? How do you do this? We could theoretically have Telliot as an open-source software, even like serving in on a peer-to-peer database, have it be an open API that is a data feed for the bitcoin price that anybody can query the bitcoin price currently from. You know, our nodes, that'd be super cool for people and then you could be like the standard bitcoin price out there. It's not linked to an exchange, it doesn't have to do anything really with necessarily putting it on chain, but just you could be the standard of this is the best way to do it and same with you know like a lot of times like I don't know if you guys have ever tried to pull stock prices from the internet all APIs are like come sign up here with an email and give us your registry and everything that we could just have a peer-to-peer database. We could query stock prices, I don't know, so like you know as a decentralized database could be cool, store stuff on IPFSs, gets creative here. Yeah, like it's just the you know what that price of bitcoin is that our nodes are reporting in our really robust aggregation methodology that we put in place that could be it, you know like people have talked about like the inflation methodology like. I know we have the resumes as good as anyone to come up with a new inflation methodology I think we can do that we just serve it and then it's not even if people want to request and put on chain, they can but we could be useful to the space as far as just that's what we put out, I think. Fun things to think about. Anything on Telliot?
Will: Well, Telliot is who we really need to grow her admissions to our users growing a reporting network is the secondary most critical
Nick: The reporting network should follow with users, like if users are paying reporters will come like you know and we've always struggled with this as far as like you know because you can even see it in like bitcoin or like how many miners do you need to have a successful bitcoin? If you have five is that enough probably five of them control like 50% the hash rate maybe it is, maybe it's not. 10? 20? I don't, you know like there's not really like it's not 10 000. You don't need that many, you just need basically a handful of people who can report for a profit and the cool thing about us like you know like even versus like a ChainLink, like we could actually have five reporting parties with a ton of stakes, who are providing all of the data requests and they're making all the money on our network. We're actually more decentralized even if we just have those five than ChainLink is, if they have 500. The reason, anybody can dispute and then if those five guys go down the money's still flowing, somebody's going to step up and do it. Like just the fact that you can replace them, less of them, you don't have to trust them as much right, you just want to make sure that people know how to replace them and come in there and report on new things and you could always do something with autopay you know we've had ideas about. I don't know you could give people like first-time reporter incentives just to test it out. Yeah, if you know, have fun thing, fun games like that to play hey if you come on here and actually do register with us and then you're eligible to be a reporter you can make a thousand bucks this month. Just to make sure that you're getting new fresh blood and not the really big guys.
Will: So, and like the competitive nature because we're just talking about how like Krasi has really good software built for his purposes built on top of that, sure and for somebody coming in at least on the main net competing against him is something that just seems like very challenging to do for something you know, now moving on to different chains that's kind of been addressed right and well I guess is there more that should be done or could be done or maybe doesn't need to happen at all in terms of like the barrier of entry being a little bit more approachable and then allowing something newer to be competitive or a pathway to be competitive without.
Nick: It's probably super tough to make it competitive.
Owen: I've had that question a lot too and usually what Nick. I'm going to paraphrase, is like this, there you have an end game where there is going to be a few number of reporters who dominate and we have one right now Krasi, and it's okay we could... what is the purpose of putting in more effort to equalize when there's always going to be someone who's going to dominate. We already know Krasi, Krasi cares about the system, so it's like what do we have to do anything about that?
Spuddy: When you take out open competition you lose security too, because then you've developed software where people have to... if you were going to make it so reporters share rewards equally or something like that, then you created an environment where there's no competition, there's never an innovation.
Will: Sure, yeah. I'm not necessarily advocating for that.
Spuddy: The team is the only group of developers building on it it's like that.
Owen: I mean it's basically the reality is he's, there's just like so many ways he's probably optimizing, I mean like he's just a better, you know he's spent way more time and he's a better developer, than the resources that we have realistic.
Nick: I mean it's just not a game that we try and play.
Owen: Yeah, we don't know like if we could beat him really like okay, we're going to, I mean this is yeah, you know.
Will: I'm not necessarily looking at it as like trying to beat anybody, as much as like just the way that we position ourselves without like anybody can be a reporter but not anybody can competitive.
Nick: I mean this is the same problem. I mean, can anybody be an Eth miner, Spuddy? But I mean most people, like if I plugged in my GPU, would I make any money like, my mac? But probably not like a couple bucks a day. Yeah, I mean like so you probably like it. It's super hard we could probably have some way of like.
Owen: You could randomly select a pool of reporters each time do victim feeds.
Mike: Maybe that moment Krasi doesn't get selected there's an open opportunity for that one request
Owen: But I think the other thing, we need if there's like better tips monitoring because in theory, okay if you put the money out there, people are going to. go report to it. But I think right now that's what we're working on, right now like yeah, we need to lower the barrier for even Krasi to report on all these things so like we need to build the example clients and document how someone else would build it reporting in every way.
Nick: I think the other thing you could do is pools, as Spuddy mentioned, we could fund pools so like if you know we have those tokens that are available you could say listen we're going to send this to tip contracts and to be a reporter on these two contracts it's actually only for registered pools, you know just to try and to try and diversify the reporter market a little bit. And you could do something like that.
Owen: Krasi could still dispute those values you know yeah for sure so and so yeah.
Will: I guess telling it is the reporting aspect of it, the disputing aspect of what anybody can do and we don't really have a client specifically for disputing.
Nick: No and that's we want to make it easier to dispute too it's definitely something we do usually part of the disputes though building a robust reporting network that's what we've always found is the best way to get disputes the reporters were always the ones just shooting each other um you know it wasn't users or token holders were never monitoring for disputes it was always like I saw this really weird price I don't want to submit on a weird price so it raised my red flags and then I disputed. That's a wheeze for disputing but I mean I don't know what the other guys were using I'm like what were the Chinese guys using I have not they weren't using Tellorscan they didn't speak English. Alright.
Will: Well and I guess with telling it and trying to encourage users to also be reporters is there trying in of either autopay or?
Nick: I mean, yeah, we don't necessarily want them, they can but we, cheaper for don't...
Spuddy: Especially for like somebody who's going to be like reporting their own data.
Nick: Sometimes people might, but you know I guess it would just depend on the user you know some how much you want to push that, as far as like you know I've even kind of talking to users, a lot of times users just want it simple like they don't want to have to think about it. Yeah, like telling them they can but. Don't worry you don't have to run software 24/7 to keep this thing up and running for you.
Spuddy: To get your data, it's just a safeguard if you did want to report. I always tell people it makes sense to learn how to do it just in case there is an opportunity you can you already know how to do it you can jump into networking.
Owen: And like realistically for new year's reviews and stuff usually you need it because you have to test their things that's reporting for it you know.
Nick: Yeah, and I mean I'd love to make like a front end too, that's easier than you could have like the one like submit to the Tellor oracle via front end so it automatically pulls the nonce converts things to bytes for you which we basically have all the code up there. But then you could easily just man my data is down like I'm going to go on Metamask, click submit to the price go. Alright so last piece; messaging. Things that we want to change on messaging I kind of touch this would be do we want to focus on being a DAO. You know there's a lot of I yeah, I mean how much do we want to focus on being a DAO. This is more of a move away from being a DAO and from a community and things like that because they actually have less say because you're moving towards the voting structure where token holders only have 25% weight and there's less, they can change in the system. So, you're kind of pivoting a little bit away from that, but it's sort of like being a moral, I keep saying protocol like you know we are software you know.
Owen: What's the distribution again, like the just proposed distribution?
Nick: 25% users, reporters, team, holders. Yeah, that's currently what it is on Polygon, so we like it. But that's we can change that today.
Will: I feel like we've been talking about moving more towards being in town but I don't yeah, I don't really know like where we are on the spectrum of being a doubt where we actually sit.
Nick: I mean you could say we're down now we're more doubt-like than most downs but you know like I think the big thing that I've kind of changed my mind over you know just be honest like it's super hard to get participation in these things you know that's why we're moving that's why I want to move towards more the people actually with some mistakes of some votes. Because getting the token awards to vote is it's a problem that we're not solving so you know.
Spuddy: Using snapshots to vote but not necessarily your tokens to vote.
Nick: You get more token holders to vote and but does that mean that the outcome of the vote is better is also a question.
Spuddy: I think it's the same because there's no like you want to vote on snapshot probably as many tokens as someone.
Nick: But I mean you find it like with the discord, I mean we love those of you that may watch this and they're very into it, but you know you tend to have just a handful of people who are really into it and then a lot of people who are not. Even the users, I mean from all of our users like you know even they don't want to vote they don't want to monitor it; you know we're the ones that go tell them that the Tellor oracle you know is doing xyz and then you know even by gen who Tellor pool he doesn't you know like he's like arguably one of the people that we might get to be able to vote on it but only because if we ping him on things you know. Users seem to just want a lot of the ease of use, they know it's decentralized they know it works, it's not going to think about it so coming from that. Just it works making that a reality of my mind is where we want to go and then I mean the big thing. A lot of these changes aren't that drastic, I guess. Even in the code base, but like if I could see us in a year, it would just be like a lot better documentation to kind of show how people do this, they can do it really quickly little bit more front-end tools, maybe but you know most of it is coding so it's just going to have to be with like how we explain to people how to integrate Tellor and a price feed is clean. Super tight because like the guy who came on our discord today and was asking, like he had the exact right idea, when he was putting in a spot price in the query builder and then he, of course he ran into BTC versus BCT, but that's a different issue. But you know and then he's going to, now he's like okay and then I'll found it and how much does it cost so like I mean we're doing something right. He's asking, he's obviously following along correctly, so but like making that actually happen and then ideally you know like in a year what I would want to see from the system is, it's like we just have Telliot it up and running. Here's we see a tip for a brand-new query looks like somebody new is using Tellor, that's pretty cool. And then we start submitting or you see a pull request for something else.
Owen: Yeah, like you know that the whole like process of like getting a user and like going from like them yeah from the career id to both like documentation and like how do you make it decentralized because it's still going to be like they have to open up a request and one of the team has to like...
Nick: Well for brand new stuff you do, but like I think for like spot prices you don't. You know like you could just go submit a spot price update you know obviously for brand new things. I think there's always going to be like you know maybe some of the ways that we could do that too would be like moving a lot of the documentation or like submitting a pull request we host that stuff on IPFS you know. We have it so you could anonymously submit it and that's like it's stored over there so then you don't have to give up any identity and nobody can take it down but, those are just like wish list type things. But you know ideally like it's just very user friendly, we just start seeing people using it, people submitting it other people you know oh somebody added a tip oh look a reporter went and fulfilled it who was that I have no idea. And that would be like that would be the feeling that you want to get and then it just sorts of works and then like you know. Yeah, there wouldn't really be any sort of need for anything um you know because similar to like even like if you look at like the bar protocols in my mind like what is like an Ethereum or a Cosmos or like you know Maker has a lot more say kind of in their protocol still, but like an Ethereum they don't do anything. They don't run the monitoring tools they have a really, they have a website that basically is just like there's some solidity docs, yeah so, I mean like you don't really have to do anything and then it just sorts of like it works. And then.
Ryan: It's just like a liquid the same thing right to extract away governance headaches it's just...
Nick: Liquity does some of the stuff yeah um i mean liquid Liquity sort of works too but Liquity is a little bit different in my mind because they're similar to most stable coins and like they're sort of a cdp structure they're roughly similar to a lot of the other ones so like let's see like Maker, that's a collateralized debt pool. That's like how they all work is roughly similar, so like the same people in one are in another so like you can like kind of piggyback on other people's documentation a whole lot. Which is always helpful like same way with like is Harmony really easy to use it's like no they're just an EVM it's not like they I didn't even touch their documentation I just like used their node url and then hope it all worked. Yeah, and it did which was great but like you didn't have to touch their docs which was phenomenal. It's like maybe if there's piggybacking, we can do in that sense i don't know um but yeah more things we can get for free so let me know where to go like what is even it would just be more on the messaging yeah.
Will: Like from a government standpoint what would be voted on?
Tim: We will always need governance or vote for disputes for disputes.
Will: Sure, yeah but as far as and then where did you raise this 4000.
Nick: Those 4000 tokens that's about it okay.
Owen: How does that how is it moving away from a dollar isn't it just like we want to focus on like the software as being like this protocol but aren't we still like the DAO basically?
Nick: You would be but I mean like a DAO a lot of times when I think of DAO you have way more control over a lot of it like if you guys if we wanted to go mint 10000 tokens we could, if we wanted to you know change everything we wanted to work on this piece of software like.
Will: I mean like the community proposal aspect of it and like votes like that like where did where does that come into play?
Tim: There wouldn't be community proposals.
Nick: Right now, I mean you could have communications for the 4000. Yeah, but that's like about it yeah.
Will: So, like thinking back to whenever who fired like a marketing team, Maker, yeah like that's not a vulnerability for the team itself not being more protocol-based, right?
Mike: Okay, but with Tellor X you could make proposals to fire the team and now hire this new team where all the funds go to.
Owen: Well in this structure you could too.
Nick: Not necessarily, you could still do that it just means yeah well, no you'd have to fork it. Like that's what now like you would have that's like usually a DAO I think of something that you don't have to fork like I mean theoretically somebody could relaunch Tellor with a brand-new team and they would have a new token address and they would you know.
Mike: The topic we haven't talked about was working and what situation would we.
Nick: You would ideally never require a system I mean.
Mike: I you know I don't like Liquity where like our b2 is an upgrade but it's a fork.
Nick: Well, the way like so like the way that it works now is like with flex it's like you would have a flex contract here and then let's say we rewrote flex and we made it way better. Old people could still use this flex and they could people currently using this flex like there's nothing preventing anyone from you could keep that going forever if you would want. But then there would be an anew flex2 and then you know you would have some reporters slowly move over here it would be more similar to like the Uniswap model, okay whereas like now it's like you would have reporters on both.
Spuddy: Because the token contract.
Brenda: What happens to our token address?
Nick: It stays the same. But the difference so like Uniswap the reason this suck with Uniswap. No, we're not doing a fork the reason the reason it sucks whenever you upgrade in Uniswap because like the liquidity. Like for ours it would just be reporters moving over but like if you wanted to keep some reporters over here so let's say Liquity couldn't update their oracle address they're stuck here, that's fine they can stay there and everything should work out because reporters can stay over there and as long as Liquity is willing to pay, reporters will stay over there whereas like a Uniswap if 75% percent of the liquidity goes over here 75% of your security on your. The liquidity is basically your security because people can drain and manipulate the market when somewhere else. So, like if you have to keep your own you know in our system you could theoretically just be your own reporters over here it would still work but in Uniswap would even do be your own liquidity. I mean you can, this can be pricey.
Will: The dev share would be locked in?
Nick: Locked in forever and ever.
Will: And so, the only you know the only flexibility in terms of like the team you guys were like we should we should double in size; we should trip in size. If you felt the need, we're still limited to those 4000 tokens.
Nick: Yep, and that's before I mean like that that's what's pretty different yeah but you can't sell them. I mean we I mean we could probably change we have an ability to change it if we wanted to.
Owen: But I thought the point of having it as a particle is that you can't change it then.
Nick: You, well I mean like if we wanted to move our address, we could you know, we could move it, not the governance, yes, the community. The community couldn't vote to move it.
Owen: You know that's what they would have to do basically.
Brenda: Yeah, how does this change like why where this to me it this seems very different from like before like for example Nick, you're saying like oh eventually I want to fire.
Nick: We can still fire everyone, yes.
Will: Yeah, that's okay like this, yeah like what happens with that thing. It's still going yeah, no the multi-stick just.
Nick: Who controls the multi-sig is a different question.
Owen: Well then that's just like a like okay we fired all ourselves and like what do you how do you give that how do you pass that off to someone like oh don't worry I got rid of my private key.
Nick: You know no yeah no it would be you'd have to like you could sit theoretically like we could DAOify that team's dev share as far as like sending that to a governance contract. You could make even our team wallet also governed by.
Owen: You could because having it hard coded in there seems very like not you know in line with the original kind of idea of Santa where it's like yeah and technically if like we all got up and left and wanted to go do some other projects the community could be like oh all right maybe they wouldn't and like price tags and everything dies but like it could just be like okay now we just need to like vote instead of like all right fork and like do all this you know.
Nick: Yeah, I mean I think for that that would be like a process of like when do we want to fire ourselves and then we send it to another address.
Owen: How does this affect everyone's like idea of like it's like I mean like.
Nick: Right now, it's sort of hard-coded in where it goes like in two years, we all get to like fire ourselves and now we're going to power structure or whatever what's the it's still on in my mind but uh Brenda’s never been on board with that idea so. That would still be possible it's the exact same it's exact same possibility so it's not like yeah there's still kind of the exact same centralization versus decentralization on that front. That's the current structure.
Brenda: If we get to that we will do the work and we'll make sure that it goes to the government's contract.
Nick: Well, no you wouldn't have to do it no you wouldn't you're not voting anymore you would just send our contract address like the team's address we could change our team. We would just have to send it out yeah to change the multi-save address yeah so.
Tim: Would governance be able to change the stake amount?
Nick: Good question.
Tim: Or any other little parameters like that.
Nick: I don't know dispute well I mean we have that now it's only in flex we did yeah so I mean but I guess we could think about like maybe parameterizing it more so you can break anything with it yeah I mean or you could just leave it hard-coded and I'm just for you know should also be a good I think it would be fine can I pay contracts um how much stake the recipient has to have to get paid no what you could do so if you wanted more people staked like I was thinking like what if a specific user wanted their reporters to be more saved yeah could they have a requirement on their own auto pay with like the stakeholder and the same care yeah what's the timeline for like okay we're having this discussion like when are we getting like community input on this like how do you guys do that I mean we're recording it I'm hoping to post it we'll see if we post it uh if we don't post it if you guys don't want to post this one we'll probably do this exact same discussion in a week or two and then we'll get a bunch of community input and we'll watch it.
Owen: Yeah, I think it's fine but like I think there's just like some of these things that we need to oh yeah for sure yeah, I mean
Nick: There was like some issues with Tellor X I mean we were changing stuff in like September October. L.
Brenda: Listen you know you got to there's just things that we aren't thinking about here that we'll think later literally on the brainstorming change about session of this do you remember the little cycle.
Nick: What if I send my TRB to this contract I mean but that's yeah you can send your TRB people send tokens to wrong addresses all the time.
Will: Is there a way that we can safeguard against that happening like rejecting?
Nick: You could you increase gas every time every check you do so is it worth it maybe it makes every TRB send yeah but yeah so, we can talk about it we can always vote with those four thousand tokens to give you to give somebody there.
Tim: If you wanted to and yeah in the oracle that it says it's for someone to claim some TRB that's been sent to the oracle address and it uses the oracle to verify to like allow someone to do that like so it says like I'm this is my address I accidentally sent this amount to the workload.
Nick: I mean if you accidentally send it to the oracle, it's a bigger problem but like in the token one, we could easily add a function that says like if you send tokens to the token address like you could just give us control over those tokens yeah like that that's that would be fine and then we can transfer them. So, like you'd still be screwed if you sent it to the oracle address but if you send it to the token address like we can help you out probably so yeah one of them right that's the more likely one anyways yeah well sometimes people yeah no for oh one.
Will: I mean going back to that 4000 though like I know there was some math to determine the amount of like runway and stuff of that being a good number is that something that isn't.
Nick: You could debate it yeah, I like it.
Will: Okay enough to be and that's based on a token price of something just yeah rough roughly padded based on where.
Spuddy: It's always been the case that the more one token is worth the more inside of those that's always ask the audience I don't think so I've been taking notes though if you guys need an alright subscribe being discussed Josh is exiting out of all the things that are currently on the screen.
Josh: No, I just got a lot of things wrong so like it was laggy but I don't know everything sounds good I still I me from the front-end perspective I feel a little bit of a disconnect with all this just because I'm still trying to it like we don't want a friend like Liquity.
Nick: Yeah, it doesn't really change anything I mean it's basically like everything's moving to Tellor Flex like the Polygon stuff which most of the front ends work with right now anyway so yeah.
Josh: No that's not what I meant by that I remember just kind of like as a general understanding of the full thing uh now that we're getting like more into the in-depth uh aspects of both like the token and Telliot and kind of like how they work and how to improve them that's what I was saying like that's where that disconnect was I'm just kind of like okay because I have no reference for like all right does the monitor dispute seem to be better or that needs to be a thing with telling them like okay I didn't even know that was a thing so that's where I'm coming from. But one of my main thing is like with the whole flex which is flex 2 and stuff like that with front end being kind of like last down the pipeline as far as like I'm running into this now with like the data feed is there ever going to be any kind of like um one like way to do things to like how to report in like the format of it or is that just kind of going to be like an ongoing changeable malleable thing depending on I guess the chains and just like what the ecosystem is that the reporting system is trying to be, because down the pipeline with front end kind of like having to digest all of that then you have a lot of these weird extraneous cases that you have to account for and it just makes everything really messy with like having all the legacy requests but then also like the legacy requests being encoded the Tellor Flex way versus not being encoded the Tellor Flex way and then there's the new Tellor Flex adjust all the spot price stuff there's like the custom queries eventually I'm assuming that could be supported. So, well is there ever going to be some type of like uh format like straightforward format that could live on all of the chains if flex is going to be something that's going to be multi-chain and kind of like the new standard with that standardization rollout could there also be kind of like a standardization across the board with everything to make everything a lot cleaner or is there always going to be a need for having those legacy.
Nick: No, it should be good it should I mean we we'd love definitely as we do this we want to talk to you too you know make sure that everything you had like this is also the time like in Tellor Flex like we're going back and we're going to change the code Tellor Flex like if you want more getters you want different events things like that let us know we can add them in so um yeah definitely think through it and then hopefully it should be standard on all the chains.
Owen: And as time goes on like we might discover like more limitations with that current system and it might change but you know theory as time goes on if there's less change because you figure.
Nick: You know yeah I mean obviously like even this change like although it sounds like we just put a lot on the board this change is so much smaller than Tellor v2 to Tellor X so it's like you know it's not nearly that big of a change.
Brenda: And Tellor Flex is pretty much done.
Nick: Yeah, so it's you know like I said we can go back we can maybe change a few things about what people can vote on what people can um maybe add some events and getters make it easier for the front end some stuff like that but overall, it's looking much more solid so all right Akrem, anything?
Akrem: Not really um the only one thing I think Owen was alluding to as well as the just the I thought the biggest thing of moving from a DAO to a protocol would make it I guess more decentralized but if you can just have a version two, I'm kind of lost in that piece. How is that less decentralized or more decentralized a version to in what way?
Nick: Like if you were to have a flex now and then you can just fork it in well no so I mean it's the difference between when you can have a flex and then we re-launch a new flex we can push users there but there's nothing that there's nothing that tells users like you have to get off this one they can if reporters want to stay here and users want to pay them here they can stay here yeah like it's more opt-in for the users whereas if you had upgradability and governance that would be like flex turns into flex 2. So, it upgraded whether you wanted to or not um that that's kind of how it's more decentralized it's more of the like opt-in approach, versus anything. Make sense? Okay yeah oh yeah thanks everyone for listening um and then yeah cool lots of fun stuff I mean timeline for this we'll post this video get some community feedback probably brainstorm it write it out like we have this document now right onto more of a formal proposed changes article that'll that that's probably over the next month then we'll code it for a month test it for a month audit, test on test nets for a month. Then launch so it's very cool nice long maybe we can hit September, October is like the timeline on this so don't hold your breath but it'll be here before you know it so cool thanks everyone.