IT202100026213A1 - System for the creation and transfer of digital FIAT money based on blockchain - Google Patents

Description

1.3 DESCRIPTION

DESCRIPTION of the industrial invention with the TITLE ?System for the creation and transfer of digital FIAT money based on blockchain?

Field of application of the invention

The present invention fits into the field of digital currencies and allows you to exchange, without having a bank account, through the use of a decentralized public blockchain and a shared public register, in real time, FIAT currencies (such as the Euro, the British Pound, the American Dollar, etc). Offering security, reliability, privacy in operations, as well as a very low environmental impact.

As is known, there are different forms of currency transfer, which however have different operational limits.

The cash? the most shape? known, but has the limitation of being a means that can only be used in proximity, to which are added very high costs of printing, storage, distribution and replacement of worn banknotes.

Bank remittances, on the other hand, have the limitation of not guaranteeing the confidentiality of operations and therefore privacy. For instant transfers (e.g. SEPA) they can only be used in certain geographical areas (Europe) and are not accepted by all banks. Furthermore, they require the obligation to maintain a bank account, with limits on the maximum amount that can be transferred (for instant ones), expensive costs and particularly long times to complete transfers, especially for cross-border ones.

Then there are unanchored cryptocurrencies (e.g. Bitcoin), i.e. cryptocurrencies whose price is not ? fixed, but? given by market supply and demand. These, in some cases, are controlled directly by the issuer, so they are not transparent.

Furthermore, they are extremely speculative, with highly volatile prices, potentially manipulable and with a high environmental impact (e.g. Bitcoin Mining or Ethereum Gas).

Furthermore, they have very expensive transfer fees as well as? highly variable over time and unpredictable, why? dependent on external factors, non-instant transfers, security problems (the main one being that of double spending), risk of default/bankruptcy of the issuer, they are not instantly convertible with other types of FIAT currency (e.g. cash) without having an account banking, do not offer any purchase or fraud protection for buyers, as payments are irrevocable.

Then we find pegged cryptocurrencies (or stablecoins), i.e. those cryptocurrencies that have a nominal value equal to a FIAT currency (e.g. USD), which also have many limits because? they are controlled directly by the issuer (centralized) and therefore not transparent.

Furthermore, the issuer can ?print out? coins ad infinitum, having de facto absolute governance power.

They're not sure why? prone to attacks, transfer rates are often very high and transfer times are not instantaneous. They also have a strong environmental impact.

Aren't you? guarantee of the presence and consistency of the collateral to guarantee the "minted" coins, there is no truly independent and reliable third-party control, therefore there is a high risk of issuer bankruptcy.

Finally, they do not offer any protection to consumers in the event of a purchase (irrevocable payments) and present security problems, precisely because of the type of blockchain they use (mainly double spending, 51% attacks, DDOS, fake deposit, etc). However, all cryptocurrencies (pegged and unpegged) cannot be instantly converted into other forms of FIAT currency (e.g. at a Bank ATM and without having an account). In addition, there is no independent, reliable, non-alterable and verifiable control in real time regarding the exact amount of digital coins issued, which gives a certain guarantee on their reliability. some data.

Similarly, it does not exist even with reference to the corresponding equivalent value in reserves, made up of the same FIAT currency.

To make a digital currency risk-free, therefore safe and reliable, this equivalent value must always be ? 100% and must be immediately available and payable (therefore not tied or invested), as well as not subject to exchange rate risk.

Furthermore, all centralized systems allow the authority? which controls them to have absolute governance powers, therefore it can? print coins endlessly without there being evidence that these are guaranteed by collateral.

In other words, with regard to the known solutions, there is no system, procedure or process that is able to offer a certain guarantee that the amount of the digital currency issued is guaranteed and therefore covered by the same value in FIAT cash and therefore , that these solutions cannot face the risk of failure. In fact, in the event that everyone decided to reconvert the total digital coins in circulation. in FIAT money, if there is no? complete coverage, automatically the real value of digital coins? equal to zero, precisely why? the coins would no longer be guaranteed by collateral. Are there any known circumstances in which the authorities they investigated the consistency of these collaterals, discovering that there was no coverage to guarantee the digital currencies issued.

Furthermore, no known solution allows the network to govern very important processes and decisions such as the issuance of new money and the destruction of existing and excess money (Mining and Burning).

The known solutions do not allow instantaneous and autonomous (therefore simply via a web/mobile interface) and without the aid of an authorized bank or intermediary, to be able to create payment promises in FIAT digital currency such as sureties and letters of credit, to receive interest in FIAT currency on digital FIAT currency holdings, to request loans in digital FIAT currency, to lend digital FIAT currency to others in exchange for interest, to have purchase and fraud protection when used as a means of payment of physical goods and do not allow them to be converted in real time with other forms of FIAT currency.

Technical problem

Therefore, the technical problem that the present invention solves consists in making the total amount of FIAT digital currencies issued and circulating certain, irrefutable and non-modifiable, thus? as well as the related FIAT reserves (collateral) in order to make this solution financially and mathematically reliable.

This result is achieved with the help of decentralized and public blockchain technology, which allows the exact total of digital coins in circulation and the exact amount and consistency of the collateral to guarantee them to be verified.

Furthermore, the processes of issuing (minting) and destruction (burning) of the digital currencies object of the invention are decided and authorized by the network itself, only when certain conditions occur. Therefore, not even the broadcaster has the authority? to create new money or destroy the existing one.

With regard to the real existence, consistency and value of the collateral (reserves), these are kept by an authoritative third party and/or directly accessible by an authoritative third party and/or verifiable at any time by an authoritative third party. Therefore, if 1 is output? digital, are you? certainty that there is at least 1? FIAT deposited to guarantee the issue. In addition, the consistency of the collateral, so? such as the consistency of the digital currencies issued, ? however, it is always publicly accessible, cannot be modified in any way and complies with any type of verification, including by any Authority, at any time.

The issuance of new digital currency (minting) (Fig.19) is left to the decision of the network, which issues new money only when there is an objective and documented request. In other words, the network authorizes the printing of new digital currency only if? guaranteed by deposits in FIAT currency of the same amount. For example, if there 1? digital in circulation, this means that there is? certainly 1? FIAT registered. At this point, what if there was a need to print a further 5? digital, can you? to do only if there are 5 more in storage? FIAT. By the same principle, the destruction of excess digital currency is also possible. authorized by the network (Fig.20).

These characteristics make the digital currencies object of the invention absolutely risk-free, 100% guaranteed by legal tender value and therefore not subject to the risk of failure.

The invention therefore represents a new means of transferring and using money, as well as a new mode? payment both online and offline.

The main elements of the invention are (Fig 1):

1.The distributed network (1.1), composed of n.

computers/servers - the nodes of the network (1.13) - which communicate with each other via a Gossip protocol (13.3). The designated nodes, which participate in the consensus, are called validators.

2.Public decentralized blockchain technology (1.2);

3.The FIAT digital currency that is transferred via the network (1.3);

4.The shared/distributed public ledger (Distributed Public Ledger) which records and authenticates all transactions (1.4);

5.The registry consensus protocol (1.5);

6. Users' digital wallets (1.6) in which digital currencies are stored and exchanged and which also offer the possibility to convert the balances, immediately, with other forms of FIAT currency (Banknotes or bank reserve) (Fig.22,23,24,25,26,27,28)

This characteristic ? extremely innovative as it does not exist today in the state of the art.

7. The issuer's bank deposit(s) (1.7) (or bank account(s), in FIAT currency equal to that of the pegged digital currency, where the reserves to guarantee the digital currencies issued are stored and immediately due (collateral), and subject(s) to the control of the authorities.

8. The issuer's digital wallet (1.8) in which individual digital currencies are issued (printed) and distributed.

9. The real-time reporting system based on public decentralized blockchain technology - therefore unalterable and unchangeable - which publicly displays the total digital currency issued and in circulation (1.9), and that relating to stocks/collateral in FIAT currency (1.10) . Both compliant with every type of audit by third parties and/or authorities? certified, including public or government ones.

10. Any FIAT bank accounts (1.11), which are located outside the Blockchain.

11. The FIAT currency (1.12) which is transferred through the banking system, therefore external to the blockchain.

12. The Connection (1.14) between authorities? financial institution that holds the collateral deposited in the issuer's FIAT accounts (1.7) and the blockchain (1.2), which communicates in real time to the network (1.1) and to the register (1.4), the amount of reserves deposited in the issuer's FIAT accounts. issuer, updating the reporting system in real time (1.10).

13. The Connection (1.16) between the issuer's digital wallet (1.8) which holds the collateral deposited in the issuer's FIAT accounts (1.7) and the blockchain (1.2), which shows in real time to the network (1.1) and to the register (1.4), the amount of digital coins issued, updating the reporting system in real time (1.9).

14. The real-time report (1.18) showing the exact total of the digital currency issued (1.9), the FIAT collateral as collateral (1.10) and the related ratio (Ratio). The combination of the aforementioned elements, so? as described below, constitutes the system object of the invention capable of solving all the problems of the prior art.

System operation

The public and decentralized blockchain technology makes the system absolutely transparent, not centrally controlled and accessible by anyone.

The public ledger (Distributed Public Ledger) (1.4) ? shared and open to all. Everyone can be assured of its integrity, as it can be updated only according to very specific rules, predetermined by the consensus protocol (1.5). Each instance, therefore each single operation/transaction on the ledger, maintains a complete copy of the ledger and the peer-to-peer network of servers/computers (1.13) distributes the proposed transactions among them.

The consensus process determines which transactions are applied to each new version of the shared public ledger.

The public register? composed of a series of registers or register versions, which are distributed over the network.

Therefore, there are different versions of the same registry, but located in different locations on the network.

Each of these versions has an index that identifies the order in which it is created the registry or its version.

Registers can be ?Open?, ?Closed? or ?Validated?.

The server makes a distinction between open, closed and validated log versions.

Each server has only one open log, a variable number of closed but unvalidated logs, and an immutable history of validated logs. The registry never "closes" an open registry to convert it to a closed registry.

Instead, the server discards the open ledger, creates a new closed ledger, applies the transactions that were on top of a previous closed ledger, then creates a new open ledger, using the last closed ledger as a base.

This ? a consequence of how consensus solves the problem of double spending, since in this way there is? certainty that a transaction, isn't it? a duplicate of a transaction already? performed.

For an open ledger, transactions are applied in the order they appear, but different servers/computers may display transactions in different orders.

Therefore, servers may not agree on the exact order of recorded transactions, especially when these occur multiple times. or less at the same time.

For this reason, the process for developing a closed registry version that is eligible to be validated, ? different from the process of creating an open ledger based on transactions, sorted by the order in which they arrived.

To create a closed ledger, each server always starts with a set of transactions and a previous version, or ?parent? of the register.

The server places the transactions in a canonical (that is, rule-compliant) order, then applies them to the previous ledger in that order.

The canonical order? designed to be deterministic and efficient, as all transactions are placed in an order based on specific rules. Each server, therefore, will order? transactions in the exact same way as another, therefore in a deterministic manner.

Therefore, an open ledger is only used as a temporary workspace, which is the main reason why interim transaction results may vary from the final results.

Each registry version that is ?closed? it also has an identifying hash value, which uniquely identifies the contents of that register.

