The Agile methodology is an approach to the software development process that focuses on flexibility, collaboration and incremental delivery of working products. It was introduced to address the limitations of traditional software development methodologies, such as the Waterfall model, which often tend to be inflexible and poorly adaptable to change.

Here are some key concepts of the Agile methodology:

• Iteration and Augmentation: Instead of developing the software in one large iteration, the Agile approach involves dividing the work into small iterations, called ‘sprints’. Each sprint usually lasts one to four weeks and produces an increment of usable functionality.
• Prioritising customer needs: Agile places a strong emphasis on customer involvement throughout the development process. Customer needs and requirements are taken into account continuously and can be adapted during the project.
• Collaboration and communication: Agile promotes regular communication and collaboration between development team members, as well as with the customer. This means that team members work together to address challenges and make decisions.
• Self-organised teams: Agile teams are encouraged to be self-organised, which means that they are responsible for planning, executing and controlling their own work. This fosters an environment in which team members feel empowered and motivated.
• Adaptability to change: Agile recognises that requirements and priorities may change during the course of the project. Therefore, it is designed to be flexible and able to adapt to new information and requirements.

There are several specific methodologies within the Agile approach, including Scrum, Kanban, and XP (Extreme Programming), each with its own practices and tools. In this in-depth look at one of the most popular methodologies: Scrum. 

Agile methodology: SCRUM

The SCRUM methodology is a framework that is used by a team to manage complex projects in order to extract as much value as possible through iterative solutions.

The SCRUM pillars

Scrum is framed within the framework of agile methodologies and is based on flexibility in adopting changes and the cooperation of a group of people sharing their expertise. The strength of this methodology is its empirical approach: knowledge is derived from experience, so decisions are made from what has been observed.

The most important pillars and features of this methodology are :

• Transparency: the whole team involved is aware of the various stages of the project and what happens.
• Inspection: In order to make these elements transparent, progress towards agreed targets must be inspected and evaluated in order to detect undesirable problems.
• Adaptation: If and when there is something to change, the materials produced must be adapted and the whole team adapted to achieve the Sprint objective.

Before going on to define what Sprint is, it is necessary to provide an explanation of the three most important figures of the SCRUM method:

1. The Product Owner is responsible for maximising the value of the product by defining and prioritising the functionalities to be developed, and works closely with the Scrum team and stakeholders to ensure that the product meets the users’ needs.
2. The Scrum Master is in charge of making SCRUM theory and practices understood by all.
3. The SCRUM Team consists of a Scrum Master, a Product Owner and the Devolopers (those who are in charge of creating any aspect of a usable increment at each Sprint). It is a cohesive unit of professionals who evaluate the activities of the Product backlog without any outside influence. Their common thread is shared responsibility.

The stages of the SCRUM process.

Let’s talk about Sprint (Iteration) again. It is the beating heart of SCRUM because everything that happens to give value, happens within a Sprint. The maximum duration is one month as having longer Sprints can result in the loss of valuable customer feedback.

The next phase is Sprint planning, which kicks off the Sprint by setting the work to be done. The whole team must have a goal (the Sprint Goal) and must work together to define its value and/or increase it through discussion.

The purpose of the Daily SCRUM is to inspect the progress towards the Sprint Goal and to adapt the Sprint backlog as needed. It is a meeting that lasts a maximum of 15 minutes and must necessarily be attended by the developers of the Scrum team. The purpose is to improve communication and promote rapid decision-making, eliminating the need for further meetings.

The Sprint Review is the penultimate of the Sprint events and lasts a maximum of four hours for a one-month Sprint. Its purpose is to inspect what has been completed or changed in the context of the Sprint.

The Sprint Retrospective is the last phase of the SCRUM methodology and aims to plan ways to increase quality and effectiveness. It is a great opportunity for the SCRUM team to self-assess what improvements or problems have emerged and how they have or have not been solved.

SCRUM Artifacts

In the context of Scrum, artefacts are documents or objects that are used to facilitate the planning, communication and monitoring of work progress during the course of a project. There are three main artefacts in Scrum:

Product Backlog:

• Description: The Product Backlog is a prioritised list of all functionalities, features, updates and bug fixes that might be needed for a product. It is a kind of ‘queue’ of things to be done.
• Owner: The Product Owner is responsible for the Product Backlog. It is his task to prioritise items according to the value they bring to the customer.
• Priority criteria: Items higher up in the list have a higher priority and need to be better detailed. Items further down the list may be less well defined.
• Updating and Refining: The Product Backlog is continuously updated and refined in response to customer feedback and changes in product requirements.

