Coffee chat 21st Sept

The main points from the transcription are as follows: - The team is planning to release a light paper explaining the staking mechanism and the 1% trading fee. - The staking mechanism involves generating revenue through off-chain operations and using the profits to buy and transfer pint to the SIP pint vault. - The team wants to preserve a single-sided pint staking system to avoid exposure to other assets. - Initially, there will be no trading fees to make the experience as frictionless as possible, but later on, a 1% trading fee will be implemented. - The team is working on a framework called EVM-ASM to assemble dynamic transaction scripts and allow governance control over trade parameters. - The team is making progress on the engine, with the order matching aspect fully tested, and optimizations being made to reduce gas fees. - Articles will be published to explain the trading engine and the functionalities of the Telegram bot. - The team is also focusing on strengthening relationshi Okay, announcement there. Let's wait a moment until everyone is there. Probably should be quick this week. Mostly just engine updates on my side. Yeah, no, the only topics people were curious about was like, as mentioned, like the 1% trading fee and how the staking mechanism works. Like, we haven't released the light paper, obviously, it's more explained there, but like the LDR. I think we can now. I think we're pretty much at a point where we can put that out. I mean, unless you feel differently. I think it's just the legal stuff, right? Yeah, it's only like legal stuff. And then, yeah, I think we can publish it like next week. Just make sure everything is correct there. Yeah, we can publish it for sure. Yep. Yeah, I've been over it a bunch of times. I think it's a good spot on the tech side. Okay, let's wait like a tiny bit more for the people to hop in. And then when we can kick it off. Okay, let's kick things off. Well, thanks everyone for joining. We have our weekly coffee chat. Yesterday released like a tokenomics article based on that we saw some questions from the community. It was in regard to the 1% trading fees, and it was a bit about the staking mechanism. Somebody asked a question about how we want to implement it, because there is a risk of front running. I think Adrian, it would be good to kick off with like the staking mechanism being given the TLDR on how it works like on a high level so that people understand it better. Yeah, I think as far as front running, like any transaction that interacts with the vault is going to be submitted through one of the MEV builders. So like actually front running like just the normal way is not possible. I don't know if they have a different meaning with it when I say front running. But yeah, the staking mechanism is effectively, it's described in the paper, which we'll put out, but basically just revenue. Anywhere revenue is generated by the protocol, it's usually done by off-chain, like either just the ops, which are the bots that are actively matching orders, or just actual transaction fees taken from a trade, which we'll implement at some point. The profits are just used to buy pints off of the market, and then the output pint, either a portion of it is burned, or actually the entire amount is just sent to the SIP pint vault. We have a vault for basically every ERC20 that can be spawned on demand. The SIP pint vault is actually the standard vault that we use for the rest of the framework for any other ERC20, with a special property that is actively being traded into by the bots just to, all revenue just being used to buy a pint and transfer it to the SIP pint vault. So then your staked pint in that sense becomes more valuable in terms of pint. So we originally had a mechanism where we could stake a pint-eat LP, but we really didn't want a system where you have any exposure to anything else besides pint. We actually want a single-sided pint staking. That's kind of a property of the system we wanted to preserve. So you'll be able to just go long on pint, just stake your pint, earn more pint. So that's kind of what we wanted, and that's what we put together. And to put everyone to ease, what Adrian just explained, we will also put it into writing, because I can understand it's quite a lot to get it addressed all at once. So we will dedicate a post to it, so it's all clear for everyone. Then I think we can hop on to the second part. So there was a discussion about having a 1% trading fees on a trade. So let me explain. Our focus initially will be the low-cap markets and the coins with a 5% buying sell tax on it. So that basically means if you're doing a trade by Uniswap, you will pay the 5% plus 0.3% as a user. So on each transaction, we'll pay like 5.3%. But via Pineswap, you would pay 1%. So compared to the second-best option, we are significantly cheaper than the other options out there. However, if you, for example, compare it to, like, let's say, for example, like majors or like blue chips, then we are very much aware that, like, a 1% trading fee is definitely not viable nor competitive in this market. That's why I also in the general chat yesterday explained, like, to start off with, we will have, like, no trading fees. This is also to make the experience as frictionless as possible in the beginning, so we can get as much feedback on the protocol and get it as smoothly as possible. So after that, we want to implement the 1% trading fee. And later down the road, we will have, like, variable fees. So where the pairs with, like, a 5% buy and sell tax, we can have a 1%, where on the more majors or blue chips, we can have, like, 0.3% or 0.5%. So we can adapt it to make sure that we are competitive with the rest of the market. I think that's... The way this is going to work, to describe some of this, like, in the tech side is, right now, we assemble these transaction scripts in the browser. So it's all done client-side. We want to have a framework where we'll have the time delay on this, too. But basically, we'll have a contract on-chain that can assemble dynamic transaction scripts. It's just a view function. So there's no transaction sent to this contract ever. It's just, it actually is a smart contract that assembles, like, transaction call data for a Pineswap trade. So it's basically, like, an on-chain version of the assembler that I wrote for this project. And so with that, we can actually make it so we can get on-chain state, assemble it without having to upgrade the clients of Pineswap. And so we still maintain the decentralization of the protocol, but governance today is permission to basically set parameters, which determine what the script is that is assembled by the on-chain contract. So that's something we're calling EVM-ASM. And it's an EVM assembler, which is different from EMASM, which is the one we're using now, which is a purely JavaScript framework. So with this, we'll actually have, like, a governance-controlled framework where we can set any parameter of a trade. And basically, trade can effectively have any behavior. But with the time delay element, you'll be able to react to changes, just to make sure any changes in the framework can be reacted to appropriately by anybody making a trading decision. For everyone, everyone will be fully informed for any change of a parameter to the system. But at the same time, we'll be able to get on-the-fly decentralized transaction script assembly that doesn't rely on something like GitHub to rely on version control. And what I can add to that, that flexibility also will allow us to use some of the same mechanism as, for example, like Robid uses, where you can hold an X amount of fines. And for that, you can get a discount on your trading fees. And in terms of implementation, where we can see that being used for is, let's say if a project or a market maker wants to use the Fineswap platform. As a market maker, it's obviously not viable to have like a 1% trading fee. So therefore, they will be able to buy part of the market and get a discount on their trades. And we can base it on the volume they want to fly through the protocol. But it's later down the road, we first need to implement it. So you think we should move on to dev updates or what do you think? Yeah, I think that's a good one. All right, cool. So I'll let everyone know then. We actually have made a lot of progress on the engine. We have it all actually working. I think as of today, the engine has been fully tested. And the only thing that's not tested is actually the DEX aggregator aspect. But the actual order matching engine aspect is all fleshed out. We have mutexes in place so we can actually match many orders in parallel from a single process. But we also parallelize as many processes as we need. But we have it so everything is packed in bundles and bundles are signed. The linearization of bundles is all working as we dispatched it for on-chain settlement. The only thing is we're just making optimizations to get the gas a little lower, just kind of like the MEV aspect of this. We want to get the best price execution in terms of transaction fees on-chain as we set up with the MEV bundlers endpoints. So what I'm doing right now is mostly trying to... One thing is just splitting. In a couple of instances, we have to make a couple of ETH transfers in the bundle. So we want to actually compress those into a single transaction. It's actually a very optimized contract which will exist on-chain, which only just splits ETH transfers based on call data you pass. So that's actually going to cut down gas. I think about 20,000 gas, so we get a little more optimized there. There's a few other spots we can optimize. I wrote some routines to actually repack call data and transaction data to actually compress it even further. We have the PUSH0 instruction, which was added by a recent Ethereum fork, which was useful to get it down a little further. So we're actually going to get a pretty great trade execution and be able to get things settled as fast as possible from a user standpoint when they actually go to dispatch an order. It should be filled immediately at the best execution price. That's what we've been working on this past week. Very cool. Yeah, I know. So we are still in line with our planning. So everything is on track. Also want to add to it, from the content side, we want to publish an article about the trading engine to also get clear what's going on there so everybody can understand it as we can see that it's still a bit vague of what the actual functionality is besides from matching the orders. Then we also soon published an article about the Telegram bot, where it explains all the functionalities it will have and the functionalities that will be added in the near future. Aside from that, we're also working on strengthening the relationship with our existing KOLs and trying to onboard new ones. Also a very important thing to mention is we are not working with paid shields or that kind of stuff. The KOLs are bright about us. We are trying to build a long-term relationship with them because they believe in what we're building and not simply because we give them something. That's our approach with all of our marketing efforts, basically. I know today we are actually featured in a paid newsletter from one KOL. Or actually, I mentioned paid newsletter, not in the sense that we paid for it, but it's paid to have access. But I will ask if it may be possible to share the article as well with our community, but I cannot guarantee that 100%. Besides from that, we're also working on getting Arbitrum fully functional. I know we mentioned last week that we had it live, but after some more testing, we wanted to improve some minor details, some little bugs to make sure it's running smoothly. I think that was it from my side. There's nothing from your side, Aiden. I think it would be a good moment to hop on to the questions from the community side. If you guys have any questions, please feel free to ask them in the chat. No questions? Well, there's one question I'm just reading from David. He's saying, I do not fully understand the market capital launch portion of the article. Is there anywhere I would have guessed that the market capital launch will be the seven-day TWAP divided by 63? No, it's basically the market cap at launch will be the floor price of NFT. However, for the floor price, we'll use a time-weighted average price of the seven days prior to the launch. So on each of the individual days, we will look at all the sales and then we divide it by the amount of NFT sold to get an average price for that day. We will do that for each of the seven days and then divide by seven. Then we will get like a floor price for the thrift collection, then multiply that with a thousand, like the total size of the collection and then multiply with the each price and then you will get the market cap at launch. That's how we want to do or we want to approach it because we believe that's the most fair valuation. Because the thing is, let's say if we would take the last floor price of the last sales or whatever, people could easily sell an NFT for like an incredibly high price to themselves and then we would have to launch that valuation, which doesn't make sense. We will launch a peak valuation after that. It's just not realistic. I hope that answers the question. Just to add to that, I'll be putting together the volume-weighted average, but it's not exactly like a division over seven. It's obviously the summation of volume over that time period divided by the total time elapsed time. It's discrete. It's just time series. It's a histogram basically. It's just volume-weighted average. It works out the same when you do the seven-day discretization, but I can't pronounce that. It's the same math essentially. It's just take the actual total volume over that time period and divide by the time period, you get the average price. Luckily, Adrian knows how to do the math better than I do. What you're saying is also correct, but we're just doing the regular thing. I do not see any questions from the community side. Is everything answered? It's always hard to believe for me. There are always questions. If there are no questions from the community side, I think we can close it off for today. Then if there are any more questions, please feel free to drop them in the chat. Then I want to say thanks everybody for the time again. I'll catch you in the chat. See you guys later. Take care, everyone. Bye-bye.