At any given time, a single instance contains a "current" and current open registry, as well as a number of closed registries that have not yet been approved for consensus, and a variable number of "historical" registries that have been validated for consent.

Only validated records are correct and immutable.

A single version of the registry? composed of more parts (Fig.15):

I. A header (15.1): the log index (5), hashes of other contents, and other metadata.

II. A transaction tree (15.2): the transactions that were applied to the previous ledger to create the current one. Transactions are the only way to change the ledger.

III. A state tree (15.3): All registry objects, which contain the settings, balances, and objects in the registry as of this version.

IV. The register index (15.5): the register index ? a 32-bit integer used to identify a register. The register index? sometimes known as the registry sequence number. The very first register? indicated with the index number 1 (Fig 14) and each new register will have? 1 compared to the previous index number (14.1). The register index indicates the order of the registers, the Hash value identifies the exact contents of the register (14.2). Two registers with the same hash are therefore two copies of the same register. For validated ledgers, the hash values and indexes of the ledgers are equally valid and correlated 1:1.

However, this is not true for ongoing logs, for the following reasons.

Two different servers can have different contents for a current log and with the same log index, due to latency in propagating transactions throughout the network.

Could there be more? closed registry versions that compete to be validated for consensus. These log versions have the same log index but different contents (and different hashes). Only one of these closed registers can? be validated,

The hash of the current open ledger is not calculated.

This why? the contents of a current register change over time, which would cause its hash to change continuously.

For this reason, even if its register index remains the same, the hash of a register, however, is calculated only when the register ? closed.

According to the characteristics described so far, therefore, a transaction? the only way to cause public registry changes.

Transaction results are final only if signed, submitted and accepted in a validated ledger version after the consensus process (15.4).

For this reason, therefore, the data present in the public register is absolutely reliable and reliable.

Then there are the registry objects.

The status data (15.3) of each version of the ledger is a set of ledger objects called ?entries?, which collectively represent all settings, balances and relationships at a given time.

To store or retrieve an object in state data, the protocol uses a registry object ID, which is unique to that object.

In this finding, the consensus process can? be summarized in a simplification of the problem.

So, consensus, makes a complex problem into a simple problem.

In fact, the most great technical limit of every transaction, regardless of whether it takes place via digital resources or traditional methods,? that of double spending. Which in other words, nothing else? that preventing the same sum from being spent more? times.

The public register therefore solves the problem of double spending, allowing more conflicting transactions to be in a group of transactions, agreed upon by all.

The group of transactions is executed according to deterministic rules; so any transaction comes first according to the sorting rules, succeeds and any conflicting transaction, comes second, and fails, hence fails. To give a practical example: Suppose Maria is 20? and would like to send them to Giorgio. The sending is successful because? Maria was actually in possession of 20?. What if Maria tried to send an additional 20? to Franco, this transaction would fail.

The set of all these deterministic rules, accepted and respected by all participants, is consent.

Does consensus work to improve integrity? of the system by preventing "double spending".

In traditional centralized payment systems (such as banks), an authoritative administrator has the final say on how and when transactions occur.

Decentralized systems, by definition, do not have an administrator to do this.

Instead, decentralized systems (like the one that is the subject of the invention) do not have an administrator but have a series of defined rules which are followed and respected by all participants, so that each participant can agree on exactly the same series of events and their final result at any time.

The consensus protocol that is the subject of this invention? a fault-tolerant Byzantine consensus mechanism, which means that it is designed to work even in the most demanding scenarios? critical, including attempts to attack and control the network by malicious actors.

Furthermore, the set of participants in the consensus protocol is not? never known in advance and can? change over time.

The properties? of the consensus protocol used in this invention are as follows:

I. All those who participate in the network, through the public register, can agree on the lowest balances? recent, on which transactions were executed and in what order;

II. All valid transactions are processed without the need for of a central operator; III. The public register can make progress, even if some network participants join, leave, or behave inappropriately;

IV. If too many participants are unreachable or behave inappropriately, the network fails to make progress (crashes), instead diverging or confirming invalid transactions;

V. Confirming transactions does not require wasteful or competitive use of resources, unlike most other blockchain systems;

These properties? are summarized with the following principles, in order of priority: Correctness, Agreement, Advancement.

The main purpose of consent? that participants in the process agree on which transactions are to be processed as a group, so? to solve the problem of double spending. Deterministic rules can also be used to form groupings, leading to disagreement only in borderline cases.

For example, if there are two conflicting transactions in a round (Fig 16), ? Is it possible to use deterministic rules to determine which one will be? included in the next round.

Therefore, the priority? absolute of each participant? correctness, followed by agreement.

To make sure that nothing violates the integrity? of the shared registry, ? It is necessary to have deterministic rules accepted by everyone but also that these are respected by everyone in the same way.

The invention is based on the correctness of the participants as a priority. absolute. The second priority? ? the agreement. Therefore, correctness and agreement are the two main characteristics of consensus.

The consensus group (or round) ? an attempt to agree on a group of transactions, so that they can be processed (Fig.16).

Each validator (16.1) proposes a set of transactions that must be included in the next version of the ledger.

If a particular transaction does not have the support of a majority of validators, participants agree to defer/postpone that transaction (16.3). If a particular transaction has majority support, participants agree to include the transaction (16.4).

Thus, small majorities quickly become full support and small minorities quickly become universal rejection from the current round.

To avoid consensus stopping near 50% and to reduce the overlap needed for reliable convergence, the threshold required to include a transaction increases over time.

Initially, participants continue to agree to include a transaction if more? than 50% of the other participants? agree.

If the participants do not agree, they increase this threshold, first to 60% and then even more? up, until all disputed transactions are removed from the current set.

All transactions removed in this way are carried forward to the next version of the ledger.

When a participant sees a majority that ? agree on the set of transactions to be processed, declares that ? consensus was reached.

Validation? based on trust, therefore? the fundamental principle underlying the consensus mechanism of the shared public registry, the subject of this invention.

Each participant in the network chooses a set of validators, which are servers specifically configured to actively participate in consensus, and which are managed by different entities, therefore, which are expected to behave honestly most of the time.

For the same reason, and even more? Importantly, each set of validators should not collude with each other to break the rules.

As the network progresses, each server listens to its trusted validators (a server does not need a direct connection to its trusted validators to listen to them), why? the peer-to-peer network of this invention uses a gossip protocol (13.3) in which servers identify each other via public keys and transmit/forward digitally signed encrypted messages from each other. The nodes communicate in parallel with each other and each of them communicates with one or more knots that for? are chosen randomly. (13.1 shows the centralized approach and 13.2 shows the fully connected and overlapping approach).

As long as a large enough percentage of them agree that a series of transactions should occur and that a given ledger is ? the result of this series of transactions, the server declares a consensus.

If they disagree, the validators modify their proposals to match as closely as possible. possible to those of the other validators they trust, repeating the process more? round until a consensus is reached.

This way, even if a small percentage of validators are not working properly at any given time and/or are not ? reachable, the system continues to operate.

Until? less than 20% of validators trusted? defective, the consensus can? continue without obstacles; and confirming an invalid transaction would require the collusion of more than 80% of trusted validators (highly unlikely scenario).

If for any reason there were a very large number of unreachable or faulty validators, the network stops making progress and therefore crashes instead of being subject to attacks or validating erroneous transactions. Can the consensus mechanism also fail, right? Perfect. Therefore, the odds? that a failure in consensus occurs cannot be reduced to zero, but can be made significantly irrelevant.

There? What makes the difference instead? the way consensus failure is handled.

In the proposed invention, this issue is handled in this way: after the completion of a consensus round, each participant applies the set of transactions that it believes have been agreed upon.

There? translates into the construction of what? which they believe should be the next state of the public record.

Participants who are also validators then post a cryptographic fingerprint of this subsequent ledger, called a ?validation vote? (15.4).

If the consensus round is successful, the vast majority of honest validators should publish the same fingerprint.

Participants then collect these validation votes.

From validation votes, they can determine whether or not the previous consensus round resulted in a majority of participants agreeing on a set of transactions.

The participants therefore find themselves in one of three cases, in order of probability:

- They built the same public register agreed upon by the majority.

In this case, they can consider that registry fully validated and rely on its contents.

- They built a public register different from the one agreed upon by the majority. In this case, they must construct and accept the register of the absolute majority. This typically indicates that they declared consensus early and that many other participants changed later. They must then "jump" to the absolute majority register to resume operations.

- No majority? clear from the validations received. In this case, the previous consensus round ? been wasted and a new round must occur before any log can be validated.

The first case? the most common, the second does not damage the network in any way which would work without any problem.

The last case causes the network to lose a few seconds in which it could have made progress, since it has to repeat the consensus round, but this scenario is correct. extremely rare.

In this case, ? however, it is much less likely that the next round of consensus will fail because? disagreements are resolved in the consensus process, and only remaining disagreements could cause failure.

On rare occasions, the network as a whole fails to make progress for a few seconds.

In exchange, the average transaction confirmation times are almost instantaneous and this makes overall times almost instantaneous.

In other words, with this mechanism, the proposed invention is can detect a failure in consensus and handle it.

The ledger uses a consensus protocol, where designated servers (validators) agree on the order and outcome of transactions every 0.1-5 seconds.

All servers on the network process every transaction according to the same rules, and any transaction that respects the protocol is immediately confirmed.

All transactions are public, with strong encryption, to ensure integrity. of the system.

A sistem ? reliable as it provides results even if some components do not work.

In the case of digital currencies? the capacity? of a system to produce results on which one can? rely.

Part of the ledger's design philosophy, ? detect the conditions in which the reliability? of the results? compromised and report them, rather than providing results on which one cannot? rely.

The data is therefore absolutely reliable - why? - how? Was the system conceived and for the methods? operational of the registry consensus algorithm, on the one hand offers a solid alternative to POW (proof-of-work) systems, without consuming computational resources unnecessarily, on the other hand, it always produces reliable results. In fact, when the data, for any reason, is not available, the entire network stops rather than being subject to attacks or progressing with errors and unreliable data.

The consequence ? that, only in these cases there may be small delays in the processing of transactions but, in all cases, the register's consensus algorithm reports the results as reliable only when they actually are.

Therefore on the reliability? of the data, through this invention, there is? mathematical certainty.

The set of all the processes described constitute the system which is the object of the present invention, which is capable of detecting failures / failures and managing them so that they cannot alter data and/or damage the network. The proposed invention? therefore characterized by the fact that it can? be used to transfer resources, (even without having a bank account), by any type of user (private, business, government) and for any type of payment, both online and off-line. The processes for completing a payment/transfer are described in Fig.8, and can be performed either using desktop/laptop devices (8.15) and/or mobile/tablet devices (8.14). To transfer digital assets from user A (8.1) to user B (8.2), the digital assets will then be transferred (8.5) from the digital wallet (8.3) to the digital wallet (8.4). If the process is performed from a desktop/laptop (8.15), a web interface of the wallet is opened on the desktop device (8.6), if the process is performed from a mobile/tablet (8.14), it is opened the mobile interface of the wallet, directly on the mobile device (8.7); The recipient's wallet address is entered or a QR code is scanned (where to send the payment) (8.8); The amount to be sent is entered (8.9); In the case of a mobile device (8.14), the operation is authorized/signed directly via the App/wallet interface (via pin or biometrics, etc.), directly on the mobile device (8.10); In the case of a desktop device (8.15), a QR Code is displayed on this device which is used to authorize the transaction. This QR Code is scanned on the desktop/laptop by the smartphone where? the user's digital wallet is present (8.11). The transaction is authorized via the mobile interface (8.12), The transaction is processed (8.13).