Sprint Backlog:

• Description: The Sprint Backlog is a selection of items from the Product Backlog that the team commits to complete during a specific sprint. It contains only those items that the team believes can be completed within the duration of the sprint.
• Responsibility: The team is responsible for its own Sprint Backlog. The Product Owner can provide guidance, but the team is free to organise the work as it sees fit.
• Sprint Planning: The Sprint Backlog is created during sprint planning, which is an initial meeting in which the team selects items from the Product Backlog and determines how they will implement them.
• Daily update: During the sprint, the team holds daily Scrum meetings to update each other on the status of the work and to adapt the plan according to new information.

Increment:

• Description: The product enhancement is the result of sprint work. It is an evolution of the product that includes all functionalities completed and ready for delivery.
• Requirement: Each increment must meet the Definition of Done criteria defined by the team and accepted by the Product Owner.
• Presentation and review: At the end of each sprint, the team presents the product increment to the product owner and, if applicable, to the customer for feedback and acceptance.

These artefacts are fundamental to the functioning of Scrum, as they help to define, organise and track work during the development cycle. Each artefact has a specific role in the Scrum process and helps to maintain transparency and clarity in the work of the team.

In conclusion, it is necessary to emphasise how essential it is to clearly define the Scrum or Agile methodology in a written agreement as it provides a solid basis for the project success. A detailed contract establishes expectations, roles, responsibilities and delivery criteria, reducing ambiguities and conflicts. It also fosters collaboration and transparency between the parties involved, promoting a culture of continuous adaptation and improvement. This contractual approach creates an environment of trust and clarity, which is crucial to reaping the full benefits of agile methodologies, where flexibility and communication are central to success.

Basic Elements

What it means to be a start-up today is certainly a simple question, but one that needs a very articulate answer. 

It certainly does not mean having a lot of free time and sleeping soundly, and it certainly does not mean being relegated to unpleasant, underpaid work.

Doing start-ups today has undoubtedly become easier than yesterday, if by start-ups we mean that circle of entrepreneurial activities in their initial phase, whose social object is linked to the sphere of innovation; and, today, doing innovation is easier thanks to the proliferation of public funds, VCs and business angels. Unfortunately, in Italy, we are still a long way from solving the problem of access to credit for this type of entrepreneurship, partly due to the malpractice of some investors in asking little and expecting much (too much) from founders.

In addition to significantly improved access to credit, there has also been a small improvement in the supply of services for start-ups. This is due to the joint action of several incubators and private companies whose services have been improved and tailored to the specific needs of innovative entrepreneurship in its early years.

Beyond the ecosystem that only partly qualifies what it means to be a start-up today, these few lines are meant to give an answer to what are the basic elements needed to create the alchemy of a start-up, postponing in-depth studies on specific subjects related to this topic to other posts on this blog.

The idea

Certainly, in order to even remotely think about a start-up, it is necessary to have an idea. Having an idea does not mean having an intuition. An intuition is “a simple, instantaneous, synoptic cognitive act; it therefore designates a form of immediate knowledge, as opposed to any knowledge of a discursive nature”; whereas an idea is a much more complex term that must be declined within the sector it falls into and, in its broadest and most generic meaning, constitutes the representation of an object in the mind: the notion that the mind receives of a real or imaginary thing, the fruit of its own consciousness.

An idea is something more complex than intuition, it develops from it but constitutes a more evolved state where the intuition is filtered and elaborated on the basis of one’s knowledge and skills, coming out modified and, therefore, improved from its initial state.

Sometimes it is necessary to wait months before an intuition is transformed into an idea, as the elaboration process is repeated cyclically, sometimes enriching it with the contribution of the first embryonic elements of the ‘team’ that we will see later.

Skills

Needless to say, in order for the process of transforming an intuition into an idea to bear fruit, it is necessary to have the necessary skills for the sector one wishes to approach. It will almost certainly be necessary to go into the technical aspects of the chosen sector in greater depth, by virtue of any protocols specific to the topic one wishes to address, in order to prevent them from constituting an obstacle to the development of the business model.

Studying and working on the subject are certainly preliminaries to setting up a start-up, however, it is practically impossible to cover all the specific skills needed for each element related to the business model, and it is here that the need for the next fundamental element, the ‘team’, emerges.

The team

The team sees its value manifesting itself already in the very early stages of a start-up’s development but, in reality, it has only begun its relationship with the start-up because it will be instrumental in every single stage of its development.

