Relayed v3 feature brings a cheaper, improved version of relayed transactions, that can hold multiple inner transactions. The inner transactions will be full transactions. Additionally, a fix on the base cost of relayed transactions was implemented, to follow the minimum gas rule. This fix affects all types of relayed transactions.
Note: Relayed v1 and v2 will be deprecated and marked for removal once v3 will be fully adopted.
The improvements implemented on ESDTs enable the dynamic NFT functionality.
3. Crypto API, new Opcodes and EGLD in MultiESDTTransfer #6139
With this feature, new opcodes were enabled for developers, among with new crypto VM endpoints(VerifySecp256r1, VerifyBLSSignatureShare, VerifyBLSMultiSig).
Additionally, EGLD(native tokens) can be now sent within MultiESDTTransfer (token identifier: EGLD-000000) along with custom tokens.
Note: When using native tokens as part of MultiESDTTransfer, transaction value must be 0.
We found several bugs. We did penetration testings and found even more. We want to make a statement around this when the release date is set. Even last week we found bugs on relayedV3, sadly.
It is really frustrating, especially for us, when we think everything is ready like 99% and than we find some problems and we have to code a lot again. The team is doing non stop overtime.
Everyone will (AND NEED TO) understand that delays can happen (especially for security reasons, when bugs are being fixed), but we really need more communication around those delays to avoid the community getting frustrated. I really believe people will truely appreciate receiving updates on these important updates every 3 weeks.
If I take as an example your latest twitter post from yersterday evening on the progress from Consensus 1.0 to Consensus 3.0, this kind of tweet is SUPER usefull; but I really think it should also be shared by official communication channels (MultiversX twitter account, Agora, Website blogpost, etc.) in a proper way and on a regular basis. You can’t be the only one responsible for sharing this kind of stuff. I also like how @AdrianDobrita also share updates on the work being done on finality improvements but again, these tweets should also be shared by an official communication channel.
Why haven’t you just given us this feedback whenever these bugs/problems were found? Everyone would have totally understand it and everyone would have just been informed.
Regular feedback is important, even feedback that says "“Hey, bad news, we found 2 more bugs, we will have to rewrite a lot of code, this will take a while, we will give you more updates in 2 weeks.”.
It’s better than leaving everyone in the dark for months, with nobody knowing what is taking so long.
Just a heads-up, we update the roadmap every week. You can check it out at https://multiversx.featurebase.app/roadmap and follow the points that are relevant to you. By the end of this week, the website should be fully synced with Featurebase.
The June 26 date you mentioned is just a placeholder. If you had been regularly checking Featurebase, you’d notice there are comments, updates, and even estimated timelines (ETAs) for each task.
We take all feedback seriously and act accordingly based on what makes sense at the time. For instance, when it comes to security bugs, we don’t make any announcements until the issue is fixed, deployed, and confirmed to no longer be a threat. Otherwise, we risk exposing vulnerabilities to potential attackers. I hope that addresses most of your concerns.
Is there any specific feature in SPICA that you’d like to use in your project?