The total digital currency issued and circulating? visible in real time (1.9), by anyone, directly via the blockchain. This ? possible thanks to a series of direct and indirect connections (1.16,1.17,1.22) between the issuer's wallet (1.8) and the public register (1.4), which return values to the network in real time. Similarly, the value of the balances relating to the collateral (1.10) held in the issuer's FIAT accounts (1.7) are also communicated in real time and automatically to the network.

This ? possible through the establishment of a series of direct and indirect connections (1.14,1.15,1.21), between the entities? financial institutions that store collateral and the public register, which return values to the network in real time; All transactions are public, updated in real time and visible to anyone. Likewise, the balances of each wallet and all transactions carried out.

Furthermore, the ratio between collateral (1.10) and digital currency issued by the issuer (1.9) is shown publicly and in real time (1.18), which will be? always at least 1:1, therefore the collateral will always be greater than or equal (?) to the total digital currency issued.

Digital wallets (1.6) are not associated with the owner's personal data, therefore, they are totally anonymous in order to guarantee the privacy of operations. The balances and transactions of each individual wallet are public and visible on the blockchain, but not? known who the owner of that wallet is.

In addition, through procedures, ? provided that the collateral, therefore the reserves that guarantee the digital currency issued, can only be kept (1.7) by an authoritative third party and/or that are directly accessible to an authoritative third party and/or that can be verified at any time by an authoritative third party. Not ? It is therefore possible for the issuer to deposit collateral that is not accessible and/or verifiable and/or supervised by authorities. independent and authoritative, if these do not allow a connection between the issuer's bank accounts where the collateral is kept and the network (1.14,1.21), so that? the actual amount is made public and verifiable by anyone (1.10).

Stability? of the price of the digital currency, is created through automatic processes of inserting purchase and sale orders, 1 tick from the reference price (therefore at the first value close to that price), by automated bots (9.5). In the example in Fig.9, you can see that at the exchange (9.1), two pairs of digital currencies are traded: The Digital Euro/EUR pair (9.3), where the exchange price is ? 1?.

Bots place buy orders at 0.99999? and sell orders at 1.00001?, thus keeping the price stable at 1?. The Digital Euro/USD pair (9.4) is instead trading at 1.11USD. The price ? the same as the EUR/USD pair (9.6), at the official exchange rate at that given moment (9.2). The bots then replicate the official rate, placing buy orders at $1.10999 and sell orders at $1.11001, thus maintaining the price identical to that of the official exchange rate (9.2). The bots adjust the prices of the orders over time, adapting to the variations in the official exchange rate (9.2) of each pair, thus replicating the same exchange rates of the FIAT pairs, with the same pairs in which there is? the same currency, but digital.

The currency of the FIAT collateral, which guarantees the digital currency issued and which is deposited in the issuer's bank account (1.7), can only be of the same currency. So, for example, for the digital Euro issued, the collateral will be exclusively in Euro (10.1). Other types of collateral and/or other currencies are inhibited by the system through a verification and blocking process (Fig.10).

The issuer's bank accounts (1.7), where the collateral to guarantee the digital currency issued is stored, through operational blocking processes, are inhibited from any use other than mere deposit. Therefore, it won't be? It is possible to use the aforementioned sums, for example, for investments or purchases of financial instruments, thus guaranteeing immediate collectability. and at any time, of the aforementioned sums.

The processes of issuing (Fig.19) and destruction (Fig.20) of the digital currencies object of the invention are decided and authorized by the network itself, only upon the occurrence of certain conditions and through well-defined processes: As regards Minting ( issue), in the example you can see in T1 that the bank wants to convert 1000? FIAT in 1000? digital (19.1); In T2: does the bank send the 1000? FIAT to the broadcaster (19.2); At this moment for? Aren't there 1000? digital available from the issuer (19.3); The ratio between collateral and circulating digital currency? 1000:0 (19.4), as there are 1000 that guarantee 0 digital currency (therefore there is an excess of collateral and a shortage of digital currency). In this condition, the network authorizes the printing (minting) of 1000 Digitals, as there are 1000? of collateral FIAT already? available and there aren't 1000? digital that can be sent to the bank; In T3: The broadcaster prints 1000? digital (19.5). This operation immediately updates the total circulating digital currency (19.6) which goes from 0 to 1000; At this moment the ratio between collateral and digital currency issued? 1:1 (19.7). In fact, there are 1000 in circulation? digital, guaranteed by 1000? FIAT Deposited; In T4: the issuer sends the 1000? digital to the bank (19.8). As regards Burning (destruction), in the example we see in T0, a situation in which the circulating digital currency (20.3) is totally guaranteed by FIAT reserves (20.4). So there? a ratio of 1:1 (20.2). The 1000? digital cards issued are in the possession of the bank (20.1); In T1: Does the bank want to reconvert 1000? digital in 1000? FIAT, therefore, the bank sends the 1000? digital to the broadcaster (20.5). In T1, therefore, the digital currency issued? always guaranteed, but all that in circulation? in the possession of the issuer; In T2 the issuer sends the 1000? FIAT to the bank (20.6). Therefore at this moment the relationship is ? 0:1000 (20.7), which means there are 0 collateral collateral for 1000? digital cards issued (and which are available to the issuer), therefore? it is necessary to destroy the digital currency that is not? guaranteed by collateral, as there is? an excess of digital currency; in T3, based on this factual data, does the network authorize the burning of the 1000? digital (20.8). The total in circulation goes from 1000 to 0 (20.9) and the ratio goes to 0 (20.10) as there are 0 digital coins and 0 guarantees. All these values are publicly visible and in real-time. Through the above processes, not even the issuer has the authority? to create new money or destroy the existing one, but the printing and destruction decisions are authorized by the network, which is always based on certain and factual data that justify the need. In other words, the network authorizes the printing of new digital currency only if? guaranteed by deposits in FIAT currency of the same amount. Likewise, it destroys excess digital currency, for the amount that is not available at a given moment. guaranteed by collateral. Thanks to these processes, the ratio between digital currency issued and collateral is always maintained at a ratio of 1:1.

Therefore, the aforementioned invention returns certainly reliable data. The digital currencies issued (4.1) have the same value (4.3) as the FIAT currency (4.2) to which they are anchored (therefore there is no exchange risk and/or speculation), they are financially and mathematically covered by immediately payable collateral, in the same currency (therefore no risk of exchange and/or bankruptcy) and kept by an authoritative third party who certifies the exact amount (4.5). Furthermore, all this data is always visible to the public and in real-time (4.8).

Therefore, all these characteristics make the FIAT digital currencies object of the aforementioned invention financially reliable and in a certain, irrefutable, mathematical way.

The proposed invention also resolves the limitations of the prior art, introducing an innovative process in a crypto field, where by definition, all payments are irrevocable: Purchase and fraud protection for consumers. Through the process described in Fig.17, in fact, when a payment is made by a user (17.1) to another (17.2), for the purchase of physical/tangible goods (17.5); The sum is not sent directly to the recipient (17.2), but a third party is inserted, the escrow user (17.7), who manages a special wallet, the escrow wallet (17.8). The original payment is then sent (17.6) to the escrow wallet (17.8), from the payer's wallet (17.3. The digital sum remains blocked until the physical goods are delivered and delivery control occurs automatically through connections with the shippers Only after the actual delivery of the physical goods and only if the user (17.1) does not initiate a dispute/complaint, the payment is released from the escrow wallet (17.8) to the recipient (17.2), in his digital wallet (17.4) .

Digital wallets (1.6) also allow the holder to create letters of credit / sureties / guarantees - including international ones - and guaranteed by digital FIAT currency, instantly, in total autonomy on the part of the user and without going to a bank . These can be created directly via the wallet interface. In other words, ? It is possible to create an irrevocable digital document, which is similar to a unilateral promise of payment, such as a ?stand-by letter of credit SBLC? or similar, therefore, a certain credit. The processes for creation are depicted in Fig.6, where the payment between two subjects (6.1) and (6.2) ? subject to the occurrence of certain conditions established between the parties. The subject (6.1) sends the sum from his digital wallet (6.3) to the escrow wallet (6.8), which is managed by the escrow user (6.7) and which is in contact with both parties, the payment is released from the escrow (6.7) to the user (6.2) and in his digital wallet (6.4), only upon the occurrence of the condition(s) previously agreed between the two users. The flow of digital payment when the condition? satisfied? (6.6); If the condition is not met, the payment returns to the payer (6.5).

Digital wallets (1.6) also allow the owner to invest the digital FIAT currencies in his possession, lending them to more persons and in small amounts, against the payment of interest in digital FIAT currency. Thus, the system allows it to be used as a means of investment for lenders and as a means of obtaining credit for applicants. The processes that allow the system to achieve this result are depicted in Fig.11. In the figure, 3 applicants (11.1,11.3,11.5) and 3 lenders (11.13,11.15,11.17) are simulated. In the trial it is clear that the applicant 3 (11.5) ? result worthy of credit. The flow shows that the three lenders send 50? Digital to the warranty wallet (11.11) which, therefore, will have? a total of resources equal to 150? Digital. Applicant 3 (11.5), which is? result worthy of credit after the credit check, therefore bankable, he receives the payment of the loan (11.10), in his digital wallet (11.6) which, in the example, is of 150? Digital. The aforementioned 150? Digitals are transferred from the warranty wallet (11.11) to the requester's wallet 3 (11.6). Will this be reimbursed monthly? to the warranty wallet the monthly installment (11.9), including interest. At the end of the period you will have refunded (for example) 10? Digital per month x 16 months = 160? Digital. In the warranty wallet (11.11) there will be? so the sum of 160? Digital. Lenders (11.13,11.15,11.17) will have monthly refunds, in their respective digital wallets (11.12,11.14,11.16) including interest which, at the end of the period will have generated total refunds of ?53 Digital each. So, 50? Will it be digital? their initial investment and ?53 Digital ? the total reimbursement to individual lenders. The following elements are also represented in the figure: (11.7) loan request declined; (11.8) loan request accepted.