Choosing team members is very difficult and there are various schools that more or less agree on the subject; we will therefore avoid going into too much detail by pausing only for a moment to mention one element without which, apart from schools, it is certainly not possible to form a team: trust.

Between team members, it is necessary to go beyond mere respect, there must be trust so that everyone is able to express their value to the fullest, individually and as a team member.

The team is the flywheel of the idea, it amplifies the scope of knowledge and expertise from which the idea is filtered, which emerges from this process greatly enriched and ready to be timetabled in its various stages of design and development, the roadmap.

The Roadmap

Fundamental from the very first moments following the definition of an idea is the creation of a checklist of actions necessary for the progression in the design and development of the idea and the scheduling of each action. 

The roadmap plays a pivotal role in relation to the distribution of the various actions, as it also constitutes a connecting element in the event that an action requires the intervention of different actors than originally planned or, in the event that several actions converge for a subsequent joint phase. Needless to say, it is necessary to respect the timeframes set in the roadmap and their eventual re-scheduling in the event of unforeseen and/or unexpected events.

It is easy to see how the roadmap is not a rigid document but, rather, an extremely fluid one that must be able to adapt to unforeseen events, slowdowns and pivots, right down to the various branches that the idea might take and that might not converge on a single business model.

Advisors

The last basic element in the creation of a start-up is the Advisors. Advisors have the function of guiding the action of the founders and that of the team in general; they differ from the latter in that their competences are fundamental but at the margins of the development of the core business; they constitute a conditio sine qua non for its setup but are extraneous to the process of providing the service or selling the good.

The rationale for the need for their presence is obvious, as are the immediate benefits that start-ups reap when they are able to include professional advisors in their network for each of the basic needs of a start-up: legal, fiscal, financial, project, technical.

Making start-ups today

To be able to do start-ups today, these elements are extremely crucial: The idea, The skills, The team, The roadmap and The advisors. Without these essential elements, it is difficult if not impossible under normal market conditions to make it through the initial stages that characterise the life of a start-up.

Once these elements have been aggregated, after taking the first steps in the development of the core business, it will be possible to proceed with a financing round of the start-up, i.e. its pre-seed. This eventuality is excluded in the event that the start-up plans to pursue the initial stages of design and development of the core business with its own economic means or through possible financiers who have entered at the only previous moment, i.e., those of validation of the idea.

The ethical issues arising from the use of data augmentation, or synthetic data generation, in the field of medicine are increasingly evident. This technique, which is also called synthetic data generation, is a process in which artificial data are created in order to enrich a starting data set or to overcome certain limitations. This type of technology is particularly used when AI models have to be trained for the recognition of rare diseases, on which there is little data available for training. By means of data augmentation, further data can be artificially added, while still remaining representative of the starting sample.  

From a technical point of view, data augmentation is performed using algorithms that modify existing data or generate new data based on existing data. For example, in the context of image processing, original images can be modified by rotating them, blurring them, adding noise or changing the contrast. In this way, different variants of an original image are obtained that can be used to train artificial intelligence models. The use of this technology makes it increasingly effective to use AI to recognise diseases, such as certain types of rare cancers.

However, there are several ethical issues that arise from the use of data augmentation in medicine. One of the main concerns relates to the quality of the data generated. If the source data are not representative of the population or if they contain errors or biases, the application of data augmentation could amplify these issues. For example, if the original dataset concerns only Caucasian white males, there is a risk that the data augmentation result will have a bias towards these individuals, transferring the inequalities present in the original data to the generated data.

Replication bias is certainly the most critical issue with regard to data augmentation. If the artificial intelligence model is trained on unrepresentatively generated data or data with inherent biases, the model itself may perpetuate these biases during the decision-making process. For this reason, in synthetic data generation, the quality of the source dataset is an even more critical issue than in artificial intelligence in general.

Data privacy is another issue to consider. The use of data augmentation requires access to sensitive patient data, which might include personal or confidential information. It is crucial to ensure that this data is adequately protected and only used for specific purposes. To address these concerns, solutions such as federated learning and multiparty computation have been proposed. These approaches make it possible to train artificial intelligence models without having to transfer sensitive data to a single location, thus protecting patients’ privacy.

Federated learning is an innovative approach to training artificial intelligence models that addresses data privacy issues. Instead of transferring sensitive data from individual users or devices to a central server, federated learning allows models to be trained directly on users’ devices.

The federated learning process works as follows: initially, a global model is created and distributed to all participating users’ devices. Subsequently, these devices train the model using their own local data without sharing it with the central server. During local training, the models on the devices are constantly updated and improved.

Then, instead of sending the raw data to the central server, only the updated model parameters are sent and aggregated into a new global model. This aggregation takes place in a secure and private manner, ensuring that personal data is not exposed or compromised.

Finally, it is important to note that there are many other ethical issues related to the use of data augmentation in medicine. For instance, there is a risk that synthetic data generation may lead to oversimplification of complex medical problems, ignoring the complexity of real-life situations. In the context of the future AI Act, and the European Commission’s ‘Ethics Guidelines for Trustworthy AI’, the analysis of technologies as complex, and with such a broad impact, as AI systems in support of medical decision-making is becoming increasingly crucial.

The Log4j Vulnerability and its Impact on Minecraft

Minecraft, the wildly popular sandbox video game created by Mojang Studios, has captivated millions of players worldwide with its limitless creativity and expansive virtual worlds. However, in late 2021, a vulnerability in a widely used logging library called Log4j threatened the game’s stability and, more alarmingly, the safety of the entire Internet. In this blog post, we’ll dive into the details of the Log4j vulnerability, explore how it affected Minecraft, and discuss the lessons learned from this cybersecurity crisis.

The Log4j Vulnerability: A Brief Overview

Log4j is an open-source Java-based logging utility developed by the Apache Software Foundation. It is widely used by developers to record system events and monitor software applications. In December 2021, a critical vulnerability known as Log4Shell (CVE-2021-44228) was discovered in Log4j. 

This vulnerability allowed attackers to remotely execute arbitrary code on the affected systems by merely sending a specially crafted string to the vulnerable application.

The severity of the Log4j vulnerability stemmed from its widespread use and the ease with which it could be exploited. Within days of its discovery, the vulnerability had been weaponized by malicious actors, leading to widespread attacks on various organizations, including government agencies and private businesses.

Minecraft and the Log4j Vulnerability

Minecraft, which runs on Java and utilizes Log4j for logging purposes, was one of the most high-profile targets of the Log4Shell vulnerability. As soon as the vulnerability was made public, hackers started targeting Minecraft servers, exploiting the Log4j flaw to execute malicious code, steal sensitive data, and disrupt server operations.

The situation was further complicated by the massive scale of Minecraft’s player base and the sheer number of community-hosted servers, many of which were run by hobbyists with limited cybersecurity knowledge. This made it challenging for Mojang Studios and the broader Minecraft community to respond quickly and effectively to the threat.

How Minecraft Responded to the Threat

Mojang Studios, the game’s developer, and Microsoft, its parent company, took immediate action to address the Log4j vulnerability. They released a series of patches for both the official game servers and the client-side software to mitigate the risk of exploitation. Additionally, they provided clear guidance to the community on how to update their servers and protect their users.

However, the response was not without its challenges. Due to the decentralized nature of Minecraft servers, many community-hosted servers were slow to apply patches, leaving them exposed to ongoing attacks. In some cases, attackers took advantage of this lag by creating fake patches laced with malware, further compounding the problem.

The Fallout and Lessons Learned

The Log4j vulnerability in Minecraft serves as a stark reminder of the potential consequences of a single software vulnerability in our interconnected digital world. Although there were no reports of widespread destruction resulting from the Log4j exploit in Minecraft, the incident highlighted the importance of robust cybersecurity practices in gaming and beyond.

Here are some key lessons we can take away from the Minecraft Log4j crisis:

1. Regularly update software and apply security patches: Ensuring that software is up to date with the latest security patches is critical in preventing vulnerabilities from being exploited. In the case of Minecraft, applying the official patches released by Mojang Studios would have prevented many of the issues faced by community-hosted servers.
2. Increase awareness of cybersecurity best practices: Many server administrators and users may not have been aware of the importance of applying patches or the potential dangers of downloading unofficial patches. Raising awareness of cybersecurity best practices can help mitigate the risks associated with incidents like the Log4j vulnerability.
3. Strengthen collaboration between developers and the community: The Minecraft Log4j incident underscored the need for better communication and collaboration between software developers, like Mojang Studios, and the broader user community. By fostering a strong relationship with users and encouraging feedback, developers can more effectively address security issues and provide timely support during crises.
4. Emphasize the importance of layered security: While addressing the Log4j vulnerability in Minecraft was crucial, it’s essential to remember that no single security measure is foolproof. Adopting a layered security approach, which combines various defensive measures, can help protect digital assets and systems against potential attacks.
5. Encourage open-source software audits: The Log4j vulnerability remained undetected for years, despite the library’s widespread use. Encouraging and funding regular audits of open-source software can help identify and remediate vulnerabilities before they can be exploited by malicious actors.
6. Foster a culture of responsible vulnerability disclosure: The timely public disclosure of the Log4j vulnerability by its discoverers allowed developers and organizations to take swift action in addressing the issue. Encouraging a culture of responsible vulnerability disclosure, where security researchers and organizations work together to remediate vulnerabilities before publicizing them, can help prevent the weaponization of such flaws.