Digital wallets (1.6) also allow the holder to request instant digital FIAT currency loans. The processes are depicted in Fig.12 where two different cases are visible: A loan request based on creditworthiness (therefore with credit check) and one based on the guarantees of other cryptocurrencies (without credit check). In the loan request based on creditworthiness, the user who requests a loan and who, after the credit check, is not result worthy of credit, will you have? a declined loan request (12.8). The user (12.1) who instead, is result worthy of credit, will you have? an accepted loan request (12.7) which in the example is? of 200?; The loan is disbursed (12.9) directly to your digital wallet (12.3) from the Lender Wallet (12.5), to which the 200 are transferred? requested for a loan. The user will refund monthly (12.10), to the Lender wallet (12.5), the total loan is more? interest, which at the end of the period will be? of 200? interests. In the loan request guaranteed by collateral in other cryptocurrencies and without credit check, the user (12.2) who wants to request a loan guaranteed by collateral in cryptocurrency; In the example in Fig.12, he decides to borrow 75?. Can you? request a loan of a maximum of 50% of the value of the collateral that will be deposited as collateral; Therefore, by providing collateral in cryptocurrencies which, at current value, are worth double the sum requested. In the example 150?. The user transfers them (12.11) to the Escrow wallet (12.6) and when the collateral has been deposited, the Escrow wallet (12.6) communicates to the Lender wallet (12.5) the actual custody of the collateral (12.13). The loan is disbursed (12.9) from the Lender wallet (12.5) to the user's wallet (12.4). As time passes (12.14), two situations can occur: A) in the case of automatic liquidation of collateral (if these have lost value over time and their value approaches the value of the loan disbursed), the system will automatically sell? these collaterals, repaying the entire loan plus any unpaid interest to the lender wallet (12.5) and returning any excess (12.10), sending it to the user's wallet (12.4); B) In the event that automatic liquidation does not occur (12.12), it will be? the user decides how much and when to repay the loan, continuing to pay daily interest until he decides? to repay the loan (totally or partially) (12.15).

Digital wallets (1.6) allow the owner to make available his possessions in digital FIAT currency or part of them, for a certain time defined by him, obtaining potential quantities? of additional coins (interest). The process of operation? represented in Fig.21. In the example, the user has 1000? digital in his wallet (21.1) and through the wallet interface, he decides the amount to block and the time, visualizing what it will be? the amount of daily interest that will be paid to him. So does the Staking period begin (21.4), deciding to block 500? for 30 days, in exchange for 30? of total interest. The user will have the figure he defined (500?) which will be? blocked for the entire period (21.2), while the excess sum of its balance (500?) will be? usable (21.3). The blocked sum is transferred (21.5) to the lender wallet (21.6). The lender wallet, ? the same wallet that I will then lend? through borrowing to users (Fig.12). At this point (21.7), if the staking period is ? still active (21.8) the user is paid daily interest, 1? (21.9) directly into your wallet (21.1) and for the entire period of the digital sum being blocked. What if the staking period is ? termianto (21.10), the user is returned the amount (21.11) in his wallet (21.1), therefore 500?.

Finally, digital wallets (1.6) also offer the possibility? to convert FIAT digital currencies, immediately, with other forms of FIAT currency (Banknotes, bank reserves, central bank reserves) and vice versa. The processes vary based on the type of conversion to be performed and are they so? grouped:

- Conversion from cash (banknotes) to FIAT digital currency (via bank and postal ATMs) (Fig.22): The user, without inserting a credit/debit card and without entering any PIN (22.1); Initializes the conversion operation on the ATM display (22.2); scan the QR Code of your wallet via the ATM which is? can be generated immediately and available via the wallet interface/App which is installed on the user's smartphone. Then the ATM, using a camera, scans this QR code from the user's phone (which is nothing other than the address where the digital coins will be transferred, therefore the user's wallet) (22.4); The user enters the amount he wants to convert into digital currency (22.6); Inserts the same sum in cash into the ATM (22.7); Authorizes/signs the operation via App/wallet interface (via pin or biometrics, etc) (22.8); If the transaction is not correctly authorized for any reason, the ATM returns the cash (22.13); However, if it is authorised, the bank (which has its own digital wallet with digital currency deposits) automatically transfers the same amount in digital currency to that wallet (22.9). The cash is held via the ATM (22.11). . - Conversion from FIAT digital currency to cash (banknotes) via bank and postal ATMs) (Fig.22): The user, without inserting a credit/debit card and without entering any PIN (22.1); Initializes the conversion operation on the ATM display (22.3); The user scans the QR Code via the phone, which will be shown on the ATM display. The ATM QR Code is then scanned by the user's phone (this QR code is nothing other than the address where the digital coins will be transferred, therefore the Bank's wallet) (22.5); The user enters the amount he wants to convert (22.6) and begins the transfer process; Authorizes/signs the operation via App/wallet interface (via pin or biometrics, etc) (22.8); If the transaction is correctly authorized, the digital currency is transferred from the user's wallet to that of the Bank (22.10); The same sum in cash is then delivered to the user via the ATM (22.12);

- Conversion from Cash (Banknotes) to FIAT Digital Currency (At any bank/post office branch and even without a current account) (Fig.23): The user delivers the banknotes to the branch employee (23.1); The bank employee scans the QR CODE of the user's wallet (23.3) and begins the transfer operation; The employee keeps the cash (23.5); The employee authorizes/signs the digital transfer operation via the App/wallet interface (via pin, biometrics, etc) (23.6); If the transaction ? authorized, the same digital sum is transferred from the bank's Wallet to that of the user (23.7);

- Conversion from FIAT Digital Currency to Cash (Banknotes) (At any bank/post office branch and even without a current account) (Fig.23): The user scans the QR code of the bank's wallet, provided by the branch employee (23.2 ); The user sends the digital amount from his wallet to the bank's wallet (23.4); The user authorizes/signs the digital transfer operation via the App/wallet interface (via pin, biometrics, etc) (23.6); If the transaction ? authorized, the digital currency is automatically transferred from the user's wallet to that of the Bank (23.8); The same sum in cash is delivered by the employee to the user (23.9);

- Conversion from Cash (Banknotes) to FIAT Digital Currency (At physical points of sale) (FIG.24): The user delivers the banknotes to the point of sale staff (24.1); The point of sale staff scans the QR CODE of the user's wallet, where the same amount of digital currency can be sent (24.3), directly from the user's smartphone; The store staff holds the cash (24.5); The point of sale staff begins the digital transfer operation, authorizing/signing the operation via the App/wallet interface (via pin, biometrics, etc) (24.6); If the transaction ? authorized, the digital sum is transferred from the store's Wallet to that of the user (24.7);

- Conversion from FIAT Digital Currency to Cash (Banknotes) (At physical points of sale) (FIG.24): The user scans the QR code of the point of sale wallet, provided by the point of sale staff (24.2); The user begins the digital transfer operation from his wallet to the point of sale wallet (24.4); The user authorizes/signs the operation via the App/wallet interface (via pin, biometrics, etc) (24.6); If the transaction ? authorized, the digital currency is transferred from the user's wallet to that of the point of sale (24.8); The same amount of cash is delivered to the user by the store staff (24.9);

- Conversion from FIAT bank reserves into FIAT digital currency (via your bank's home banking/app)(FIG.25): The user accesses his Home Banking and decides the quantity? of FIAT currency in stock on his account and available, which he wishes to convert into Digital currency (25.1); The user enters the address or scans the QR CODE of the wallet where to send the converted digital currency (25.3); The bank begins the digital transfer operation from its wallet to the wallet indicated by the customer (25.5); The bank automatically authorizes the digital transfer (25.7); If the transaction ? authorized, the bank sends the aforementioned amount of Digital Currency from its wallet to that of the customer (25.8); the bank withholds the same FIAT amount from the user's current account (25.10);

- Conversion from FIAT digital currency into FIAT bank reserves (via your bank's home banking/app)(FIG.25): The user, through his digital wallet, decides the amount of digital currency he wants to convert into FIAT (25.2) ; The user enters the address or scans the QR CODE of his bank's digital wallet, where to send the digital currency and begins the transfer process from his digital wallet to that of the bank (25.4); The user authorizes/signs the operation via the App/wallet interface (via pin or biometrics, etc) (25.6); If the transaction ? authorized, the digital currency is automatically transferred from the user's wallet to that of the Bank (25.9); The bank credits the same FIAT amount to the customer's account (25.11);

- Conversion from bank reserves to FIAT digital currency (at the counter of your bank/post office or any other - even if you are not a customer) (FIG.26): The user goes to the bank counter (26.1); The user decides the amount of FIAT money to convert into digital currency, from what he has available in his bank account (26.2); Self ? bank customer, the bank checks the availability? FIAT on the Customer's account (with them) and sees if it has this amount available (26.5); If not ? customer of that bank (26.4), ? the customer's bank (26.6) to confirm to the bank where the customer is carrying out the conversion, whether it has that amount available, returning the result (26.7); If it has enough funds, the bank enters the address or scans the QR CODE of the customer's wallet, where the customer wants to send the converted digital currency, which is? provided by the customer himself (26.8); The bank begins the transfer of the digital sum from its digital wallet to the wallet requested by the customer (26.9); Authorizes the operation automatically (26.10); If the transaction ? authorized, the bank withholds the same FIAT amount from the user's current account (26.11); If for? the customer had a FIAT account with another bank (26.4), that bank reimburses the same digital amount to the bank that performed the conversion, advancing the digital currency to the customer (26.12); - Conversion from FIAT digital currency to bank reserves (at the counter of your bank/post office or any other - even if you are not a customer) (FIG.26): The user goes to the bank counter (26.1); The user decides the amount of digital currency to be converted into FIAT currency (26.3); Self ? a customer of that bank, the user scans the QR Code of the bank's wallet via smartphone (provided by the operator at the counter) (26.14); If not ? customer of that bank, The user scans via smartphone the QR Code of the wallet of the bank where he has the FIAT current account, provided by his bank (26.15); The user begins the digital currency transfer operation from his wallet to that of the bank (26.16); The user authorizes/signs the operation via the App/wallet interface (via pin, biometrics, etc) (26.17); The bank immediately credits the same FIAT amount to the user's current account (26.18);

- Conversion from bank reserves to FIAT Digital currency (directly through the issuer, Exchanges, stock exchange operators, etc) (FIG.27): The user decides the amount of FIAT currency to be converted into Digital (27.1); The user sends the FIAT currency to the operator, in his FIAT account (27.3) and indicates the address of the wallet where to receive the same digital sum; The operator retains the FIAT sum (27.5); The operator begins the transfer operation of the same digital amount from his wallet to the one provided by the customer (27.7); The operator authorizes/signs the operation via the App/wallet interface (via pin or biometrics, etc) (27.8): If the transaction is ? authorized, the user will have received the digital sum in the reported wallet;

- Conversion from FIAT Digital Currency to Bank Reserves (directly through the issuer, Exchanges, stock exchange operators, etc) (FIG.27):

The user decides the amount of digital currency to be converted into FIAT (27.2) and informs the operator of the account where to send the sum converted into FIAT; The operator informs him of the wallet where he must send the digital sum (27.4); The user begins the digital transfer operation from his wallet to that of the operator (27.6); The user authorizes/signs the operation via the App/wallet interface (via pin or biometrics, etc)(27.8); If the transaction ? authorized, the operator will have received the digital sum in the reported wallet; The operator sends the same amount in FIAT currency to the bank account indicated by the user (27.9);

- Conversion from reserves of national/central banks to FIAT digital currency (directly through the issuer) (Fig.28): The central/national bank decides the amount it wants to convert from FIAT to digital and the issuer indicates to which account FIAT bank make the deposit (28.1); The central/national bank deposits the amount in FIAT currency in the issuer's accounts and indicates which digital wallet to receive the same digital sum (28.2); When is the deposit? occurred correctly (28.3); The issuer begins the digital transfer operation from its wallet to the one provided by the central/national bank (28.4); The issuer authorizes/signs the operation via App/wallet interface (via pin or biometrics, etc) (28.5); If the transaction ? authorized, the central/national bank will have? received the digital sum in the reported wallet;

- Conversion from FIAT Digital Currency to National/Central Bank Reserves (directly via the issuer) (Fig.28): The Central/National Bank decides the amount it wants to convert from digital to FIAT and the issuer tells it which wallet deposit the same digital sum (28.6); The central/national bank begins the digital transfer operation in the issuer's wallet and informs the issuer on which FIAT account to receive the same amount in FIAT currency (28.7); The Central Bank authorizes/signs the operation via App/wallet interface (via pin or biometrics, etc) (28.8); If the transaction ? authorized, the issuer will have received the digital sum in the reported wallet; The issuer transfers the same amount in FIAT currency to the bank accounts of the central/national bank (28.9).

Brief description of the drawings (+ examples)

In Fig.1 ? schematically represented the ecosystem object of the invention and its main characteristics, in order to facilitate its understanding. The main elements are: (1) The distributed network, composed of n. computers/pc/servers(Nodes) (13), (2) Public decentralized blockchain technology. (3) The digital currency that transits/is transferred through the network (Digital Currency), (4) The shared/distributed public ledger (Ledger) that records and authenticates all transactions and where all account balances are updated (Digital Wallets /Wallets), (5) the registry consensus protocol, (6) Users' digital wallets (Wallets), where digital currencies (3) are stored, deposited, exchanged and where, via an interface (App/web /mobile), there ? access to features? and additional features, (7) The bank deposit (bank account) in FIAT currency equal to that of the anchored digital currency, where the reserves to guarantee the digital currencies issued (collateral) are stored and immediately payable, (8) The digital wallet of the issuer (Issuer wallet), where the individual digital currencies are issued (through the minting process) and destroyed (through the burning process), stored, blocked, lent and distributed, (9) The reporting system actually time and based on public decentralized blockchain technology - therefore unalterable and unchangeable - which publicly displays the total digital currency issued/circulating (total supply), (10) The real-time reporting system is based on public decentralized blockchain technology - therefore unalterable and unchangeable - which certifies the total consistency of the corresponding FIAT reserves, (18), the ratio (ratio) between collateral (10) and digital currency issued by the issuer (9) which is displayed in real time, thanks to the establishment of a series of links (14,15,16,17,19,20,21,22), which will be? always at least 1:1, (11) Any bank accounts, (12) The FIAT currency that transits/is transferred through the banking system, therefore external to the blockchain (FIAT Currency).

Fig.2 shows an example of conversion between digital currency and FIAT currency, showing the payment flows from FIAT Currency to FIAT Digital from User B to Bank A. The other elements in Fig. they are: (1) the Network, (2) Blockchain, (3) digital currency, (4) the public registry, (5) the Consensus Protocol, (6) the digital wallet, (7) the FIAT account of the issuer, (8) the digital wallet of the issuer, (9) the amount of digital currency issued in real time, (10) the amount of FIAT reserves in real time, (11) the bank account, (12) the currency FIAT, (13) PCs/Servers/Nodes.

Fig.3 schematically represents the difference between centralized and decentralized ledgers.

In Fig.4 ? Reliability is represented schematically. financial statement of the proposed invention. The above figure shows that the digital currency object of this invention (1) always has an identical nominal value (3) to the FIAT currency (2) to which ? anchored. So, in the example, 1? FIAT? always equal to 1? digital. Even the quantities? of digital currency in circulation and that of FIAT currency as collateral (collateral), are identical (5). So, every 1? Digital? always guaranteed by 1? FIAT. (7) shows the ratio, which ? always 1:1 and what does it mean that the digital currency issued? 100% Covered by collateral. (6) The result? what the system? absolutely transparent, no risk of issuer insolvency. The amount of digital coins in circulation and the amount of FIAT reserves (collateral) are public and 100% real. All this information can be immediately verified by anyone at any time and is unalterable and non-modifiable (8). The result ? what the system? reliable and safe.

In Fig.5 ? The Standard payment flow scheme is represented, in the case of purchasing products using the current known cryptocurrencies. In the figure ? present user A (1), user B (2), A's digital wallet (3), B's digital wallet (4), the physical goods (5) and the cryptocurrency (6).

Fig.6 shows the operating flow of payment promises/guarantees (letter of credit, etc.). The elements of the figure are: (1) user A, (2) user B, (3) A's digital wallet, (4) B's digital wallet, (5) the payment flow when the condition Not ? satisfied, (6) the payment flow when the condition is ? satisfied, (7) the escrow user and (8) the escrow wallet. In the example we see that the sum covered by the credit promise remains "blocked" in the escrow wallet (8), until the conditions defined between the two users are met. When these are achieved, the transfer from the escrow wallet (8) to that of the beneficiary (4) is processed.

In Fig.7 ? Schematically represented is an example that includes different types of payments and transfers between different entities? (of different types, private, business and government), which demonstrates how this invention can be used by any user and for any type of resource transfer. At the top of the figure (in green), ? also concretely visible is the reporting system for the circulating digital currency, collateral and the related ratio (1.18). The elements of the figure are: The issuer (1), the issuer's digital wallet (2), the issuer's FIAT deposit account (3), the public register (4), the real-time consistency of the amount of digital currency and FIAT currency as collateral (5.6). Following, there are several other entities? with their related digital wallets and FIAT deposit accounts. Including central banks (7), exchanges (10), private banks (13), public banks (16), national banks (19), end users (22), companies (25), central government administrations (28), peripheral government (31).

In Fig.8 ? is the sequence of actions (process) to be performed to complete a transfer between two entities represented? different in digital currency (5). The sequence of actions that Alpha (1) must perform to send a certain sum to Beta (2) is shown, whether this payment is made via desktop/laptop (15) or mobile/tablet (14) devices. As can be seen, the payment starts from Alpha's digital wallet (3) and arrives, after a series of operations, in Beta's wallet (4). Item (6) can only be performed from desktop/laptop: Opening a web interface. (7) is performed from mobile/tablet: opening the wallet mobile/app interface. (8) enter the recipient's wallet address or scan a QR code of the address (where to send the payment); (9) enter the amount to send; (10) the transaction is confirmed; (11) scan the QR code from the desktop/laptop with the smartphone; (12) the transaction is authorized via the wallet mobile interface/app; (13) the transaction is processed;

In Fig.9 ? represented the process that allows the price of digital currencies to always be stable and anchored to the FIAT currencies to which they are linked. This stability? it is created through automatic processes of entering buy and sell orders, 1 tick from the reference price (therefore at the first value close to that price), by automated bots (5). In the example, you can see that at the exchange (1), two pairs of digital currencies are traded: The Digital Euro/EUR pair (3), where the exchange price is? 1?. Bots place buy orders at 0.99999? and sell orders at 1.00001?, thus keeping the price stable at 1?. The Digital Euro/USD pair (4) instead trades, for example, at 1.11USD. The price ? the same as the EUR/USD pair (6), at the official exchange rate at that given moment (2). The bots then replicate the official rate, placing buy orders at $1.10999 and sell orders at $1.11001, thus maintaining the price identical to that of the official exchange rate (2). The bots adjust the prices of orders over time, adapting to changes in the official exchange rate (2) of each pair.

In Fig.10 ? represented the process of verifying the currency correspondence between the FIAT collateral deposited in the issuer's bank account (1.7) and the digital currency issued (1.3), which can only be of the same currency. As visible, the Digital Euro (1) will be able to have collateral only in Euros, The Digital Dollar (2) only in Dollars, the Digital British Pound (3) only in British Pounds, and so? away for all other currencies (4). Other types of collateral and/or other currencies are inhibited by the system through a verification and blocking process.

In Fig.11 ? graphically represented an example flow of use of P2P lending (social lending) through the proposed invention. In the example, 3 applicants (1,3,5) and 3 lenders (13,15,17) were simulated. In this specific case, only the applicant 3 (5) ? result worthy of credit. The flow shows that the three lenders send 50? Digital them to the warranty wallet (11) which, therefore, you will have? a total of resources equal to 150? Digital. Applicant 3 (5), who after credit check ? result worthy of credit, therefore bankable, receives the payment of the loan (10), in his digital wallet (6) which, in the example, is of 150? Digital. So, said 150? Digitals are transferred from the warranty wallet (11) to the requester's wallet 3 (6). Will this be reimbursed monthly? to the warranty wallet the monthly installment (9), including interest. At the end of the period you will have refunded (for example) 10? Digital per month x 16 months = 160? Digital. In the warranty wallet (11) there will be? so the sum of 160? Digital. Lenders (13,15,17) will have monthly reimbursements, in their respective digital wallets (12,14,16) including interest which, at the end of the period will have generated total reimbursements of ?53 Digital each. So, 50? Will it be digital? their initial investment and ?53 Digital ? the total reimbursement to individual lenders. The following elements are also represented in the figure: (7) loan request declined; (8) loan request accepted.

In Fig.12 two examples of utilization flow are graphically represented, which show how Borrowing (loan request) works using this invention. The request can take place through creditworthiness (therefore with the credit check) or with guarantees of other cryptocurrencies (without credit check). In the example relating to creditworthiness (left), we see that user A (1) requests a loan of ?200 Digital, this is disbursed (9) directly to his wallet (3) from the Lender Wallet (5). The user will refund (10), at the end of the period, to the lender wallet (5) the ?200 Digital Interests. In the example relating to the loan guaranteed by other cryptocurrencies (right), User B (2) provides collateral which at the current value is worth ?150, transferring them to the escrow wallet (6). The escrow wallet (6) communicates to the lender wallet (5) the actual blocking of the collateral (13). With these guarantees he requests a loan of ?75 Digital (9), which is sent from the lender wallet (5) to the user's wallet (4). As time passes (14), two situations can occur: In the case of automatic liquidation of collateral (if these have lost value over time and their value approaches the value of the loan disbursed), the system will automatically sell? these collaterals, repaying the entire loan of ?75 Digitali plus? any unpaid interest to the lender wallet (5) and returning any excess (10), sending it to the user's wallet (4). In the event that automatic liquidation does not occur (12), it will be? the user decides how much and when to repay the loan, continuing to pay daily interest until he decides? to repay the loan (totally or partially) (15). The following elements are also represented in the figure: (7) loan request accepted; (8) loan request declined.

Fig.13 shows different types of network protocols. Centralized approach (1): uses a centralized server to forward and mix the data stream; Totally connected and overlapping approach (2): all peers (nodes) are in direct contact with each other; Gossip-based approach (3): peers (nodes) operate in parallel and each communicates with one or more? nodes, randomly selected.

In Fig.14 ? visually shown how the consensus process determines which transactions are applied to each new version of the public ledger. (1) The index of the register increases by 1, (2) New unique hash, (3) Set of transactions just executed, (4) New version of the register is not ? immediately validated, (5) Transaction results in updated state, (6) proposed transactions, (7) The hash identifies the parent transactions used as the basis for the new version of the ledger.

In Fig.15 ? shown graphically is a simplistic representation of how ? composed of the public register validated by consensus: (1) Metadata, (2) New transactions just executed, (3) Status data (accounts, balances, etc), (4) Version of the register validated by consensus, (5) Index of register.

In Fig.16 ? represented the functioning of the consensus round that is part of this invention. Each Validator (1), proposes a set of transactions (2) that must be included in the next version of the ledger, (3) Validators remove transactions where the majority is not ? agree or where validators they don't trust don't propose them. Typically these transactions will then be re-proposed in the next version of the register. (4) Do validators add transactions where the majority of validators they trust? agree to include them in the next version of the register.

Fig. 17 represents the diagram of the payment flow using cryptocurrency which is the object of this invention, when a purchase is made with protection against fraud, introduced by the same invention. In the specific case, User A (1) purchases a product from User B (2). User A pays 30? to User B. In this case, the 30? they are not sent directly to B's wallet (4) but are sent to an Escrow Wallet (8), which holds the sum until User A sends the goods, and this is delivered to B. Only after a short period from delivery, which is automatically verified by querying the shipping company's tracking systems; if User B does not open a dispute/complaint, the escrow user (7) transfers the sum from the Escrow Wallet (8) to the wallet of user B (2).

Fig.18 visually represents the difference between the various types of wallets. The elements in the figure are: (1) Software Wallet, (2) Web Wallet, (3) Cold Wallet, (4) Hardware Wallet.

Fig.19 shows the Minting process (printing of digital currency) by the issuer and shows the evolution over time, from T0 to T4. In T0 we see that all values are at 0 (therefore there is no digital currency in circulation). In T1: Does the bank want to convert 1000? FIAT in 1000? digital (1); In T2: does the bank send the 1000? FIAT to the broadcaster (2); At this moment for? Aren't there 1000? digital available from the issuer (3); The ratio between collateral and circulating digital currency? 1000:0 (4) as there are 1000 that guarantee 0 digital currency (therefore there is an excess of collateral). In this condition the network authorizes the printing (minting) of 1000 Digitals, as there are 1000? of collateral FIAT already? available and there aren't 1000? digital that can be sent to the bank; In T3: The broadcaster prints 1000? digital (5). This operation immediately updates the total circulating digital currency (6) which goes from 0 to 1000; At this moment the ratio between collateral and digital currency issued? 1:1 (7). In fact, there are 1000 in circulation? digital, guaranteed by 1000? FIAT Deposited; In T4: the issuer sends the 1000? digital to the bank (8). All these values are publicly visible and in real time.

Fig.20 shows the Burning process (destruction of digital currency) by the issuer and shows the evolution over time, from T0 to T3. T0 ? a situation in which the circulating digital currency (3) is totally guaranteed by FIAT reserves (4). So there? a ratio of 1:1 (2). The 1000? digital cards issued are in the possession of the bank (1); In T1: Does the bank want to reconvert 1000? digital in 1000? FIAT, therefore, the bank sends the 1000? digital to the broadcaster (5). In T1, therefore, the digital currency issued? always guaranteed, but all that in circulation? in the possession of the issuer; In T2 the issuer sends the 1000? FIAT to the bank (6). Therefore at this moment the relationship is ? 0:1000 (7). So, there is 0 collateral in 1000 collateral? digital cards issued (and which are available to the issuer); T3: In this situation does the network authorize the destruction (burning) of the 1000? digital (8), since? ? digital currency not guaranteed by collateral. After the destruction, the total circulating goes from 1000 to 0 (9) and the ratio goes to 0 (10) as there are 0 digital coins and 0 collateral. All these values are publicly visible and in real time. In fig.21 you can see the functioning of the staking object of this invention: the wallet owner, by making available his possessions in digital FIAT currency or part of them, for a certain time defined by him, manages to obtain potential quantities? of additional coins (interest). In the example, the user has 1000? digital in his wallet (1); Using the wallet interface/app, decide the amount to block and the time by viewing what it will be? the amount of daily interest that will be paid to him. Start staking (4). In the example you decided to block 500? digital for 30 days (2), in exchange for 30? interest totals, therefore 1? per day (9). The remaining 500? they will be available and spendable by the user (3). The blocked sum is transferred (5) to the lender wallet (6). This ? the same wallet that I will then lend? through borrowing to users (Fig.12). At this point (7), if the staking period is ? still active (8) the user is paid daily interest (9). What if the staking period is ? termianto (10), the user is returned the amount (11) to his wallet (1);

Fig.22 shows the conversion process from cash (banknotes) to FIAT digital currency and vice versa (via bank and postal ATMs); Fig.23 shows the conversion process from Cash (Banknotes) to FIAT digital currency and vice versa (at any bank/post office and even without a current account); Fig.24 shows the conversion process from Cash (Banknotes) to FIAT digital currency and vice versa (at physical sales points);

Fig.25 shows the conversion process from FIAT bank reserves into FIAT digital currency and vice versa (via your bank's home banking/app);

Fig.26 shows the conversion process from bank reserves to FIAT digital currency and vice versa (at the counter of your bank/post office or any other - even if you are not a customer);

Fig.27 shows the conversion process from bank reserves to FIAT digital currency and vice versa (directly through the issuer, Exchanges, stock exchange operators, etc);

Fig.28 shows the conversion process from national/central bank reserves to FIAT digital currency and vice versa (directly through the issuer).

Claims (29)

1.5 CLAIMS 1. System for the creation and transfer of digital FIAT currency (1.3) between digital wallets (1.6) and management of the related FIAT reserves, deposited in the issuer's current accounts (1.7), to guarantee the digital currencies issued (collateral). 2. System referred to in the preceding claim, characterized by the fact that the system makes use of decentralized and public blockchain technology (1.2), of a shared/distributed public ledger (1.4) and accessible by anyone, of a peer-to-peer network (1.1), whose nodes (1.13) communicate with each other by forwarding digitally signed messages; the nodes use a gossip protocol (13.3), therefore they communicate in parallel with each other and each of them communicates with one or more? knots that for? are chosen randomly. 3. System referred to in claims 1 and 2, characterized by the fact that the total digital currency issued and circulating is? visible in real time (1.9), by anyone, directly via the blockchain, thanks to the establishment of a series of direct and indirect connections (1.16,1.17,1.22) between the issuer's wallet (1.8) and the public register (1.4 ), which return values to the network in real time. 4. System referred to in the preceding claims, characterized by the fact that, in the same way, the value of the consistency of the balances relating to the collateral (1.10) held in the issuer's FIAT accounts (1.7) are also communicated in real time and automatically to the network, thanks to the establishment of a series of direct and indirect connections (1.14,1.15,1.21), between the entities? financial institutions that store the collateral (1.7) and the public register (1.4), which return the values to the network in real time. 5. System referred to in the preceding claims, characterized by the fact that, thanks to the establishment of a series of direct connections (1.19,1,20) with the real-time relationship on the collaterals (1.10) and the real-time relationship time of the digital currency issued by the issuer (1.9), ? capable of generating a public and accessible relationship, via the network, by anyone and updated in real time (1.18), between the collateral held (1.7) and the circulating digital currency, also publicly showing the ratio between the two values (1.10) and (1.9). 6. System referred to in the preceding claims, characterized by the fact that the digital wallets (1.6) are associated with an address and not with a person; the balances and transactions of each individual wallet are public and visible on the blockchain, but they are not? known who the owner of that wallet is. 7. System referred to in the preceding claims, characterized by the fact that the custodian of the collateral (1.7) allows a connection between the bank accounts of the issuer where the collateral are kept and the network (1.14,1.21), so that? the actual amount is made public and verifiable by anyone, via the blockchain (1.10). 8. System referred to in the preceding claims characterized by the presence of a public register (1.4) which records and authenticates all transactions and shared and open to all. 9. System as per claim 8, characterized by the fact that the public register can? be updated only according to specific rules, respected by all participants and predetermined by the consensus protocol (1.5), where every single operation/transaction on the ledger maintains a complete copy of the ledger and the peer-to-peer network of servers/ computer (1.13) distributes the proposed transactions among themselves; The consensus process determines which transactions are applied to each new version of the shared public ledger. 10. System referred to in claims 8 and 9, characterized by the fact that the public register is composed of a series of registers or register versions, which are distributed over the network; each of these versions has an index (15.5) that identifies the order in which ? created the registry or its version. 11. System referred to in claims 8,9,10, characterized by the fact that the registers are managed according to the following procedure: a) The server makes a distinction between open, closed and validated log versions. b) Each server has only one open log, a variable number of closed but not validated logs, and an immutable history of validated logs. c) The server discards the open ledger, creates a new closed ledger, applies the transactions that were on top of a previous closed ledger, then creates a new open ledger, using the last closed ledger as the base. d) For an open ledger, transactions are applied in the order they appear, but different servers/computers may display transactions in different orders. e) To create a closed ledger, each server always starts with a set of transactions and a previous version, or ?parent? of the register. f) The server places the transactions in a canonical (i.e. rule-compliant) order, then applies them to the previous ledger in that order. g) Each server, therefore, will order? transactions in the exact same way as another, therefore in a deterministic manner. h) Each registry version that is ?closed? it also has an identifying hash value, which uniquely identifies the contents of that register. i) At any given time, a single instance contains a "current" and current open registry, as well as a number of closed registries that have not yet been approved for consensus and a variable number of "historical" registries that have been validated by consensus. 12. System referred to in claims 8,9,10,11 characterized by the fact that a single version of the register is composed of the following parts (Fig.15): a) A header (15.1): the registry index (15.5), hashes of other contents and other metadata; b) A transaction tree (15.2): the transactions that were applied to the previous register to create the current one. Transactions are the only way to change the ledger; c) A state tree (15.3): all registry objects, which contain the settings, balances and objects in the registry as of this version; d) The register index (15.5): the register index ? a 32-bit integer used to identify a register. The register index? sometimes known as the registry sequence number. The very first register? indicated with the index number 1 (Fig.14) and each new register will have? 1 compared to the previous index number (14.1). 13. System as per claims 8,9,10,11,12 characterized by the presence of a register index and a hash; the register index identifies the order in which the registers were created, the hash identifies the exact content of each individual register (14.2). Consequentially: a) Two registers with the same hash are therefore two copies of the same register; b) For validated ledgers, the hash values and indexes of the ledgers are equally valid and correlated 1:1; c) When more? register versions have the same register index but different contents (and different hashes), only one of these closed registers can? be validated (15.4); d) The hash of the current open ledger is not calculated; e) The hash of a register, however, is calculated only when the register ? closed. 14. System referred to in the preceding claims, characterized in that the status data (15.3) of each version of the register are a set of register objects which collectively represent all the settings, balances and relationships at a given moment of each register. 15. System referred to in claims 8,9,10,11,12,13,14 characterized by the fact that the register is governed by a set of rules, the properties? of the consensus protocol (1.5), which are as follows: a) Can all those who participate in the network, through the public register, agree on the most important balances? recent, on which transactions were executed and in what order; b) Are all valid transactions processed without the need? of a central operator; c) The public register can? make progress, even if some network participants join, leave, or behave inappropriately; d) If too many participants are unreachable or behave inappropriately, the network fails to make progress (crashes), instead diverging or confirming invalid transactions; e) System referred to in claims 8,9,10,11,12,13,14,15, characterized by a consensus group (or consensus round)(Fig.16) in which each validator (16.1) proposes a set of transactions that must be included in the next version of the ledger: a) If a particular transaction does not have the support of a majority of validators, participants agree to defer/postpone that transaction (16.3); b) If a particular transaction has majority support, participants agree to include the transaction (16.4). 16. System as per claims 8,9,10,11,12,13,14,15 characterized by the fact that the threshold required to include a transaction increases over time according to the following procedure: a) Initially, participants continue to agree to include a transaction if more? than 50% of the other participants? agree; b) If the participants do not agree, they increase this threshold, first to 60% and then even more? up, until all disputed transactions are removed from the current set; c) All transactions removed in this way are sent back to the next version of the register; d) When a participant sees a majority that ? agree on the set of transactions to be processed, declares that ? consensus has been reached; e) As the network progresses, each server listens to its trusted validators, why? the peer-to-peer network uses a protocol in which servers identify each other via public keys and transmit/forward digitally signed encrypted messages from each other; 17. System referred to in claims 8,9,10,11,12,13,14,15,16 characterized by the fact that the consent agreement is managed by the following procedure: a) As long as a sufficiently large percentage of nodes agree that a set of transactions should occur and that a given ledger ? the result of this series of transactions, the server declares a consensus (15.4); b) If they disagree, the validators modify their proposals to match as much as possible. possible to those of the other validators they trust, repeating the process more? rounds until a consensus is reached; c) Until? less than 20% of validators trusted? defective, the consensus can? continue without obstacles; and confirming an invalid transaction would require the collusion of more than 80% of trusted validators (highly unlikely scenario); d) If for any reason there were a very large number of unreachable or faulty validators, the network stops making progress and therefore crashes instead of being subject to attacks or validating erroneous transactions. 18. System referred to in the preceding claims, characterized by the fact that the failure of consent is managed with the following procedure: a) After the completion of a consensus round (Fig.16), each participant applies the set of transactions that they believe have been agreed upon. b) Participants, who are also validators (16.1), then publish a cryptographic fingerprint of this subsequent ledger, called a “validation vote”. c) Participants then collect these validation votes. d) From validation votes, they can determine whether or not the previous consensus round resulted in a majority of participants agreeing on a set of transactions. e) The participants are therefore in one of the three cases, in order of probability: - They built the same public register agreed upon by the majority. In this case, they can consider that registry fully validated and rely on its contents. - They built a public register different from the one agreed upon by the majority. In this case, they must construct and accept the register of the absolute majority. - No majority? clear from the validations received. In this case a new round must occur before any register can be validated. 19. System referred to in the preceding claims, characterized by the fact that the stability? of the price of the digital currency, which always replicates the value of the FIAT currency at which it is? pegged, and at the price at which the FIAT currency is exchanged with other pairs, at the official exchange rate, is achieved through the following procedure: a) Automated bots (9.5) place buy and sell orders at the exchanges where the digital currency is traded, paired with the same FIAT currency (9.3); b) Buy and sell orders are entered 1 tick from the reference price (therefore at the first value close to the reference price); c) The same procedure also occurs with the other pairs exchanged between digital currency and different FIAT currency (9.4), thus replicating the trend of the official exchange rate (9.2) between one FIAT currency and another (9.6); d) Therefore, the official exchange rate (9.2) is also replicated with the relevant digital currency (9.4); e) The bots adjust the prices of orders over time, adapting to changes in the official exchange rate (9.2) of each pair, thus also replicating it with digital currencies. 20. System referred to in the preceding claims, characterized by a verification and blocking procedure, as per Fig.10, which inhibits any type of collateral that is not of identical currency with respect to the currency of the digital currency issued; In addition, through operational blocking processes, the deposited collateral is inhibited from any use other than mere deposit. 21. System referred to in the preceding claims, characterized by the fact that the issuing processes (Minting) of the digital currency (Fig.19), ? managed by the following procedure: a) And? the network to authorize the issuance of new digital currency; b) The decision to authorize the issuance of a certain amount of digital currency,? determined by the actual lack of digital currency that can be transferred to anyone who requests it; c) If an?entity? requests a certain amount in digital currency (19.1), sending the relevant FIAT amount to the issuer (19.2); d) If the aforementioned amount of digital currency was not immediately available from the issuer (19.3), a situation would be created in which the collateral of the digital currency issued/in circulation would be greater; e) In this situation, there ? an excess of collateral and a shortage of digital currency (19.4); f) Only under these conditions, the network authorizes the issuance (19.5) of digital currency equal to the amount of the shortage; g) The issue automatically updates the total amount of digital currency circulating (19.6) on the blockchain; h) The ratio between collateral and digital currency issued is automatically updated (19.7); i) At this moment the issuer will have? the amount of digital currency requested and will be able to send to the requester (19.8). 22. System referred to in the preceding claims, characterized by the fact that the processes of destruction (Burning) of the digital currency (Fig.20),? managed by the following procedure: a) It is the network that authorizes the destruction of existing digital currency; b) The decision to authorize the destruction of a certain amount of digital currency, ? determined by the actual overabundance of digital currency, in relation to the collateral; c) Can you? in fact, it happens that the issuer has an amount of digital currency in its digital wallet that is greater than the collateral. Can this? derive from the fact that an?entity? has decided to reconvert the digital coins in his possession in exchange for the same amount of FIAT currency, therefore sending the digital sums to the issuer (20.5); d) When does the issuer send the relevant FIAT sum to this entity? (20.6); j) A situation is created, in which there is ? an excess of digital currency and a shortage of collateral (20.7); k) Only under these conditions, the network authorizes the destruction (20.8) of digital currency equal to the amount of the shortage; l) Destruction automatically updates the total circulating digital currency (20.9) on the blockchain; m) The ratio between collateral and digital currency issued is automatically updated (20.10); 23. System referred to in the preceding claims, characterized by the fact that the transfer of monetary resources (both online and off-line) is managed by the following procedure (Fig.8), which can be performed using desktop/laptop devices (8.15) and/or mobile/tablet devices (8.14): a) To transfer digital assets from user A (8.1) to user B (8.2); b) The digital assets will then be transferred (8.5) from A's digital wallet (8.3) to B's digital wallet (8.4); c) If the process is performed from desktop/laptop (8.15), a web interface of the wallet is opened on the desktop device (8.6); d) If the process is carried out from a mobile/tablet (8.14), the mobile interface of the wallet is opened, directly on the mobile device (8.7); e) The recipient's wallet address is entered or a QR code is scanned (where to send the payment) (8.8); f) The amount to be sent is entered (8.9); g) In the case of a mobile device (8.14), the operation is authorized/signed directly via the App/wallet interface (via pin or biometrics, etc.), directly on the mobile device (8.10); h) In the case of a desktop device (8.15), a QR Code is displayed on this which is used to authorize the transaction. This QR Code is scanned on the desktop/laptop by the smartphone where? the user's digital wallet is present (8.11); i) The transaction is authorized via the mobile interface (8.12); j) The transaction is processed (8.13); 24. System referred to in the preceding claims, characterized by the fact that it introduces purchase and fraud protection for buyers through the following procedure (Fig.17): a) When a payment is made by a user (17.1) to another (17.2), for the purchase of physical/tangible goods (17.5); b) The sum is not sent directly to the recipient (17.2), but a third party is inserted, the escrow user (17.7), who manages a special wallet, the escrow wallet (17.8); c) The original payment is then sent (17.6) to the escrow wallet (17.8), from the payer's wallet (17.3); d) The digital sum remains blocked in the escrow wallet until the physical goods are delivered; e) Control over the delivery of physical goods (17.5) occurs automatically through connections with shippers; f) Only after the actual delivery of the physical goods and only if the user (17.1) does not initiate a dispute/complaint, the payment is released from the escrow wallet (17.8) to the recipient (17.2), in his digital wallet (17.4 ). 25. System referred to in the preceding claims, in which digital wallets (1.6) also offer the holder the possibility to convert FIAT digital currencies, immediately, with other forms of FIAT currency (Banknotes, Bank Reserves, Central/National Bank Reserves) and vice versa. The processes vary based on the type of conversion to be performed and are they so? grouped: - Conversion from cash (banknotes) to FIAT digital currency (via bank and postal ATMs) (Fig.22): a) The user, without inserting a credit/debit card and without entering any PIN (22.1); b) Initialize the conversion operation on the ATM display (22.2); c) scan the QR Code of your wallet via the ATM which is? can be generated immediately and available via the wallet interface/App which is installed on the user's smartphone. Then the ATM, using a camera, scans this QR code from the user's phone (which is nothing other than the address where the digital coins will be transferred, therefore the user's wallet) (22.4); d) The user enters the amount he wants to convert into digital currency (22.6); e) Inserts the same sum in cash into the ATM (22.7); f) Authorizes/signs the operation via App/wallet interface (via pin or biometrics, etc) (22.8); g) If the transaction is not correctly authorized for any reason, the ATM returns the cash (22.13); h) If, however, it is authorised, the bank (which has its own digital wallet with digital currency deposits), automatically transfers the same amount in digital currency to that wallet (22.9); i) Cash is held via the ATM (22.11); - Conversion from FIAT digital currency to cash (banknotes) via bank and postal ATMs) (Fig.22): a) The user, without inserting a credit/debit card and without entering any PIN (22.1); b) Initialize the conversion operation on the ATM display (22.3); c) The user scans the QR Code via the phone which will be shown on the ATM display. The ATM QR Code is then scanned by the user's phone (this QR code is nothing other than the address where the digital coins will be transferred, therefore the Bank's wallet) (22.5); d) The user enters the amount he wants to convert (22.6) and begins the transfer process; e) Authorize/sign the operation via App/wallet interface (via pin or biometrics, etc) (22.8); f) If the transaction is correctly authorized, the digital currency is transferred from the user's wallet to that of the Bank (22.10); g) The same sum in cash is then delivered to the user via the ATM (22.12); - Conversion from Cash (Banknotes) to FIAT Digital Currency (At any bank/post office and even without a current account) (Fig.23): a) The user delivers the banknotes to the counter employee (23.1); b) The bank employee scans the QR CODE of the user's wallet (23.3) and begins the transfer operation; c) The employee keeps the cash (23.5); d) The employee authorizes/signs the digital transfer operation via the App/wallet interface (via pin, biometrics, etc) (23.6); e) If the transaction ? authorized, the same digital sum is transferred from the bank's Wallet to that of the user (23.7); - Conversion from FIAT Digital Currency to Cash (Banknotes) (At any bank/post office and even without a current account) (Fig.23): a) The user scans the QR code of the bank's wallet, provided by the teller employee (23.2); b) The user sends the digital amount from his wallet to the bank's wallet (23.4); c) The user authorizes/signs the digital transfer operation via the App/wallet interface (via pin, biometrics, etc) (23.6); d) If the transaction ? authorized, the digital currency is automatically transferred from the user's wallet to that of the Bank (23.8); e) The same sum in cash is delivered by the employee to the user (23.9); - Conversion from Cash (Banknotes) to FIAT Digital Currency (At physical sales points) (FIG.24): a) The user delivers the banknotes to the point of sale staff (24.1); b) The point of sale staff scans the QR CODE of the user's wallet, where the same amount of digital currency can be sent (24.3), directly from the user's smartphone; c) The store staff holds the cash (24.5); d) The point of sale staff begins the digital transfer operation, authorizing/signing the operation via the App/wallet interface (via pin, biometrics, etc) (24.6); e) If the transaction ? authorized, the digital sum is transferred from the store's Wallet to that of the user (24.7); - Conversion from FIAT Digital Currency to Cash (Banknotes) (At physical points of sale) (FIG.24): a) The user scans the QR code of the store wallet, provided by the store staff (24.2); b) The user begins the digital transfer operation from his wallet to the point of sale wallet (24.4); c) The user authorizes/signs the operation via the App/wallet interface (via pin, biometrics, etc) (24.6); d) If the transaction ? authorized, the digital currency is transferred from the user's wallet to that of the point of sale (24.8); e) The same sum in cash is delivered by the point of sale staff to the user (24.9); - Conversion from FIAT bank reserves into FIAT digital currency (via your bank's home banking/app)(FIG.25): a) The user accesses his Home Banking and decides the amount? of FIAT currency in stock on his account and available, which he wishes to convert into Digital currency (25.1); b) The user enters the address or scans the QR CODE of the wallet where to send the converted digital currency (25.3); c) The bank begins the digital transfer operation from its wallet to the wallet indicated by the customer (25.5); d) The bank automatically authorizes the digital transfer (25.7); e) If the transaction ? authorized, the bank sends the aforementioned amount of Digital Currency from its wallet to that of the customer (25.8); f) the bank withholds the same FIAT amount from the user's current account (25.10); - Conversion from FIAT digital currency to FIAT bank reserves (via your bank's home banking/app)(FIG.25): a) The user, through his digital wallet, decides the amount of digital currency he wants to convert into FIAT (25.2); b) The user enters the address or scans the QR CODE of his bank's digital wallet, where to send the digital currency and begins the transfer process from his digital wallet to that of the bank (25.4); c) The user authorizes/signs the operation via the App/wallet interface (via pin or biometrics, etc) (25.6); d) If the transaction ? authorized, the digital currency is automatically transferred from the user's wallet to that of the Bank (25.9); e) The bank credits the same FIAT amount to the customer's account (25.11); - Conversion from bank reserves to FIAT digital currency (at the counter of your bank/post office or any other - even if you are not a customer) (FIG.26): a) The user goes to the bank branch (26.1); b) The user decides the amount of FIAT money to convert into digital currency, from what he has available in his bank account (26.2); c) If ? bank customer, the bank checks the availability? FIAT on the Customer's account (with them) and sees if it has this amount available (26.5); d) If not? customer of that bank (26.4), ? the customer's bank (26.6) to confirm to the bank where the customer is carrying out the conversion, whether it has that amount available, returning the result (26.7); e) If it has sufficient funds, the bank enters the address or scans the QR CODE of the customer's wallet, where the customer wants to send the converted digital currency, which is? provided by the customer himself (26.8); f) The bank begins the transfer of the digital sum from its digital wallet to the wallet requested by the customer (26.9); g) Authorizes the operation automatically (26.10); h) If the transaction ? authorized, the bank withholds the same FIAT amount from the user's current account (26.11); i) If for? the customer had a FIAT account with another bank (26.4), that bank reimburses the same digital amount to the bank that performed the conversion, advancing the digital currency to the customer (26.12); - Conversion from FIAT digital currency to bank reserves (at the counter of your bank/post office or any other - even if you are not a customer) (FIG.26): a) The user goes to the bank branch (26.1); b) The user decides the amount of digital currency to be converted into FIAT currency (26.3); c) If? a customer of that bank, the user scans the QR Code of the bank's wallet (provided by the operator at the counter) via smartphone (26.14); d) If not? customer of that bank, The user scans via smartphone the QR Code of the wallet of the bank where he has the FIAT current account, provided by his bank (26.15); e) The user begins the digital currency transfer operation from his wallet to that of the bank (26.16); f) The user authorizes/signs the operation via the App/wallet interface (via pin, biometrics, etc) (26.17); g) The bank immediately credits the same FIAT amount to the user's current account (26.18); - Conversion from bank reserves to FIAT digital currency (directly through the issuer, exchanges, stock exchange operators, etc) (FIG.27): a) The user decides the amount of FIAT currency to be converted into Digital (27.1); b) The user sends the FIAT currency to the operator, in his FIAT account (27.3) and indicates the address of the wallet where to receive the same digital sum; c) The operator retains the FIAT sum (27.5); d) The operator begins the transfer operation of the same digital amount from his wallet to the one provided by the customer (27.7); e) The operator authorizes/signs the operation via App/wallet interface (via pin or biometrics, etc) (27.8): f) If the transaction ? authorized, the user will have received the digital sum in the reported wallet; - Conversion from FIAT Digital Currency to Bank Reserves (directly through the issuer, Exchanges, stock exchange operators, etc) (FIG.27): a) The user decides the amount of digital currency to be converted into FIAT (27.2) and informs the operator of the account where to send the sum converted into FIAT; b) The operator informs him of the wallet where he must send the digital sum (27.4); c) The user begins the digital transfer operation from his wallet to that of the operator (27.6); d) The user authorizes/signs the operation via the App/wallet interface (via pin or biometrics, etc)(27.8); e) If the transaction ? authorized, the operator will have received the digital sum in the reported wallet; f) The operator sends the same amount in FIAT currency to the bank account indicated by the user (27.9); - Conversion from national/central bank reserves to FIAT digital currency (directly through the issuer) (Fig.28): a) The central/national bank decides the amount it wants to convert from FIAT to digital and the issuer tells it which FIAT bank account to make the deposit (28.1); b) The central/national bank deposits the amount in FIAT currency in the issuer's accounts and indicates which digital wallet to receive the same digital sum (28.2); c) When is the deposit? occurred correctly (28.3); d) The issuer begins the digital transfer operation from its wallet to the one provided by the central/national bank (28.4); e) The issuer authorizes/signs the operation via the App/wallet interface (via pin or biometrics, etc) (28.5); f) If the transaction ? authorized, the central/national bank will have? received the digital sum in the reported wallet; - Conversion from FIAT Digital Currency to Reserves of national/central banks (directly through the issuer) (Fig.28): a) The central/national bank decides the amount it wants to convert from digital to FIAT and the issuer indicates which wallet to deposit the same digital sum in (28.6); b) The central/national bank begins the digital transfer operation in the issuer's wallet and informs the issuer on which FIAT account to receive the same amount in FIAT currency (28.7); c) The Central Bank authorizes/signs the operation via App/wallet interface (via pin or biometrics, etc) (28.8); d) If the transaction ? authorized, the issuer will have received the digital sum in the reported wallet; e) The issuer transfers the same amount in FIAT currency to the bank accounts of the central/national bank (28.9). 26. System referred to in the preceding claims, characterized by the fact that digital wallets (1.6) allow the owner to create letters of credit/guarantees/guarantees - including international ones - and guaranteed by digital FIAT currency, through the following procedure (Fig.6): a) Payment between two subjects (6.1) and (6.2)? subject to the occurrence of certain conditions established between the parties; b) The subject (6.1) sends the sum from his digital wallet (6.3) to the escrow wallet (6.8), which is managed by the escrow user (6.7) and which is in contact with both parties; c) The payment is released from the escrow (6.7) to the user (6.2) and in his digital wallet (6.4), only upon the occurrence of the condition(s) previously agreed between the two users. The flow of digital payment when the condition? satisfied? (6.6); d) If the condition is not satisfied, the payment returns to the payer (6.5); 27. System referred to in the preceding claims, in which the digital wallets (1.6) allow the owner to lend the digital FIAT currencies in possession, through the following procedure (Fig.11): a) The user who requests a loan and who, after the credit check, is not result worthy of credit, will you have? a declined loan request (11.7); b) The user (11.5) who instead, is result worthy of credit, will you have? an accepted loan request (11.8) and receives financing from various lender users (11.13,11.15,11.17); c) The financing starts from the lenders (11.13,11.15,11.17), who send part of their holdings in digital currency, from their digital wallets (11.12,11.14,11.16) to the warranty wallet (11.11), in exchange for the payment of monthly interest; d) The warranty wallet, therefore, disburses loans (11.10) to credit-worthy users (11.5), in their digital wallet (11.6), using the funds made available by the lenders; e) The user who received the loan (11.5) will repay the loan on a monthly basis. (11.9) to the warranty wallet (11.11) the monthly installment, including interest, until the loan is fully repaid; f) The lenders (11.13,11.15,11.17), at the end of the period, will have received monthly reimbursements, in their respective digital wallets (11.12,11.14,11.16) of the sum lent, including interest; 28. System referred to in the preceding claims, in which the digital wallets (1.6) allow the owner to request loans in digital FIAT currency, instantaneously, through the following procedure (Fig.12): - Loan request based on the applicant's creditworthiness: a) The user who requests a loan and who, after the credit check, is not result worthy of credit, will you have? a declined loan request (12.8); b) The user (12.1) who instead, is result worthy of credit, will you have? an accepted loan request (12.7); c) The loan is disbursed (12.9) directly to your digital wallet (12.3) from the Lender Wallet (12.5); d) The user will reimburse? monthly (12.10), to the Lender wallet (12.5), the total loan is more? interests; - Request for a loan guaranteed by cryptocurrency collateral by the applicant (without credit check: a) The user (12.2) who wants to request a loan guaranteed by cryptocurrency collateral; b) Decides the amount of the request; c) The user can request a loan of a maximum of 50% of the value of the collateral that will be deposited, therefore providing collateral in cryptocurrencies which, at their current value, are worth double the sum requested, transferring them (12.11) to the Escrow wallet (12.6); d) When the collateral has been deposited, the escrow wallet (12.6) communicates to the Lender wallet (12.5) the actual custody of the collateral (12.13); e) The loan is disbursed (12.9) from the Lender wallet (12.5) to the user's wallet (12.4); f) As time passes (12.14), two situations can occur: - In the case of automatic liquidation of collateral (if these have lost value over time and their value is close to the value of the loan disbursed), the system will automatically sell? these collaterals, repaying the entire loan plus any unpaid interest to the lender wallet (12.5) and returning any excess (12.10), sending it to the user's wallet (12.4); - In the event that automatic liquidation does not occur (12.12), it will be? the user decides how much and when to repay the loan, continuing to pay daily interest until he decides? to repay the loan (totally or partially) (12.15). 29. System referred to in the preceding claims, in which the digital wallets (1.6), allow the owner to make available his possessions in digital FIAT currency or part of them, for a certain time defined by him, obtaining potential quantities ? of additional coins (interest), using the following procedure (Fig.21): a) The user has X amount of digital currency available in his digital wallet (21.1); b) Using the wallet interface, decide the amount to block and the time, viewing what it will be? the amount of daily interest that will be paid to him; c) The Staking period then begins (21.4); d) The user will have the figure defined by him which will be? blocked for the entire period (21.2), while the excess sum of its balance will be? usable (21.3); e) The blocked sum is transferred (21.5) to the lender wallet (21.6). The lender wallet, ? the same wallet that I will then lend? through borrowing to users (Fig.12); f) At this point (21.7), if the staking period is ? still active (21.8) the user is paid daily interest (21.9) directly into his wallet (21.1) and for the entire period of the digital sum being blocked; g) What if the staking period is ? finished (21.10), the user is returned the amount (21.11) to his wallet (21.1).