Conclusion

The Log4j vulnerability in Minecraft demonstrated the profound impact that a single software flaw can have on the digital world. While the incident did not lead to the destruction of the Internet as we know it, it highlighted the importance of robust cybersecurity practices and the need for collaboration between developers, users, and the cybersecurity community. By learning from this experience and taking proactive steps to secure our digital assets, we can hope to mitigate the risks associated with future cybersecurity threats.

Legislative interventions in consumer protection lag far behind the reality of events that increasingly see web3 shopping, especially given the expansion of NFT purchasing.

The information obligations under the Consumer Code and European law require professionals providing goods or services to consumers to provide information to consumers in clear and comprehensible language, prior to the conclusion of the contract.

Fulfilling this obligation can be complex due to the innovative nature of these goods, and understanding for the consumer what he or she is really buying, without adequate prior information, could lead to an increasing number of disputes.

The European legislator adopted specific rules applicable to contracts for the supply of digital content with Directive (EU) 2019/771, which was transposed into Italian law by Legislative Decree No. 170/21 amending the Consumer Code.

The new discipline expressly deals with ‘goods with digital elements‘, i.e., those goods with a digital component without which they cannot function. The digital component may be internal to the good, incorporated, or external, interconnected, but in both cases it must be essential for the good itself, meaning that without this characteristic it would not be able to perform its functions.

In the specific context of the sale of digital goods, the new subjective and objective conformity requirements dictate that the characteristics of the digital content must correspond, respectively, to what is stipulated in the contract and to what can reasonably and objectively be expected from the digital content itself.

The European Directive also states that the seller must ensure that the consumer is provided with the updates, including security updates, necessary to keep these goods in conformity for the period of time that the consumer can reasonably expect, taking into account the type and purpose of the goods and digital elements, and the circumstances and nature of the contract.

The seller must therefore fulfil a strict obligation to provide information about available updates so as to be exempt from liability for lack of conformity in the event that the consumer, despite receiving information, does not provide the necessary updates or installations.

In the specific case of the purchase of NFT, non-conformity of the goods can be recognised when the content is not available or is altered.

On the other hand, doubts as to the non-conformity of the goods arise when the NFT does not exhibit the promised rarity characteristics; the scarcity of the NFT is in fact fundamental for the quantification of its value, and a degree of rarity significantly lower than that expected by the consumer could render the goods unfit for use and therefore not conforming according to the subjective requirements. 

The contractual terms and conditions of sale of the NFT should therefore set out precisely what degree of rarity is to be guaranteed in the future for the NFT sold, and comply with the requirement of good faith and contractual transparency with regard to multiple other, often underestimated issues, such as, but not limited to, the possible consequences in the event of failure of the blockchain and the action for damages.

Another issue that will be decisive for the application of the protections provided by consumer protection legislation is to resolve, in NFT purchases, the status of consumer.

Article 3 of the Consumer Code defines a consumer or user as ‘a natural person acting for purposes which are outside his or her trade, business, craft or profession’.

In practice, however, we see an increasing use of NFT for advertising or marketing purposes, and the category of buyers is divided into occasional and ‘speculative’ or ‘collector’ buyers, who might not be considered consumers but rather ‘professionals’.

This first distinction will be the basis for the interpreters of the law for the application of many other issues that currently do not find practical application because the European consumer protection rules were designed for the conclusion of “traditional” contracts, not through smart contracts: think of the issue of the so-called unfair clauses and the impossibility of double signature of clauses required by Art. 1341 of the Italian Civil Code; or the so-called consumer forum, today it is difficult to establish the domicile of the consumer.so-called unfair clauses and the impossibility of the double signing of clauses required by Art. 1341 of the Civil Code; or the so-called consumer forum, to date it is difficult to establish the domicile of the buyer/consumer in the crypto world, precisely because of the anonymity that characterises blockchain environments.

The EU’s new Markets in Crypto-Assets Regulation (MiCA) may partly provide a solution, as it prohibits the anonymity of crypto-asset holders for admission to trading platforms, but NFTs will be excluded from the scope unless they fall under existing crypto-asset categories. 

The European Commission will be tasked with preparing a comprehensive assessment and, if deemed necessary, a specific, proportionate and horizontal legislative proposal to create an NFT regime and address the emerging risks of this new market.

Purchase of NFT and right of withdrawal

Another crucial issue for consumer protection and web3 shopping concerns the right of withdrawal.

According to Directive 2011/83/EU on consumer rights, the consumer must be informed about the possibility and how to exercise the right of withdrawal, i.e. the right to withdraw from a distance contract within fourteen days, without having to provide any justification. 

The smart contract under which an NFT is usually sold does not allow for the exercise of the right of withdrawal, as it is not possible to stop the execution for non-performance or in case of a change of heart.

The smart contract in fact uses the formula “if this/then that”, by virtue of which, upon the occurrence of a given event (this), certain effects are produced (that), which are predetermined by the parties themselves, based on strict instructions.

In application practice we therefore see numerous transactions with general contractual terms and conditions that explicitly exclude the right of withdrawal.

This exclusion is justified by making the NFT purchase hypothesis fall within the exceptions provided for in Article 59, letters a), b) i), m) and o) of Legislative Decree No. 206/2005 (Consumer Code). 

In this respect, it is recalled that the right of withdrawal is excluded (sub-para. a) in service contracts after the service has been fully performed if performance has begun with the consumer’s express agreement and acceptance of the loss of the right of withdrawal following the full performance of the contract by the trader and (sub-para. b) where the price is linked to fluctuations in the financial market which the trader is unable to control and which may occur during the withdrawal period.

Furthermore, the right of withdrawal is excluded (sub-para. i) with respect to the supply of sealed audio or video recordings or sealed computer software which have been opened after delivery, or (sub-para. m) with respect to contracts concluded at a public auction.

Another exception (sub-para. o) is for the supply of digital content (such as NFT) by means of a non-material medium (such as a private key for an NFT or other NFT redemption code) if performance has begun and, if the contract imposes an obligation on the consumer to pay, if three cumulative conditions are fulfilled: 

• the consumer has given his prior express consent to commence the performance during the right of withdrawal period;
• the consumer recognised that he thus lost his right of withdrawal;
• the trader has provided confirmation of the conclusion of the contract in accordance with the terms of Directive 2011/83/EU for distance contracts.

A possible solution to allow consumers to exercise their right of cooling-off could be found in the new NFT standard, which would guarantee their purchases against scams (better known as ‘rug-pulls’) as well as the possibility to ask for a refund in case of withdrawal before the deadline.

The term ‘rug-pull’ refers to a type of scam that generally occurs when the developers of a project, after creating the cryptographic token, increase its value in order to attract as many investors as possible, and then withdraw all funds and abandon the fraudulent project.

When speaking of a standard for NFT instead, one is reminded that it refers to the unique identification of a token with respect to others of the same smart contract, called ‘ERC-721’, introduced, as is well known, in 2017, by Ethereum, as the first protocol for the creation of NFTs and to date the most widely used, representing a unique and infungible asset.

The publication of a new anti rug-pull standard, ERC-721R, officially released on 11 April 2022 and aimed, among other things, at countering fraudulent NFT projects, could give the user a right to reconsider their purchase and, thus, be refunded the price paid for the minted NFT.

In particular, this mechanism takes place through a lien on the deposit of the sums placed as collateral by the smart contract. These funds can only be withdrawn, by the creators, after the lapse of a period of time (such as the 14 days for the right of withdrawal in off-premises purchases) that allows buyers to return their NFT and receive a refund from the signed smart contract.

This new standard represents a possibility both in terms of openness towards innovative solutions concerning the user’s right to rethink and the consequent exercise of the right of withdrawal, and in terms of a guarantee against certain fraudulent practices: although the purchase of NFT is irreversible, if during this period the creators decide to rug-pull, buyers will be able to request a refund of their funds by the end of the waiting period, losing only the gas fees incurred for transaction costs.

The use of such a new protocol for the generation of NFTs, besides being more advantageous for buyers, as it would limit possible losses to only the fees for processing and validating transactions on the blockchain, presents a real opportunity for commercial service providers to promote their businesses also in the cryptocurrency world, creating trust in the market and attracting more investors.