EP3740918A1

EP3740918A1 - Token-based transactional systems and methods

Info

Publication number: EP3740918A1
Application number: EP19706738.2A
Authority: EP
Inventors: Enrico Maim
Original assignee: Individual
Current assignee: MAIM, ENRICO
Priority date: 2018-01-15
Filing date: 2019-01-15
Publication date: 2020-11-25
Also published as: US11861599B2; WO2019138391A1; US20210133735A1; CN111699502A

Abstract

The invention proposes a network transactional system, comprising a set of token nodes (TN), a set of user nodes (UN) and a set of provider nodes (PN), the nodes being capable of executing an executable contract for a user node to obtain token account units (Voucher Tokens) by reserving (R) reserve account units according to a value of the token units which itself varies according to the reserve, the number of token units in circulation and the reserve ratio (RR). A provider node is associated with each token node and the token is representative of a product or asset (good, service, right or other benefit) of the provider, or a group of such products or assets. When a user node provides account units necessary to obtain token units from a given token node at the current value, the system is capable of transferring a first portion of said reserve account units to the reserve of the given token node, and transferring a second portion of said reserve account units outside the reserve, and performing reverse transfers when token units are returned to the given token node, so as to limit or neutralise the value variations of the token unit when said token units are received and returned. Application including the generation of interchangeable local tokens without undesirable value variations related to reserve mechanisms such as Bancor.

Description

Transactional systems and methods based on tokens Field of the invention

The present invention generally relates to methods and electronic systems for performing transactions involving assets based on reserve units from which "tokens" are generated.

State of the art

Nowadays, the execution of "smart contracts" is in full expansion, thanks to the ability of a processing unit to execute a contract which we are sure has not been altered, nor by logical attack, by physical attack, and neither by a third party nor by the owner of the unit in question. This makes possible trust exchanges between different processing units. The applications of the exchanges of confidence develop in many fields, from financial to legal through logistics, etc.

In particular, executable contracts are known that make it possible to generate tokens by setting aside money account units or cryptocurrency, these tokens possibly having different kinds of counterparties.

There are already various electronic means that act as a medium of exchange (currency) to allow the person who has delivered goods or services to order later on the market other goods or services he wishes.

It would be desirable that any person who offers goods or services for sale on the market at published and competitive prices can have a medium of decentralization emitted automatically without the intervention of a third party other than his client. automatic currency exchange, at least when these goods and services are required on a daily basis.

Now, such an abundant and readily available medium of exchange to ensure the mediation necessary for exchanges does not exist in generalizable form.

We know certainly the vouchers issued by a supplier, for example in the form of tokens- a customer buys such a token from the supplier, that the latter will later accept (redeem) against a good or service, and enjoys This is a discount, but you can easily get too many tokens issued by some suppliers and not enough tokens issued by others. We realize the limits of this system when we can not convert excess tokens into tokens we miss. Such tokens could play the role of exchange medium if they were interchangeable.

However, such a capacity of vouchers to be interchanged raises the difficulty that it would be sufficient to issue, for a given supplier, as many vouchers as he would like, and then exchange them with vouchers for other supplies and thus obtain without limitation different types of goods and services.

Bancor (see https://bancor.network) would be able to exchange one such token against another in a transparent way by setting aside reserve account units.

It is recalled that Bancor introduced the purchase / sale of token units without the need for a counterpart. The price P of a token unit is given by the formula P = R / (S * RR) (called "Bancor formula" in the following) where: • R is the reserve (analogous to the fractional reserve that a deposit bank has to keep in order to have sufficient liquidity in the event that a large number of depositors come to withdraw their money at the same time - here the token acts as a receipt for deposit but is at the same time tradable in itself in the market and its value is variable),

• S (as "Supply") is the quantity of token units that are in circulation and

• RR is a value of "Reserve Ratio", which is in principle decided at the creation of the token and which is normally a constant,

reflecting the fact that the more one buys more the price goes up (in reserve units, for example in Ethereum units, ethers (ETH)), and conversely the more one sells the more it goes down. Each token can in turn play the role of reserve for new tokens. This model is described in Bancor White Paper: https://about.bancor.network/static/bancor_protocol_whitepaper_en.pdf incorporated here by reference - note that in the most recent version of this White Paper, R is called "Connector Balance" And RR is called "Connector Weight", reflecting better than reserve tokens are generally common to different tokens and thus serve to "connect" them to be convertible between them; they are "connectors".

However, if you want a token of a system such as Bancor to take the place of "voucher" (such as a voucher) representing an asset or product of the real world, this raises several difficulties.

First difficulty, the fact that its value increases with each purchase. Indeed, when a seller puts on the market a set of vouchers (voucher in the broadest sense, for example by offering a discount in relation to the value of the corresponding product - good, service, right or another advantage - on the market), it is expected that all these vouchers will have the same price regardless of the order in which they were purchased by the customers, while the tokens have a value that evolves at each transaction.

Second difficulty, as the tokens must be generated (automatically during their purchases) without limitation because the fluctuations of the price of a token on the external market (on the various exchange market places, the many "exchanges") can be taken into account through arbitration operations (see white paper already cited) and this requires that tokens are generated in an unlimited way (as long as there are purchases), indeed, a ceiling in their generation would mean that arbitrage with external markets ceases to be possible as soon as the ceiling is reached - tokens can not represent a limited set of assets (real-world resources).

Finally vouchers must be linked to the assets they represent. For a voucher that, by definition, represents an underlying of real-world goods or services, a change in the value of the underlying must be reflected directly in the value of the token, which is not automatically the case with the tokens of a system such as Bancor.

These tokens can not represent vouchers. But potential applications with voucher tokens would be numerous. Voucher Tokens could represent assets (ie a good or service, or a share of ownership in these goods or services or in legal entities capable of providing such goods or services, or holding them), such as:

• money issued by a bank or a central bank;

• shares of a company (equity);

• intellectual property rights or units of these securities;

• goods in limited quantity (such as gold);

• gift vouchers ("self-issued credit" or "IOU") as presented in the video https://www.voutube.com/watch?v=RrawbYEZm M) for a product available in the future and the production of which may be limited in time - the voucher may advantageously include preferential delivery dates and bonuses (additional quantities, or other benefits) associated with these dates. Assets represented by voucher tokens would have the advantage of being able to be taken into account and handled in smart contracts (executable contracts), in new types of cooperation.

Moreover, currency systems are already known, making it possible to create currencies, for example local currencies that can be used by communities. See in particular the literature written by Bernard Lietaer, Belgium, about complementary currencies.

These currencies return to generate credit for the economic actors. When credits are generated a priori, they are based on an estimate of the demand and the actual supply, possibly according to certain possible allocations of the supply to the estimated demand. These estimates are therefore tainted by error; some actors are left with a surplus in relation to the purchases that were expected to be made locally and when such an actor wishes to convert this surplus into another currency, for example a currency ("community currency"). ) of a second community, this will negatively affect the value of the credit currency, thereby negatively impacting the entire first community.

For example, if the currency in question is generated according to the "Bancor" model, this exchange with another currency will imply a decrease in the reserve and therefore a fall in the value of the currency.

It would be more beneficial if the vouchers are generated as credits (as long as the difficulties mentioned above are mitigated) and there is no longer a need for credit issuers (such as banks) apart from the buyers themselves, so that credits are generated based on actual demand (rather than estimates) and credit risk is taken by buyers rather than the community. It would also be beneficial to remove the geographical limitation of current complementary currency solutions.

Summary of the invention

In one aspect, one aims, based on a model with reserve such as the Bancor model, where different types of tokens represent different types of assets or products, to control the changes in the value of tokens during transactions, inherent in the Bancor model. .

Thus, an existing, essentially speculative, mechanism would be made fundamentally useful for allowing communities to develop local currencies or other fiduciary elements without parasitic value variations and in a perfectly interchangeable manner.

A network transactional system is thus proposed, comprising a set of token nodes, a set of user nodes and a set of provider nodes, the nodes being capable of executing an executable contract enabling a user node to obtain account units. tokens (Voucher tokens) by setting reserve account units based on a value of token units which itself varies according to the reserve, the number of token units in circulation and the reserve ratio , each token node being associated with a provider node and the token being representative of a product or asset (good, service, right or other advantage) of the provider, or a group of such products or assets, the system being suitable, when a user node makes spare account units necessary to obtain token units from a given token node at the current value, to transfer a first one by of those reserve account units to the reserve of the given token node, and to transfer a second part of those reserve account units out of that reserve, and to perform the reverse transfers on surrender of token at the given token node, so as to limit or neutralize the value variations of the token unit during the obtaining and rendering of these token units. Token units of account (sometimes shortened to "token units" or "token units" in the following) obtained can generate a supply commitment from the vendor owning the supply node and constitute a kind of purchase order. However they are only generated on an actual request by a user and not on the initiative of the supplier as is the case for a traditional purchase order. The "fraud" in which the provider itself obtains token units from the associated token node (thus generating false orders) would be absurd here because (thanks to the execution integrity of the executable contracts) this provider should for this pay his token at the same price (P) as his customers. Moreover, in the case where for most of the suppliers (subcontractors, etc.) of the supplier in question, only the tokens associated with these suppliers make it possible to buy from them, block reserve units to generate units of his own token would prevent him from using these same spare units (to the extent that they are the same as his own suppliers and act as connectors) to obtain the supplies he himself needs.

In this respect, the use of a system of tokens for the supplier's own supplies is virtuous in that it allows reciprocal circuits to be detected and cause automatic discounts or even, in the particular case where a barter circuit indirect is detected, not having to block spare units at all, when buying token-units and suppliers will have the advantage to adopt it by creating their own token.

The invention also makes it possible to generate credit for an actor not according to estimates, but according to actual demand and future demand.

Certain preferred but nonlimiting aspects of this system include the following features, taken individually or in any technically compatible combination:

the system is able, when supplying a good or service product by the supplier, to delete the corresponding token units by transferring to the supply node the first part of the reserve account units and, if it has not already been transferred, the second part of the reserve units;

* the system also includes product delivery attestation nodes able to communicate with the token nodes to selectively delete all or part of the token units and transfer to the supply node all or part of the first part of the reserve account units and, if it has not already been transferred, the second part of the reserve units, according to a certified or certified status of supply of the product corresponding to a user;

the system also comprises, at the level of a user node, suitable means, in response to geographical location information, to cause obtaining units of a certain token associated with this location.

the system comprises means for loading into the user node in question an executable contract allowing this obtaining.

* to said units of the certain token are associated temporal data, such as a period of validity.

the fraction of units of account defining said first part is variable, of material to vary the price of the certain token associated with the location, in particular for regulation purposes.

* the delivery certificate node and the user node of the user concerned form one and the same node; * the product is constituted by a right of use of the given token as unit of account of reserve for token nodes of other tokens;

said second portion of the reserve account units is transferred at least in part to the provider node;

* the executable contract executed in a token node is able, prior to a return of token units to the given token node, to check the availability of reserve account units that were transferred to the provider node when obtaining these token units and, based on this check, to perform the restitution to the extent of the available reserve account units, and is also able to assign the supply node a residual debt attribute of reserve account units in case of at least partial unavailability;

* the executable contract is able, in a subsequent transaction involving a transfer of reserve account units to a provider node with such a remaining debt attribute, to transfer all or part of the reserve account units to be transferred for that purpose. subsequent transaction to the user node at the origin of said restitution, to at least partially complete the latter;

the system comprises means for associating the remaining debt attributes of the provider nodes with other attributes of these nodes, thereby dissociating these attributes from the key pairs of said nodes;

* said second part of the reserve account units is transferred at least in part to an escrow account;

* the escrow account is managed within the given token node;

* the number of reserve account units of the first part is chosen to neutralize the variations of value of the token units during the accessions and restitutions thereof;

the token node is able to compare the number of token units obtained by the user nodes with a variable availability threshold and, if this threshold is exceeded, to modify the allocation of the new reserve account units set to provision between first and second part;

* the modified allocation has a second part with zero units of reserve account;

the given token node is able to mark the token units generated beyond said threshold so that they form an availability waiting list, and to delete this marking as the said threshold increases;

* the availability threshold is determined from an amount of assets associated with the provider node and a given asset blocking ratio;

the availability threshold is determined by an executable contract at the provider node or the token node, responsive to information provided by asset blocking sensor means;

the system comprises means for modifying the value of the availability threshold and / or the conversion value of the Voucher Tokens into assets in response to a decrease (generally out of control) in the number of assets from which the availability threshold initial has been established; * the supplier is able to supply fixed quantities of product constituting a reference good (such as gold metal), these fixed quantities of the reference good thus playing the role of real money;

the system includes priority management means in the waiting list;

the priority management means are able to take into consideration micropayments made with the token considered by different users having tokens in the waiting list;

the system also comprises, at the level of a provider node or a token node, secure means for certifying blocking or asset generation (typically sensor means managed by an executable contract), cooperating with the means for generating the availability threshold for the asset in question;

* the first part of the reserve account units consists of a first sub-part the number of which is such as to neutralize the variations in the value of the token units when they are obtained and returned, and a second sub-part of which the number is such that they generate a controlled variation in the value of the token unit, with an increase on obtaining and a decrease on the return;

* the number of spare account units of the second subpart is determined according to a variable parameter (IH) associated with the token and managed by its token node;

* the parameter is a function of time data relating to the supply request and the supply offer at the supplier node;

the parameter is a function of a density and / or a distribution of possible supply instants in one or more time intervals where the supply is requested;

* The parameter is a function of population data of different user nodes that have obtained tu tu tu associated units;

* the population data of user nodes are weighted by coherence data, between these nodes, vis-à-vis token units of other types they obtained (compliance);

the parameter is a function of reliability data of supply of the products corresponding to the considered token;

* the parameter is a function of at least two of the data;

a token node is able, in case of variation of said parameter, to redistribute the assignment of the reserve account units to its first part and its second part by transfer from outside the reserve to the reserve or vice versa;

the system further comprises means for automatically causing tokens unit accesses at a given token node in response to a reported change in the underlying asset to that token unit, so as to adjust the value of the token unit on the value of the underlying asset that has changed;

* the variation is signaled by detecting a change in quantity of a physical asset constituting the underlying asset; the system comprises secure means (such as sensor means managed by an executable contract) for detecting said variation;

* the change is reported by detecting the change in value of an intangible asset constituting the underlying asset;

* the system includes secure means of communication, managed by an executable contract, with a data source capable of providing the value of the intangible asset;

the units of tokens for a given token node are able to be converted into supplies of products or reserve units previously blocked in blocked assets, and the system further comprises means for determining a number of units of tokens to obtain to be provided a given quantity of products or reserve units previously blocked according to data of probabilities of events triggering such a supply, at least part of the reserve account units which made it possible to obtain the tokens units being transferred to the product supply node and / or to the blocked assets;

the system further comprises means capable, in response to the occurrence of a triggering event, of converting token units of a given token into a supply of products or reserve account units previously locked in assets blocked, and means for determining a number of token units to be obtained to obtain a given quantity of pre-blocked pooled revenue or reserve account units based on event trigger probability data of such a supply. at least a portion of the reserve account units which have acquired the token units being transferred to the supplier supplier node of the products and / or to the blocked assets;

* said number of token units to acquire varies according to a probability of occurrence of a triggering event according to a growing law;

* the transfer of the reserve account units to the product provider node constitutes a down payment, the balance of reserve account units being transferred from the reserve (R) to the supplier when supplying the product to the triggering event;

the transfer of the reserve account units to the blocked reserve account unit node participates in the generation of the blocked assets, the reserve account unit complement being transferred to the user node from the reserve (R ) when releasing assets on triggering event;

* said probability data is based on existing statistical data related to the triggering events;

* said probability data are adjusted by statistical learning;

the tokens of at least one token node are tokens support able to be converted into support supplies upon the occurrence of triggering events, the system comprising means for managing the spare account units capable of obtaining additional tokens support in relation to a starting situation:

- to block at least part of the reserve account units received for this acquisition, without assigning it to the reserve,

- to allocate these blocked reserve account units to the different tokens support holders (user nodes that are beneficiaries of the support commitment) according to the occurrence of the triggering events; the system further comprises means for transferring units of account from a given token in response to an increase in utility or use of a network of token nodes having that token given as a unit of account. reserve, towards the reserve of token nodes contributing to this increase;

* the increase in utility or utilization of the network is determined by at least one of the following factors:

- an intention to purchase a good or service, materialized by the purchase of units of a specific token (second token) by setting aside the given token,

an offer for sale of a good or service with a specific token that can be obtained by setting aside the given token,

- the actual purchase of the good or service,

- The conversion of the specific token Voucher token for exchange with the good or service,

- increasing the threshold of availability of the specific token in Voucher token;

the system further comprises means for generating, at least some token nodes, offers and requests for tokens of other types, and means for managing a token exchange market on the basis of said offers and requests and the configuration of the network so as to optimize the exchange transactions;

the system further comprises means for controllably transferring reserve account units between token nodes so as to act on the values of the token units via their respective reserves by attenuating the fluctuations of said values caused by the acquisition transactions and restitution of tokens (reciprocity);

the means of transfer of reserve account units are able to control the quantities of reserve units transferred according to scores established for each token;

* the score for a given token is related to the importance of the transactions made on the token in question;

* the importance of the transactions on a given token is determined from at least one of the following factors: the transaction account unit volume of the given token, the number of user nodes triggering token unit transactions , the seniority of the transactions of the given token, the changes in the value of the token that would be obtained by application of a gross reserve rule (where all reserve account units go into the reserve);

* the scores are determined by iterations on sets of token nodes and of larger and larger user nodes based on links between such nodes;

* the links are constituted by the transactions;

* a transfer of reserve to token node is realized only if the score of the latter is higher than a threshold;

* the quantity of reserve units transferred to a token node is determined according to the score of the latter;

* a score is even higher than the transactions of the given token are recent; * the system is implemented in a decentralized peer-to-peer way by integrated processing token nodes;

the system further comprises means for simulating controlled transfers of reserve account units between token nodes so as to obtain simulated values of the token units corresponding to their respective simulated reserves, said simulated values having attenuated fluctuations, and means for performing transactions on said simulated values;

* the simulated values are weighted by tribal scores;

the means for carrying out transactions on said simulated values are able to determine price adjustments on the basis of deviations between real values and simulated values, and to compensate for all the adjustments;

a first provider node associated with a token node of a first token is a provider node vis-à-vis a first user node which is also a second provider node associated with a token node of a second token, and system further comprises means for determining the existence or perspective of existence of reverse transactions where the first provider node would be a user node at one end and the second provider node would be provider at the other end, where appropriate via other provider nodes, and, depending on characteristics of these actual or expected reverse transactions, to transfer to the first user node from the first provider node a given amount of first token units in exchange for a simple transfer of reserve account units corresponding to that given amount of first token units, to allocate this payment to the reserve;

* for the other user nodes, the units of account of first token are obtained for their real value (P);

* The volume and frequency of unit account transfers for the sole reserve account units are related to the volume and frequency of transactions in the reverse transaction chain;

the system comprises means for modulating the amount of the transfer between the reserve value and the real value as a function of the length of the reverse transaction chain;

* determining the existence or perspective of existence of reverse transactions where the first provider node would be a user node at one end and the second provider node would be provider at the other end, if necessary via other provider nodes , is implemented with "pretoken" type tokens that do not require reserve account units to be set aside.

the system comprises means for requesting the obtaining of tokens by setting aside reserve account units when no reverse transaction chain expected with pretokens is detected.

* a token node and an associated provider node consist of one and the same node.

The invention also provides methods comprising combinations of steps implemented by the above systems.

Brief description of the drawings The invention will be better understood on reading the following detailed description of preferred embodiments thereof, given by way of nonlimiting example and with reference to the appended drawings, in which:

FIG. 1 illustrates the basic architecture of a system according to the invention,

Figure 2A is a state diagram / transitions illustrating an embodiment of the invention with conversion of tokens to Voucher tokens in limited quantity and management of a waiting list,

Figure 2B illustrates the unit flows occurring during the transitions of the diagram of Figure 1,

Figure 3 shows sets of nodes determined, by a scoring algorithm, from relationships between on the one hand buyer / sell user nodes of tokens and on the other hand the token nodes corresponding to the purchases / sales in question. , want to amortize by the neighborhood in the network, the fluctuations of value of tokens,

Figures 4A to 4C illustrate a particular implementation of a system with Voucher tokens in unlimited quantity and network insurance, and

Figure 5 is a block diagram of potential transactions in a transactional system with particular conditions for obtaining units of account based on reciprocity.

Detailed Description of Preferred Embodiments

Definitions

By "executable contract" is meant in particular a "wallet program" within the meaning of document WO2016120826A2 incorporated herein by reference or a "smart contract" (on the blockchain, such as a Ethereum smart contract), or else another means, which implement with equivalent functionality.

By "nodetoken" or "generator node / token manager" or "token sending node" is meant the node of a peer-to-peer network (ie the terminal connected to the network) executing the contract executable to manage the token in question, in particular to generate (transmit) token units when setting reserve units.

When we talk about the purchase (of units) of a given token, we mean the conversion, in this given token, (of units) of the reserve token of this given token.

When we talk about the sale (of units) of a token, we mean its conversion to (units of) its reserve token (the token is "returned" to the executable contract of the node of the token in question).

By "user node" (or "user") is generally meant a node sending to a nodetoken an order of purchase / sale of token units against reserve units.

A node is implemented according to a method comprising determining the value of the token units based on at least the value of the reserve, the tokens in circulation and the reserve ratio (hereinafter referred to as "RBT process", RBT for "Reserve-Based-Token"). It may be a method according to the "Bancor" protocol, or a method according to another protocol (see the explanations in https://www.blunderingcode.com/how-bancor-works/) . The embodiments presented below are intended to provide improvements.

Whenever a user node exchanges one or a set of first tokens (of one or more first transmitters) with a second token or a set of second tokens (of one or more second transmitters), managed by respective token nodes for example to acquire a product from a supplier associated with a transmitting node of a second token (in the case where he does not have enough second tokens for this purchase at the moment), the first tokens are sold and the or the second tokens are purchased at their respective tokens nodes - this can be implemented from in a way that is transparent to the user - and this causes a decrease in the value of the first tokens and an increase in the value of the second tokens (according to the "RBT method", for example according to the Bancor formula).

By "provider node" (which can be abbreviated as "supplier") is meant the product provider's terminal (property, service, right or other advantage) executing the executable contract and interacting with the corresponding nodetoken, which can advantageously be implemented. in one and the same node (merged). For the sake of conciseness, by node provider or nodetoken is meant such a node merged, but this is not limiting. Furthermore, it is considered here that each node node only corresponds to one node provider, but this is not limiting either, the mechanisms described remaining valid otherwise (in particular several provider nodes can be managed by an intermediate node common which distributes to the different providers the transferred units from user nodes according to the products to be supplied to the latter, who manages the refunds, etc.). The terms "token node" and "provider node" can thus be used interchangeably, except in a particular context.

The integrity of executable (executable) executions executing the methods described in this text is guaranteed insofar as the nodes in question (user, supplier and generator / token manager) execute the same executable contract or still a set of executable contracts that cooperate by Wallet Messages so as to form together a global executable contract (see the description of "Wallet Nodes" and "Wallet Messages" for example in WO2016120826A2). This security, where the different owners of the nodes can not modify their behavior, is essential to the implementation of the systems of the invention.

To acquire a product from the issuer of a given token, a user node usually transfers units from that given token, up to the amount of the purchase in question, and in fine these units are "burned", c ' that is, eliminated, in return for reserve units delivered to the supplier.

For the sake of brevity, we describe in the following exchanges of tokens whose reserves are of the same type (when the type of reserves used in an exchange is not specified, it is understood that they are reserve units - also called reserve account units-of the same token), conversion steps being necessary in addition in the opposite case. These conversions can be performed automatically according to the RBT method (for example according to the Bancor formula) or on the market, in particular as described below.

Also for the sake of brevity, unless otherwise stated tokens have a current price equal to 1 (ie 1 unit of the token is worth 1 unit of its reserve token), but this is only taken as an example and the switching to the case where the price is different is trivial for the skilled person.

Chapter I - Introduction

The system of this invention is a transactional network system comprising a set of token nodes, a set of user nodes and a set of provider nodes, the nodes being capable of executing an executable contract enabling a user node to obtain units. account (Voucher tokens) by placing reserve account units in reserve based on a value of the token units which itself varies according to the reserve, the number of token units in circulation and the number of token units in circulation. reserve ratio, each token node being associated with a provider node and the token being representative of a product or asset (good, service, right or other advantage) of the provider, or a group of such products or assets, the system being able, when a user node makes available spare account units necessary to obtain token units from a given token node at the current value, to be transferred a first part of these reserve account units to the reserve of said given token node, and to transfer a second part of these reserve account outside the said reserve, and to carry out the inverse transfers during a return of token units to the given token node, so as to limit or neutralize the value variations of the token unit during accessions and restitution of these token units.

It allows to automatically generate credit (in the form of token) for an economic actor not according to estimates, but according to actual demand and future demand, credit units of account (although specifically designated for the token the credit in question) being interchangeable with the units of account of another credit (another token) according to a RBT process.

Thanks to this system, each of the suppliers of a market is associated with a specific token-transmitting node (for example tomato token) and the units of this token are generated only on actual demand, for immediate or delayed delivery. in exchange for a common reserve currency (which acts as an intermediary for conversions between tokens according to the RBT procedure).

Note here that the passage through the reserve currency can be transparent: the conversion between tokens, performed by their respective token nodes by converting them to / from a reserve token, can be performed transparently for the user .

This avoids the problem of the decline in value of a shared local currency because of surpluses to be converted into other currencies, because it is through the effective expression of the needs of each buyer that the system decides to allocate credits (rather than a credit issuer such as a bank that would be based on estimates).

This is so-called "self-issued credit" currency (in the form of vouchers), but with the advantage that when a buyer has too many units of a certain currency and not enough of another, it can exchange them automatically thanks to their automatic convertibility via their respective reserves (by the RBT process).

The implementation of the token nodes generating the units of account of tokens will be described in more detail later.

This invention can be applied not only to the supply of products in exchange for corresponding tokens (these are gift certificates generated during the expression of the request), but also all kinds of "vouchers" such as gift cards , consumer credit, insurance benefits for constrained consumption (eg forced mechanic), coupons, loyalty schemes, etc.

With reference to FIG. 1, there is shown diagrammatically such a system, with user nodes UNa, UNb, UNc, ... token nodes TNx, TNy, TNz, ... and provider nodes PNx, PNy, PNz, ...

A TNx token node is associated with a provider node PNx. They can be confused.

The executable contract executed in the TNx node executes an RBT process to generate Tx token units by setting aside RU reserve units.

In the present example, each node is able to securely execute a program defining an executable contract ("smart contract"), and is for example a "Wallet Node" as defined in WO2016120826A2. Tx token units are here obtained by a user node UNb via a message (for example a "Wallet Message" in the sense of WO2016120826A2) which transfers to the relevant token node TNx a number n of reserve account units RU.

The executable contract executed in the TNx node assigns a fraction of these RU units (ie a fraction equal to the RR reserve rate, or a different fraction as one will see later) to the reserve of the token Tx, to generate a number m of tokens Tx corresponding to this fraction, depending on the price of the token.

On the other hand, the remaining fraction of the RU units received is not assigned to the reserve, but transferred in different ways according to the various embodiments which will now be described.

Chapter 2 - Tokens conversion to Voucher tokens in limited quantity, with waiting list management

The following additional features are provided here:

• in preliminary, the number of reserve account units of the first part is chosen to neutralize the variations of value of the token units during the accessions and restitutions of these;

• a token node is able to compare the number of token units obtained by the user nodes with a variable availability threshold and, if this threshold is exceeded, to modify the allocation of the new reserve account units set to provision between first and second part;

• this modified allocation has a second part with zero units of reserve account;

• This availability threshold is determined from an amount of assets associated with the provider node and a given asset blocking ratio, this determination obeying a linear or nonlinear law;

This availability threshold is determined by an executable contract at the provider node or the token node, responsive to information provided by asset blocking sensor means;

• Finally, the system may include means to modify the value of the availability threshold and / or the conversion value of Voucher Tokens into assets in response to a decrease (generally out of control) in the number of assets from which the threshold initial availability has been established.

In more detail, we propose here a model of executable contracts to issue vouchers in the form of RBT tokens convertible into assets, in limited quantity or in a controlled manner in the model-time based on smart contracts such as Ethereum smart contacts or Wallet Nodes executing Wallet Programs communicating with each other by Wallet Messages (within the meaning of WO2016120826A2), the executable contracts guaranteeing authenticity and integrity of execution and allowing in a Bancor type approach (however not limited to the tokens of the ERC20 standard) acquire or sell token account units against any type of virtual account units provided as a reserve (eg cryptocurrencies issued by a bank or government or stablecoins within the meaning of https: //www.dob .texas.gov / public / uploads / files / Laws- Begulations / New Açtiqns / _SM10. _37: QDF which states (sic) that "a sovereign-backed stablecoin May be regarded Money or monetary value under the Money Services Act, receiving it in exchange for a future payment.

This embodiment aims to make the vouchers exchangeable between them (indirectly through reserve units) and thus allow them to be used as money. Indeed, the system of the invention allows the user to use a voucher issued by a given supplier to buy even a product from another provider, the conversion of a voucher to another being done in a transparent manner . Tokens are the support of vouchers (and they are called "voucher tokens" when they take a property "voucher"), but when vouchers are themselves manipulated (bought, delivered against supply (exercised), sold, etc. ), the proposed model makes transparent to the user the support tokens.

Behavior of a token

As already mentioned, one distinguishes here the concept of token from that of "Voucher". A token is a unit of account generated by contract executable according to formulas such as those presented in the White Paper supra (Bancor formula). A voucher is the representation of a finite (active) resource of the real world, such as a gift voucher.

The voucher units are linked to the token units by assigning a "voucher" property to them (or "marking"), or by other equivalent means (management of tables for example). To introduce this notion of marking, Figure 2A presents a transition state diagram that describes the behavior of a given unit of a given token. (Note that any number of units of a given token, even with decimals, can be manipulated at a time - to be more precise we will go further to speak of m reserve units received for generated tokens (c ie the number of token units generated divided by their price expressed in reserve units), n reserve units corresponding to those marked voucher, r units corresponding to those exercised (redeemed) in exchange delivery of assets, etc.)

In this transition state diagram, the initial entry in the "Convertible Token" state (that is, the generation of the token unit by the executable contract) is due to the "Buy" transition. that is, the purchase of the token unit, see White Paper supra).

The "Conversion" transition changes the unit to the "Voucher Token" state (with corresponding marking) if the convertibility threshold is not reached and the "Conversion Request" transition changes it to the "Waiting List" state. Token "- that is," in the waiting list "(priority list), with corresponding marking - if the convertibility threshold is exceeded.

A "Convertibility OK" transition (from "Waiting List Token" to "Voucher Token") is triggered automatically when the threshold value allows it again and the token can leave the waiting list favorably (the marking being changed correspondingly). ).

The "Back Conversion" transition means the return to the "Convertible Token" state.

Finally, the unit is deleted (burned) during a "Sell" transition (that is, the unit is returned to the executable contract, see the above-mentioned White Paper) or an "Exert" transition. (whereby the corresponding supply to the voucher takes place).

Behavior of the price of the token during these transitions

With reference to FIG. 2B, during the generation of "Convertible Token" units, the token node has received here m reserve units (for example m ETH) according to its current price. Its price was then increased as in the Bancor model (see White Paper supra).

A transition from some of these units from "Convertible Token" to "Voucher Token" (up to here n reserve units) compensates for this increase (in proportion to n / m) because, according to one aspect of the invention, the vouchers provider then withdraws (1-RR) * n reserve units (only RR * n remaining in reserve). When the voucher is exercised (transition "Exert"), the complement RR * n which was kept in reserve is transferred to the node provider and the corresponding token units are deleted (burned). In the end, this means that the price of the token remains stable when buying units of Convertible Token followed by conversion and then exercise.

Conversely, if Voucher Token are "deconverted" for v reserve units ("Back Conversion" transition), subject to any conditions for deconversion, the supply node restores to the nodetoken (1-RR) * v units of the reserve units that it had received during the conversion (or with a different rule, determined in the executable contract) and the price of the token re-increases accordingly.

In a possible implementation in an executable contract, the convertible token can be subject to the following nine transitions:

1. Init: When creating a new convertible token T, the quantities R (reserve) and S (supply) are initialized - this can be done by contribution (on the part of the node of the user who creates the token) at the node (managing the new token in question) a first quantity (R) of reserve units and the corresponding generation (according to the fixed RR and the initial price required, for example: 1 token unit = 1 reserve unit ) an initial amount (S) of units of T.

2. Buy: Subsequently, the node's reception of spare units from the node of a user who buys T units causes the generation of a corresponding amount of T units (which are sent by the node to the node of this user). R, S and P increase accordingly according to the same principle as the Bancor model (see White Paper above).

3. Sell: the return of units of T (by a user node, to the nodetoken) causes the sending (in return, by the nodetoken to the user node) of a corresponding quantity of reserve units (according to the current price of T ) and said units of T returned to the nodetoken are deleted by the latter (burned). S, R and P decrease accordingly (see White Paper supra). This transition requires that the units in question not be marked "voucher" (or a transition Back Conversion - a transition of sale of units marked "voucher" that can be provided elsewhere).

4. Conversion: at the request of a user node and to the extent that the convertibility threshold is not reached, a given quantity of T units are marked "voucher" by the nodetoken (with application-dependent attributes , as bonus depending on the time ...). When T units are marked with n reserve units, the P price of T decreases to compensate for the increase that their purchase caused during the Buy transition: the supply node receives (1-RR ) * n reserve units (and will receive the complement (RR * n) when it is supplied - see Exert transition). (Advantageously, and with reference to Chapter 9, it is notably on this transition, that is to say when purchased token units are marked "voucher", that these purchases feed the system of Chapter 9 which we recall consists in triggering loans of reserve tokens).

5. Conversion Request: In the case where the availability threshold of the available vouchers is already reached, the units are marked "in waiting list" by the nodetoken by assigning them a sequence number (or "priority") to manage the priorities. (Advantageously, with reference to chapter 9, it is notably on this transition, that is to say when purchased token units are marked "in waiting list", that these purchases feed the system of chapter 9 ( remember it is triggering loans of reserve tokens), thus creating an interesting combination of the two embodiments.)

6. Convertibility OK: for these units in the waiting list, as their turn arrives (at T level), this "waiting list" marking is replaced at node level by a "voucher" marking. And the provider node receives (1-RR) * n spare units (as in the "Conversion" transition described above). (Advantageously, with reference to the embodiment of chapter 9 below, this transition involves rendering (return) the units lent on the occasion of the conversion or conversion request transition.)

7. Exert: T units marked vouchers up to r reserve units are returned to the node for supply. So as already mentioned above, RR * r reserve units are transferred to the provider node by the nodetoken and said r units of T marked "voucher" are deleted (burned) by the nodetoken. The price P of the token does not vary.

8. Back Conversion: Node request from a user who had a Conversion done on T units and now triggers an inverse transition up to v spare units. Then these units cease to be marked "vouchers" and the supplying node returns to the nodetoken (1- RR) * v reserve units among the (1-RR) * n that it had received on that occasion (or only in part, depending on the executable contract), which has the effect of increasing the price of T again (the units returned being added to the reserve). This transition then makes it possible to carry out a Sell transition of the unconverted token. It should be noted here that a reverse Conversion Request transition, with no reserve unit movement this time, must also be provided to remove the units (or part of the units) from the waiting list.

9. Termination: Finally, when all T units are removed (burned), the token is supposed to end (see White Paper above).

Advantageously, a node can be used to automate a vouchers transfer market between users: to the token units marked "voucher" or "in waiting list" can be associated an amount (for example in reserve units) that their owner (user node) is willing to accept to give them up. The receipt of this amount by the latter for the token units in question automatically triggers the transfer of these token units to the node (user) who has paid this amount. Reciprocally, users can associate with priorities in a waiting list (or a voucher marking) a proposed amount for their purchase, the acceptance of which by the owner also triggers a transfer transaction. Alternatively (or additionally), it is possible to implement a mechanism whereby regular micropayments of reserve units are carried out by users having a priority in the waiting list, failing which priority may be lowered for the benefit of others. users (depending on the amount of their own micropayments). Users can adjust their micropayments according to the priority they want: lower micropayments allow to delay conversion to voucher token (let the priority down); stronger micropayments help to move it forward (try to increase the priority). The node manages the waiting list and, at the time of conversion to a voucher token, redistributes the units received by the micropayments in an equitable manner, that is to say by completely refunding the users who have made the micropayments as planned and without their conversion being delayed, and by managing the priorities of the other users of the waiting list according to their respective adjustments, the users who adjust their micropayments to delay the conversion to a voucher token being compensated for by the surplus micropayments received to advance conversion to voucher token.

It should be noted that said threshold values can be linked to distinct dates (with given granularities, for example time slots) to which respective waiting lists are associated.

Examples of applications

A producer of goods, here a baker, makes daily N baguettes. It can thanks to this production mark N tokens (here a token "bakery", with a conversion value of 1 unit of token for a baguette), each user being able to thus convert a token "bakery" that it has in a voucher token "Bakery" allowing him to reserve, on a given date, a wand. It is understood that thanks to this embodiment, a Bancor-type model is enriched to be able to use the tokens generated in this model for the most diverse uses, with a flexibility to control the demand (Voucher tokens usage periods, discounts related to the date of supply, etc.) in particular depending on the production and its prospects. The management and visibility of waiting lists has a self-regulating effect that prevents a producer from generating excessive convertibility with respect to actual production.

In the second example that follows, we will illustrate that Token vouchers are well linked to the assets they represent. The following example shows that a loss of value of the underlying is reflected directly in the value of the token.

As an example, consider the case where the supplier is able to supply fixed quantities of a product constituting a reference good (such as gold metal). Thus a gold metal supplier who provides a convertibility of a certain type of token in gold vouchers, each representing 1 kg of gold metal. For example, it provides a convertibility with a ratio of 1 to 1 to 1000 vouchers by blocking 800 kg of gold (blocking rate 80% because he estimates that his customers will never want to be delivered for more than 80% of the vouchers that they possess, since it is trustworthy and its voucher tokens weigh less heavy than gold metal).

Suppose 1000 tokens were converted to 1000 voucher token gold (VTG), as described above.

A serious incident occurs: one steals half of his blocked stock (400 kg of gold disappear).

In this case, one approach is to adjust the exercise value of the voucher, the holder of the VTG being entitled to only 500 g of gold. The loss of value of the blocked asset (here in quantity) is spread to all the vouchers.

In the case where only a fraction of the tokens has been converted, it is possible to adjust the convertibility threshold, without however bringing it below the number of converted tokens.

In the intermediate case where the number of converted tokens is between the original threshold and the new theoretical threshold related to the loss of assets, the threshold is reduced to the number of converted tokens, thus preventing any further conversion, while adjusting the exercise value of the voucher.

Automatic variation of the price of the token according to its underlying

As we have just seen in the example above, when a token represents an underlying asset (see the examples of assets given in the preamble), the value of this underlying may vary. The method that will now be described is that the token node of this token takes into account this variation automatically or semi-automatically and varies the price of the token accordingly by interaction with the nodes that hold.

Example 1 - automatic consideration

A unit of a "Gold" token represents 100 g of gold metal contained in a secure box for example as described above, equipped with an electronic circuit (such as a wallet node device) capable of notifying a flight in case of violation of the envelope or displacement detection using the GPS module.

Example 2 - semi-automatic accounting

A unit of an Equity token represents shares of a company. The value of these units (and their variations) arises from digital signatures (attestations) from its auditor (for example), each notification of such a certificate triggers the recognition of changes in value of the shares automatically. .

Said taking into account (upon receipt of said notification, verified by an executable contract) is to automatically sell units of the token in question by the nodes that hold, when the variation consists of a decrease in value - conversely, to buy it automatically when the variation consists of an increase in value - so as to reduce the unit of the token in question to its fair value (that is to say reduce its price, expressed in units of its (or its) reserve (s), to its fair value).

This sale- resp. this purchase- (as well as the resulting price variation) is immediate insofar as it is carried out without the need for a counterpart by using the "RBT process" (for example Bancor). Advantageously, in another embodiment, it can be performed in the form of exchanges according to the embodiment of chapter 8 below.

Concretely, for the first example, when a certain amount of the gold asset disappears (following a theft), the price of the token Gold automatically decreases by the same amount, thanks to sales according to the "RBT process" (sub-components). Gold token units are returned to the executable contract by their respective owner nodes) which cause the price of the gold token to be brought to the exact value corresponding to the new underlying.

As for the second example, when the value of the said shares of the company increases, notified by digital signature or by automatically referring to an external source in a secure manner (see the previous deposits mentioned elsewhere by the same inventor), the price the amount of the Equity token increases accordingly, thanks to RBT purchases (new sub-units of the Equity token are generated by the executable contract) which cause the price of the Equity token (expressed in its (or its) units of reserve) to the exact value corresponding to the new underlying.

These purchases (respectively these sales) in order to reduce the price of the token to its fair value are executed by the nodes holding the token in question, in proportion to the units they hold. This is automatically executed except when the owner has objected in advance (by configuring its node in this direction, it may for example prefer a semi-automatic mode, which will then be implemented offline).

It is understood here that the faster each node holder reacts by performing these operations, the more these operations are performed with a price advantageous for this node (by nature even a method such as Bancor). It should be noted here that, automatically, the executable contract executes these operations reliably (thanks to the integrity of executable contracts already mentioned) and that it was designed to execute these operations without buying or selling more than in proportion to the units that the nodes in question hold. Advantageously, an automatic draw by the executable contract at said nodeoken makes it possible to avoid favoring certain holding nodes to the detriment of others.

In the case of purchases of tokens (on notification of an increase in the value of the underlying) by the token-holding nodes, these token make these purchases automatically when (and to the extent that) they hold units of token. reserve allowing them these purchases. In a particular embodiment, the warehousing node performs a method of acquiring the missing units automatically (see in particular the embodiment of chapter 8).

In the particular case of a decrease in the value of the underlying voucher tokens within the meaning of the embodiment of Chapter 2, it is provided in the executable contract that only tokens not yet marked Voucher are automatically sold as described above. .

This embodiment thus makes it possible to pass the price of a token automatically, the change in value of the underlying it represents.

Finally, it should be noted that the same approach is advantageously adopted to implement an automatic arbitration process with respect to the variation of the price of a token (expressed in its (or its) reserve unit (s) on external markets (token exchanges): when its price falls (or rises) externally (which can be detected automatically by automatically referring to an external source in a secure way, as already mentioned), units are automatically sold (or purchased) to token holders, in proportion to their holdings, in order to automatically balance their price.

Assets playing the role of tokens

Advantageously, the blocking of the assets, in the case of tangible goods, can be carried out by means of detection of presence or integrity of the goods, these means cooperating with an executable contract for generating / updating the threshold convertibility. This may include locks, electronic seals, machine-readable codes, for example in the sense of the "Sensor Actuator Modules" described by the applicant in PCT / IB2017 / 057707 whose contents are incorporated by reference, or else a combination of the integrity of an envelope as described in US Patent Application No. 62/586, 190 in the name of the applicant, the contents of which are hereby incorporated by reference, optionally in combination with an integrity detection geographical position by GPS. Other approaches such as presence detection of the asset by weighing, security type described in https://www.crowdsupply.com/design-shift/orwl, etc., possibly combined with a GPS detection can to be implemented.

In the case of using a GPS, it is expected to reset the position in secure conditions at each change of hands of the asset.

Not only tokens (be it convertible tokens, waiting lists or vouchers tokens) can be transferred from one node (user) to another, but also (of course) assets (that these tokens represent) can transferred from one node (provider) to another.

When switching providers for the same assets, the corresponding tokens are automatically converted to tokens issued by the new provider's nodetoken.

To continue the example of the stock of 800 kg of gold which gave rise to 1000 VTG (see above), if 200 kg (ie half of the stock remaining after the incident), that is to say one quarter of the initial stock, have been transferred to another supplier whose tokens are VTG1, a quarter of the tokens voucher, a quarter of the tokens on the waiting list and a quarter of all other tokens in circulation are automatically converted into VTG1.

The change of supplier is triggered by a process that is corroborated by the aforementioned means of detecting the presence or integrity of the goods.

Advantageously, the assets play here an "indivisible" token role transferred from one provider to another and managed in executable contracts. For example, a 100 g tin of gold metal in a small self-sealed box can be traded as a token, in the same way that gold metal took the place of money in the distant past (voucher tokens described above ensuring as for them exchangeability and divisibility in any desired fraction). Such an asset "100g gold metal" is a safer token because when it is acquired, in the sense that one has the asset itself rather than a promise of its supply. This restores the original function of a currency constituted by a good which determines its value. This applies to both precious metal and other types of assets.

Escrow account In an alternative embodiment, the system is such that the second part of the reserve account units (the one that is not put in the reserve) is transferred at least in part to an escrow account. This escrow account is advantageously managed within the considered token node.

The executable contract includes management rules for the escrow reserve units.

For example, the second part of the reserve units received is by default in a "returnable" mode, but can switch to a "nonreturnable" mode at the time of effective reservation of a product (typically a Wallet Message "indicating a firm order of the product, whereas the initial obtaining of the units of the token in question was only an intention), for example for immediate delivery or at a later date determined according to the delivery date envisaged during the reservation (eg 3 days prior to the scheduled delivery date, as the supplier would have costs to incur as of this time) - the concept of date being able to be variable granularity as mentioned later in this description when we talk about Time Ranges .

It should be noted here that only the returnable mode presents a risk of fraud - fraud in the sense that the supplier does not return the second part when returning the token - but offers the essential advantage of offering convertibility with other tokens.

So, advantageously, the executable contract provides that the second party goes into an escrow account at least until the moment of the reservation (and only then will be transferred to the supplier when it can no longer be question that he returns them), which will have the effect of mitigating any risk of fraud (essential advantage / classic vouchers, which do not require a request for issue with transfer of reserve tokens at the current price from a user node and can be issued to infinity by the supplier himself). It should be noted, however, that the said fraud can also be mitigated by associating reputational information with the token.

In summary, we have here the following possible events:

(1) obtaining units of the token with advantageously setting reserve units (forming the second part) in an escrow account (here the mode is releasable),

(2) (optional) return of token units (ie the sale of units of the token, ie its conversion into units of the reserve token in the sense of Bancor),

(3) reservation of product (s), involving the transition to the non-returnable mode and transfer to the supplier of the corresponding second part, immediately or at a date determined according to the executable contract,

(4) delivery and removal of token units and transfer of the first party to the supplier.

Note that in the case of a right provided implicitly and entailing no subsequent supply, steps (3) and (4) are absent, but there may be restitution (step (2)).

In the latter case, in general the units forming the second part are directly transferred to the supplier who is required to return them in case of an event causing step (2) and plays his reputation. Advantageously, the units forming the second part can also be held in an escrow account for a limited time and transferred to the supplier after (if not returned in the meantime). To summarize, it has been described until now that a limited number of tokens (generated by a node) are marked "Voucher" (and correspond to assets blocked or blocked in the future for these Voucher Tokens), unmarked tokens. may be in "marking waiting list"; each such marking directly entails the transfer of (at most) an amount (1-RR) * n of reserve units to the supplier (s) (n being the number of units marked Voucher divided by their price P expressed in reserve units), which restores it in case of deconversion; the supply (s) corresponding to (a) Voucher token being made at the request of the knot that owns it (or as planned from the moment of conversion into a Voucher Token), the voucher-token then being burned (deleted) by the node and the complement (at least RR * n) being then transferred to the provider (against this provision).

Thus, the system of this embodiment is an alternative to the Bancor model, keeping the advantages but also allowing to associate tokens of this model vouchers representing assets in limited quantity (which does not allow Bancor) , the purchase / sale of tokens does not cause a change in the value of tokens in terms of reserve units used when vouchers are associated (or up to factor IH only as will be seen below) .

Chapter 3 - time factors

This embodiment includes the following features:

means are provided for automatically causing tokens unit accesses at a given token node in response to a reported change in the underlying asset to that token unit, so as to adjust the value of the unit token on the value of the underlying asset that has changed.

Optionally:

* This variation is reported by detecting a change in quantity of a physical asset constituting the underlying asset.

* there are provided secure means (such as sensor means managed by an executable contract) to detect this variation.

* this change is reported by detecting the change in value of an intangible asset constituting the underlying asset.

* secure means of communication, managed by an executable contract, with a data source capable of providing the value of the intangible asset.

In more detail, when purchasing a token, the buyer (user node) can communicate to the supplier (supplier node) an initial set of one or more Time Ranges in which the buyer will request to be supplied ( immediately or in the future). This set can be modified later.

Advantageously, the Time Ranges communicated to the provider can be fixed or depend on rules and in particular a resolution of constraints, and for example be gradually restricted by adding additional constraints (depending on the application).

In response, the supplier communicates to the buyer a set of Dates, located throughout Time Ranges release, for which its supply capacity (typically a production capacity) is not yet reached and the product will be available. (in the current state of the Time Ranges communicated to the supplier).

By Date (or potential delivery date) is meant here a date by which the supplier believes it can provide or not. However, instead of one-off dates, here we consider dates with a given granularity or time slots - for example, time slots or quarter-hour slots. A Date is thus a time interval for which the provider node reserves a certain supply capacity (which normally is limited) and according to which it will indicate to the user whether he can provide it or not in this interval.

The supplier node calculates the consumption (thanks to Time Ranges related to the purchases of the units of its token) of its supply capacity at each Date as follows:

* The amount of each purchase by a user is divided by the total time (expressed in units of time in the granularity set by the provider) of the Time Ranges that that user has disclosed for that purchase, and the result of that split is spread on along these Time Ranges by associating it with each Date included in these Time Ranges.

* By cumulating on each Date these results for all users, the supplier node determines the probable consumption of its supply on that Date.

These operations are performed incrementally when creating and updating Time Ranges related to a purchase of token units and, for each Date included in these Time Ranges, if the supply capacity is already reached, this purchase is made in waiting list (see above), and otherwise the relevant date is made available for this purchase.

The reserve units received during the purchase of the token by a user are decomposed, proportionally, into a first part corresponding to the Available Dates and a second corresponding to the Waiting List Dates for this user. For the first, (1-RR) * n reserve units are transferred to the provider node and only RR * n units are put in the reserve of the token, while for the second all the reserve units received go to the reserve ( second part equal to zero). (As previously described in Chapter 2, the first part includes units marked voucher, and the second part includes units queued.)

The user can then modify his Time Ranges to better match the Available Dates. The capacities at the different dates are then recalculated and the allocations of the reserve units are re-allocated accordingly.

Advantageously, the user nodes close to one and the same provider node (see the chapter 9 tribal scores below) mutually exchange the available dates communicated to them by the latter. They also exchange the information on the execution of the supplies, as well as any defects in supplies, on the dates in question. These notifications allow them to check a vendor's reliability and automatically penalize it in the event of a failure.

Chapter 4 - Introduction of the factor IH

In the above, the amount of spare units transferred to the provider node is (1-RR) * n.

An embodiment is introduced here in which the first part of the reserve account units is constituted by a first sub-part whose number is such that they neutralize the variations of value of the token units during the obtaining and rendering thereof. and a second sub-part whose number is such that they generate a controlled value variation of the token unit, with an increase on obtaining and a decrease on the restitution, with the following options:

* the number of spare account units of the second subpart is determined according to a variable variable IH associated with the token and managed by its token node.

the parameter IH is a function of time data relating to the supply request and the supply offer at the supplier node.

the parameter IH is a function of a density and / or a distribution of possible supply instants in one or more time intervals where the supply is requested. the parameter IH is a function of population data of different user nodes which obtained units tu token associated, these population data can be weighted by coherence data, between these nodes, vis-à-vis token units other types they have obtained (conformity).

the parameter IH is a function of reliability data of supply of the products corresponding to the considered token.

the parameter IH is a function of at least two of these data.

a token node is adapted, in case of variation of the parameter IH, to redistribute the assignment of the reserve account units to its first part and its second part by transfer from outside the reserve to the reserve or vice versa.

In more detail, in this embodiment, a parameter or factor IH that is defined in more detail and whose implementation is described later, increases the part kept in the reserve during voucher token markings, the term RR * n being replaced by (RR + IH) * n and the term (1-RR) * n being replaced by (1-RR-IH) * n, the factor IH allowing somehow to reproduce the role of "the invisible hand of the market "when marking. It is understandable that with this factor, when marking token units voucher token up to n reserve units, the vouchers provider only withdraws (1- RR-IH) * n reserve units (at instead of (1-RR) * n), and this has the effect that the increase in the price of the token that occurred during its purchase is preserved at the limited height of IH. Then, when the voucher is exercised (transition "Exert"), this limited upward effect is canceled (except variation in time of the value of factor IH in which case the increase is not exactly canceled): the complement (RR + IH ) * n remained in reserve is transferred to the provider node and the corresponding token units are deleted (burned) - so the price of the token recovers more or less its value. And, of course, when Token vouchers (up to n reserve units, ie the number of voucher token units divided by the current price P of the token) are returned to the executable contract (executed on the node) by the user, (1-RR-IH) * n reserve units are at least partially (at a service fee close, or according to other rules) refunded to the user (unless automatically pass through a "Back Conversion" deconversion transition beforehand, as specified above, to return the (1-RR-IH) * n units to the pool before the tokens are returned.

We understand that increasing IΊH

* is expected to make the token more volatile (since a larger portion of the reserve account units received goes into reserve, denoted "(RR + IH) * p") and

* reduces its pre-financing part (denoted by "(1-RR-IH) * p").

The idea here is that the more volatility (IH increases), the lower the pre-financing, which encourages the issuer of the token to have a safer underlying (by increasing its production capacity, the quality of the product , etc.) to make his token less speculative and lower the value of IH (thus returning to greater pre-financing).

But IH is not the only factor that determines the volatility of the token. Initially, in a Bancor type system, it is the RR reserve rate that determines the volatility of the token: the greater the RR, the less volatile the token is. With IH, this role is played by RR + IH (IH varying between zero and 1-RR).

In case IH is zero, there is no volatility at all regardless of the RR value. The factor IH makes it possible to control the impact of the reserve ratio on the volatility: the greater the HI, the more the RR determines the volatility of the token and the smaller the HI, the less the volatility of the token is determined by RR.

Example

In a Bancor type architecture, there can be no limitation on the number of "Baguette" tokens that the baker's vendor node sells, because they are generated automatically (by the executable contract that runs on the baker's node) whenever one wants to buy one - if not, there would be no way to always be able to arbitrate with the external markets. But because of this non-limitation, there may be too many tokens generated in relation to the baker's production capacity (suppose he becomes a rising star and buyers speculate on the value of his token ).

The purpose of the factor HI is to capture this aspect of speculation: if there are probably more tokens generated than chopsticks that the baker can provide (and a method is proposed in the following to calculate it), then IΊH is higher, which allows the price of this token to go up to speed IH, but also to go down as fast if people get rid of it (ie if they sell the baguette token), which happens for example if its Reinsurers reject it, its reinsurers being typically the neighboring bakers who provide it when it can not (as described later). Typically its reinsurers will replace it during a failure of the oven or health problems preventing it from producing normally, but any kind of reassurance is possible, for example that of providing chopsticks in its place in case of a failure. too much demand. An executable reinsurance contract then automatically swaps the Baguette token with a Baguette token from another baker via one or more reserve tokens.

As will be seen below, thanks to the factor HI, the tokens cover all the cases, and in particular this model makes it possible to achieve a unification between the traditional trade and the insurance:

Take, for example, boiler maintenance tokens (with helpdesk and assistance at any time), such a contract can indeed be seen as an insurance contract (insurance that the boiler will always continue to operate or with, if necessary, limited periods of interruption).

The supplier of the boiler maintenance service will typically associate with its token a price P corresponding to the annual basic maintenance of a simple and basic boiler in very good condition, requiring only rarely troubleshooting or assistance.

Nothing will prevent him from selling 1.2 units of this token a year to the owner of a boiler X which, according to him, may cost him a little more work (or for a larger house to heat); 5 units per year for a very old Y boiler, etc.

Thus, the transaction amount (corresponding to the insurance premium) can be calculated (or negotiated) on a case-by-case basis, depending on the risk presented by the buyer. (It should be noted that the risk presented by the buyer is not taken into account in IΊH.The IH is rather a function of criteria such as the size and therefore the availability of his team given the volume of his clientele, his skills and ability to repair breakdowns, its speed of intervention (which is mainly a function of distance), etc.)

This does not prevent, for the market to remain socially equitable, to apply constraints to this negotiation (fixed or framed public rate), these constraints being managed by the executable contract.

Taking into account factor IH leads us to widen the concept of voucher tokens, allowing them to be used for insurance applications as in the example above. This is what we will now describe:

We have already seen for voucher tokens that, when buying units of a token T unmarked Voucher ("Token" simple), all units (T reserve token) received for this purchase will in the T. reserve

Conversely, for a token T marked Voucher ("Voucher Token"), it is a predetermined fraction RR * p (p being here the number of reserve units received for this purchase at price P) which is assigned to Reserve, the rest being attributed to the supplier, in lieu of pre-financing or down payment (or blocked to form "blocked assets" as described below).

It may be desirable for the notion of Voucher to be gradual, with a variable factor IH ensuring the progressivity between a non-Voucher token and a Voucher token.

Thus all the tokens are here, in a way, "more or less" of the Vouchers and it is the factor IH (for "Invisible Hand") which makes it possible to indicate to what extent they are, that is to say to say are approaching Voucher tokens presented above - the case IH = 1-RR representing the extreme case of tokens that are not Vouchers at all.

To materialize this principle, if:

p is the number of reserve units received,

RR is the reserve ratio, and

IH is the aforementioned factor,

we allocate (RR + IH) * p units to the reserve, and (1-RR-IH) * p constitute the deposit paid to the supplier.

We will now generalize the tokens by keeping the formulas

reserve = (RR + IH) * p and

pre-financing = (1-RR-IH) * p

for all tokens.

There is thus no distinction between Token and Voucher Token, and the case IH = 1-RR is a special case where the commitment of supply of product is not associated with the token (case of classic tokens at Bancor ) and therefore where all the units of reserve tokens received go into the reserve.

In the following, we will designate by the term "Token" both the traditional tokens at the Bancor Voucher Tokens with progressivity defined above.

The vocabulary used has already been defined earlier in the introduction. Let's remember that :

The purchase of a product from a supplier is here seen as:

1. Obtaining a corresponding number of units of the token associated with this provider (that is, their purchase by a user node, called "user" or "client"),

2. the product in question being possibly (immediately or subsequently) supplied in exchange for those token units purchased.

The tokens then play the role of "vouchers" purchased to obtain the supply in question. Of course, in return for the benefit of "pre-financing" it withdraws, the supplier can offer incentives, such as discount, bonus, etc. in particular as a function of the time that has elapsed or must elapse before the exercise of the voucher in question.

The purchase of units of a token T here means the conversion, in units of this token T, of reserve units of this token T (according to a given RBT method, such as Bancor).

The provider for a given token T is a provider node associated with the token having issued said given token T (and for ease of reading, it is considered here that there is only one, but this is not limiting). By "buyer of a token T", we mean purchaser of a certain amount of units of the token T in question, allowing him to be provided with a number of units of a product of the corresponding supplier. The transfer of the part (1-RR-IH) * p to the supplier can be seen as a payment advance, the supplement (RR + IH) * p being paid at the time of supply (or the part (1-RR-IH ) * p that can be repaid (in full if the value of IH has not changed) if there is no supply, depending on the executable contract (as in the chapter 2 embodiment).

For the purposes of this explanation, it is considered that the supply is made according to rules specified in the executable contract, such as "on reservation", "on a waiting list", "by drawing lots", etc. or "trigger event" as we will see below. These rules may impose more or less commitment on the part of the supplier and, as already explained, the value of IH is representative of this commitment: the factor HI is even higher than the node supplier does not engage on the future inventory, and / or that the planned supply is distant in time or uncertain at the time of purchase of the token. The factor IH can thus depend on a certain number of parameters such as capacity and production rate, risk factors, possible period of exercise of the token, etc.

More generally, the value of the factor HI and its variations over time can be determined by any process, in particular for the purpose of regulating the price of the token according to the environment or circumstances (see in particular example of Chapter 1 1 where the HI factor depends on the traffic). Artificial intelligence algorithms may be part of such processes.

Chapter 5 - Times Ranges and Factor IH

An embodiment based on Time Ranges and Possible Delivery Dates in combination with factor III operation will now be described (see Chapter 3 and 4 above).

As described in Chapter 3, when purchasing token units, the buyer (user node) communicates to the vendor (vendor node) an initial set of Time Ranges, and the vendor then communicates to the buyer a set of Delivery Dates. possible supplies, located in these Time Ranges. But here, the supplier node determines its IH factor from its remaining supplies capacities at these dates (surely, remember, thanks to the properties of integrity / authenticity of executable contracts).

The initial value of the IH factor is determined (and then incrementally revised) when Token units are purchased by the user nodes based on the Time Ranges coverage by the Dates communicated to them and the remaining available capacity on those Dates.

In one embodiment, the value of IH is determined as a function of the density and distribution of the remaining available capacity in the Time Ranges - better the Dates in the future cover (in density and distribution) the Time Ranges specified by the users, less is the value of IH.

The density is for example determined by subtracting, from the available capacity at different dates, the expected consumption of the users, that is to say the units they bought divided by the durations of Time Ranges they indicated during of their purchases.

The distribution is for example determined by dichotomous decompositions, to granularities and more and more thin so as to form a tree. At each decomposition level, the distribution level (ie a value representative of the regularity of the distribution in the time window constituted by the concatenation of the Time Ranges) is calculated by taking into account the difference between the median remaining available capacity. before decomposition and the remaining available capacity of each side after decomposition. The path of the tree by adding the values to the different decomposition levels makes it possible to obtain the distribution level at the finest level (Léa algorithm).

The IH factor as well as the Dates communicated to the users are incrementally revised because user nodes modify their respective Time Ranges (typically by adapting to the possible Delivery Dates and Available Capabilities communicated by the provider node) or finalize their reservations to Specific dates.

Thus, the value of this factor for a certain purchase of token units is revised upwards when the coverage of the Dates communicated corresponding to this purchase decreases, which causes a decrease of the financing part: when the factor IH taken for a purchase of units of a given token increases, the formulas reserve = (RR + IH) * p and pre-financing = (1-RR-IH) * p are recalculated and the provider transfers the missing reserve units thereby to the nodetoken which adds them to the reserve of this token. Therefore, it is in the vendor's interest to maintain the highest possible supply capabilities to keep the value of IH as low as possible and to benefit from greater pre-financing for as long as possible.

Advantageously, as described in Chapter 3, nodes obtaining units of the same token communicate to each other the dates communicated to them by the latter, which enables them to check the coherence of these data (advantageously, these are the nodes users close to the same provider node - see the tribal scores in Chapter 9 below). They also communicate to each other the information of execution of the supplies, as well as if necessary the defects of supplies, to the reserved Dates. For example, a supply defect may result in a penalty in the form of a revised HI value for that defaulting supplier.

Another approach to determine factor HI is to give a lower value of IH to more trusted issuers. The quality of "trusted issuer" is determined by counting the number of nodes that buy the considered token. To avoid a Sybil attack, these buying nodes are weighted by a compliance datum that takes into account the types of tokens that the other nodes that buy this token also buy - because the more they conform, the more credible they are. With this weighting, a "Sybil attack" would actually favor the nodes it tries to disfavor. These other nodes may be those with a strong tribal score (ie, a close tokens purchase profile, as described in Chapter 9). The integrity of these weighted counts is guaranteed at the level of executable contracts.

Alternatively, it is sufficient to weight these counts with the number of reserve account units paid for the purchases in question (a Sybil attack to benefit from pre-financing will not be worth it if it involves blocking too many units reserve - as this would neutralize the intended purpose). These two weighting approaches can also be combined.

In addition, there may be many buyers of a token considered, not for the purpose of obtaining a product associated with the token, but to speculate on the value of the token. In this case, the fact that (according to this method) IΊH decline will dissuade them (because more IΊH falls, less the price P of the token fluctuates), but if one wants to take into account that these purchases are speculative and increase IΊH rather than lowering it, advantageously we will combine this method with the previous ones (giving them priority in this case).

According to yet another approach, the value of IH is based on information indicating whether neighboring nodes of a given token node obtain or not the product when they present the token (or in a more elaborate variant, if they have been delivered on time or not in relation to their past bookings). Neighboring nodes are here those who have a close tokens purchase profile (strong tribal score). So, if until then regularly its neighbors have obtained the product corresponding to the token, then presumably the supplier does not make promises in the air, he is reliable and his IH deserves to be low (and he is thus entitled to a strong pre-financing), and vice versa.

This approach can also be combined with the previous ones.

Chapter 6 - Network Insurance and IH Factor

We will now describe the particular case of a "trigger event supply" (such as the occurrence of an accident). In this embodiment, the token units for a given token node are adapted to be converted into supplies of products or reserve units previously blocked in blocked assets, and further comprising means for determining a number of units. tokens to be obtained to obtain a given quantity of products or reserve units previously blocked according to data of probabilities of events triggering such a supply, at least a portion of the reserve account units which allowed to obtain the units of tokens being transferred to the supply node of the products and / or to the blocked assets.

It may be supply of products as above, or supply of reserve units. In the latter case, said units (1-RR-IH) * p then constitute "blocked assets" for this purpose.

The type and modalities of validation of triggering events are defined and implemented in the executable contract.

Note that in the case of supplies on triggering events, tokens generally represent more assets than actual assets (since "all accidents do not arrive on the same day").

For example, on a population that will buy tokens to get a certain drug (let's say that the price of a medicine box here is a token unit), only part of that population will get sick and actually convert these tokens in a box of drugs.

The volume of drugs to be supplied is therefore less than the number of tokens purchased. It follows that these tokens must be able to be obtained cheaply without disturbing the economy of this market.

To illustrate this, if for example a person in a population of 1000 falls sick and needs a box of drugs, it is sufficient that each person buys for 0, 1% of the price in tokens of the box of drugs for the availability of the medication box is guaranteed. In the end, the price to be paid (in tokens) by each person is equal to 0, 1% of the price of the box of medications (neglecting here the service fee intermediation fee or other).

This unifies "classic" business and insurance.

Advantageously, when all the assets are already consumed and new triggering events occur (and trigger asset deliveries to be made), the new supplies to be made form a "supply waiting list" and are executed later when new assets are available. become available (for example in response to a "call for contributions") (see also the section "Reinsurance" below).

Typically, but without limitation, a triggering event is a notification by a user node of a "disaster" validated by a hardware device and / or digital signature of one or more arbitrators / trusted experts provided in the contract executable and, typically, the supply to be made represents the payment of damage caused by the loss; another example trigger event is the fact of winning a lottery; finally, a type of triggering event could even be the simple request by a user of the supply of the asset in question.

In all cases where this is possible, the triggering event is preferably detected by sensor means managed by an executable contract, or via a communication channel with a reliable source of information (for example, the attestation, digitally signed, of a doctor, the information system of the lottery, ...), with again the intervention of an executable contract.

Of course, the executable contract may provide that the recipient user can confirm or cancel the triggering event.

Thus, a triggering event will be an event whose notification is validated by an executable contract.

To differentiate tokens generating trigger-based supplies from tokens acting as product vouchers (or to distinguish them from voucher tokens of the embodiments described in Chapters 2 and 3), they are also known as "support tokens". .

We will focus below in case a trigger event allows the unlocking, not products, but reserve units included in the blocked assets.

As shown in FIGS. 4A-4C, the blocked assets may comprise said (1-RR-1H) * p spare token units - minus a portion possibly taken by the provider (s) for the service rendered - the blocking is automatically implemented ("enforced") by the executable contract.

On each triggering event, some of the blocked assets and a portion of the pool are automatically provided by the executable contract to the receiving node (s) of the intended medium (s) in the executable contract for the event in question. The portion of the blocked assets is based on an estimate of the triggering events that may occur: as for the part of the reserve, it is calculated so as to keep the price of the token stable (at the factor near). This is described in one example with reference to Figure 4A which shows the current situation of a support token "T" having a RR of 10% (10% of the received reserve token units are directly allocated to the reserve by the node token) and a price of 1 reserve token unit (1 unit of T = 1 reserve token unit), where 99% of the 90% of the reserve token units received (1-RR = 90%, IH is here neglected) are blocked by the executable contract to form said blocked assets, the remaining 1% of this 90% being taken here by the supplier (F) for the service rendered.

In the Figure, 1000 T token units have already been purchased and 891 spare token units have been blocked to form the blocked assets (1000 * 90% * 99% = 891).

Figure 4B illustrates the case where additional x tokens purchased (T) are split into:

a part R 'to increase the reserve R,

- a part F 'for the supplier,

- the rest being added to the blocked assets.

In this example, it is estimated that, on triggering events, not more than 10% of the tokens T purchased (here 100 tokens) will be returned (to receive the supply in question). This estimate (taken as a parameter) allows the executable contract to determine that each Tx token unit provides 8.91 ABx blocked asset units on a triggering event (see Figure 4C). Indeed, these 10% here represent 100 units of token T and the number of 891 reserve units blocked as underlying assets has therefore had to be divided by 100 to obtain what the executable contract will provide to the destination node (s) for each token T unit presented on the triggering event.

As for the said (RR + IH) * p units of the reserve, each token unit T presented on the triggering event (which is then burned) causes the destination node (s) to be transferred to RR + IH units. reserve (if the current price is 1) - thus, in this example, 0.1 units are removed from the reserve - so as to keep the price stable (similar to the embodiments of the previous chapters).

To illustrate more concretely, suppose that the triggering events are here breaking a leg and the reserve token units are ETHs; then each unit of token T costs at a given time 1 ETH (Tx) and allows to receive 8.91 ETH (ABx) + 0.1 ETH = 9.01 ETH when its holder breaks one leg.

The underlying assets may also be hospital care units, 100g gold metal ingots, 50kg rice bags, etc., and to the extent that they are "indivisible token" (or "Solid tokens") managed by the executable contract as mentioned above, their blocking in underlying assets is also enforced by the executable contract automatically (as well as their unlocking on triggering events, which can be determined as it has been said either by sensors or reliable sources of information under the guidance of an executable contract).

Still in the medical field, the use of underlying assets of the care type can be triggered by physiological measurements made by sensors embedded in the human body and associated with a secure microdevice wallet node device type also embedded and powered by a battery, the executable contract being advantageously able to collect a validation action or non-validation by the user beforehand (preferably without this non-validation by use is broadcast in the network).

Advantageously, the tokens also have a limited life (an expiry date) and the token purchases must be renewed by the user at the time of their expiry dates (similarly to an insurance premium) , to continuously benefit assets in case of trigger event.

The lifetime of the tokens (and their price) is determined in such a way that the renewal of the token purchases offsets the supplies made to the recipient node (s) on triggering events. Using the previous example, each token T unit provides 8.91 + 0.1 spare token units on a trigger event if it is estimated (statistically) that 10% of the tokens are returned on trigger events per year and if the tokens T have a life of one year (the one-year period was taken here as an example). Thus, the life span of the tokens is a function of the frequency and the volume of the triggering events (and of course the price of these tokens). Note here the advantage of the possibility of purchasing tokens support for very short periods of time. micropayment).

When tokens expire, the unutilized assets generate new units (representing those unused assets) for the holders of these tokens.

Advantageously, the amount of the reserve token units (said 8.91 + 0.1 units) provided on the triggering event and / or the lifetime of the tokens can be dynamically adjusted (continuously or periodically, or according to other rules) according to the the amount of tokens already presented on trigger events up to that point (similar to the units of account of a life insurance account ("Mutual Funds")). Chapter 7 - Networked Insurance and Reinsurance (Networked-lnsurance)

In this embodiment, the nodes form a system of provider / recipient nodes of "support commitments" of a certain type (i.e., triggering asset delivery commitments, in exchange support tokens) - each recipient node can itself provide a support commitment of the same type to certain other nodes, the latter to still some others, and so on, the nodes and the support commitments of a given type forming a P2P network of "networked-insurance".

Reinsurance: "unity is strength"

In a networked-insurance context, support commitment provider nodes (token nodes generating token support) have an interest in "reinsuring" each other and thus better benefit from the law of large numbers. A reinsurance commitment is that the executable contract guarantees ("enforces") the provision (at the receiving node of the reinsurance commitment) of the asset (or part of the assets) of the supplier of the reinsurance undertaking. reinsurance commitment when the own assets of the node benefiting from the reinsurance commitment have been exhausted.

For example, in the case where the underlying asset (or blocked asset) is a provision of care, this mechanism ensures that a caregiver who is unable to provide care (eg lack of care bed hospital) may be provided by another caregiver (a neighborhood hospital) to provide care. Thus the following example illustrates the use of care units (tokens Toi) versus support units (tokens To2), the former being used as a reserve for the latter, the needs of care units in excess being satisfied. through an executable reinsurance contract.

The care units You are here are tokens marked Voucher Token according to an embodiment of one of the chapters 2 to 4 and are dated.

Concretely, in this example:

- the reserve ratio RR of the reserve in You for To2 is 10%.

- On average, 10,000 users each buy 1 To2 support unit, at the price of 1 TB2 for 1 You dated (exercisable) that day. To2s have a life of one day.

- there are 100 beds at the supplier (the supplier is the hospital that sells the Token You). The bed costs on average 90.1 units of care (You) as it follows from the calculation that follows. The hospital has set the price of the unit of You accordingly (for example at 0.3 ETH).

Based on an estimate that each day 100 users each have 1 TB2 on triggering event, the fixed executable contract that each To2 allows you to benefit from 90.1 units of care You trigger event (indeed, the "cake" of 10000 units of You, minus 10% of RR, is divided into 100 parts: 9000/100 = 90, and the reserve of 1000 units of You is divided into 10000- neglecting here the part taken for the management of the insurance).

An overrun, if any, in relation to the number of available beds means that too many To2 units were presented that day (trigger events are in excess of estimates), causing the units to exceed of care (You) constituting the blocked assets. Upon such an overrun, an executable reinsurance contract is triggered automatically to tap into the blocked assets for another support token (To4) - here care units (To3) of a hospital in the neighborhood (searched for from close by , automatically, until finding one having a bed available - see the embodiment of chapter 10).

With respect to the law of large numbers, such executable reinsurance contracts potentially offer the power of a risk pooling to a P2P network (having a networked-insurance topology as stated above). centralized (conventional insurance), with the ability to treat the same level of financial actors (insurers properly so-called) and operational players (medical world, repairers, etc.).

Deployment of network insurance

As far as the deployment of support commitments is concerned, the implementation of executable support commitment contracts is advantageously triggered automatically by other executable contracts that result in the purchase of tokens support, thus automatically starting the executable contract. the corresponding support commitment. For example :

* When buying a product, the buyer (or the seller) automatically acquires token support units from the seller (or the buyer) for example 1 / 100th of the amount of the purchase (remember here a token support is divisible).

* Geographic proximity (or non-geographic dimensions) between any two nodes (or predefined conditions) periodically triggers a purchase / sale transaction of token support units. This provides support locally (for example car repair service in the event of a breakdown, etc.) rather than from a remote support provider entity. Advantageously, the user node automatically receives GPS coordinates information (for example when it is embedded in a smartphone), to automatically trigger the purchase of corresponding tokens support from the commitment providers.

Chapter 8 - The Network Effect

In this embodiment, the system further comprises means for transferring units of a given token, in response to an increase in utility or use of a network of token nodes having that given token. as a reserve unit, towards the reserve of token nodes contributing to this increase.

This provides a reward for a "network effect" as a function of the participation of the nodes in the operation or development of the network. Advantageously, the increase in utility or use of the network is determined by at least one of the following factors:

- an intention to purchase a good or service, materialized by the purchase of units of a specific token by setting aside the given token,

- the actual purchase of the good or service,

- the conversion of the specific token Voucher token (according to previous chapters) for exchange with the good or service,

- increasing the threshold of availability of the specific token in Voucher token. Different means can be used to implement a measure of the network effect. The network effect is here in particular in the meaning of the Metcalfe law for example, which states that the utility of a network resides in the number of its potential links; but these increase according to a law in n ² . A network effect in the sense of Reed's law, number ³ , which determines the potential number of communities that the network can train, is also relevant. The principle underlying this embodiment is to reward nodes of a network when they increase its utility.

Take the particular case of "indivisible tokens" representative of an active gold metal as mentioned previously (call them "solid tokens"). The more solid tokens there are, the more the network increases its utility because not only can one buy conventional voucher-tokens (divisible) from such suppliers, but one can also go meet such a supplier on the spot to buy him tokens solid and increase the security of his credit.

For the duration of the sale of a solid token (here a gold token), the seller is paid for it (he has an interest in expanding the network by putting his strong tokens on sale). Reciprocally, a user can declare to the network his request for a solid token and be paid for the duration of his request.

The same approach can be adopted for sales / purchase service applications. Throughout its duration, the sale (or the purchase request) of a service is rewarded, as it benefits the network. Examples include transport offers from "vehicle" nodes and transport requests from "passenger" nodes (advantageously, the positions / movements of these nodes being captured in a secure manner, for example as described in chapter 1 1- see also the applications cited in this same chapter).

This principle can be generalized by offering rewards to different types of actions that generally increase network activity (ancillary services to a basic service, new physical assets, etc.), if necessary with security by sensors connected to the network.

In a particular embodiment, for a first given token, the second tokens that have it in reserve form its network and the contributions to the network effect are:

• the purchase intentions (by user nodes) for products - which are subsequently purchased by these user nodes - products of supplier nodes whose corresponding tokens (seconds tokens) have as reserve this first token given, and

• the sales by said provider nodes of said products that these user nodes have actually purchased.

The purchase intention start date is triggered by the purchase (by a user node) of units of a second token. Then, when these last units are actually used for a purchase (of a product of a supplier corresponding to the second token), this purchase causes a reward consisting of units of the first token (which thus allow the user node to purchase more money). second token units).

As for the reward of the token node of said second token, the product of which has actually been purchased, it consists in transferring to this node more units of the first token. Advantageously, the start date of the sale is triggered by the provision of vouchers (which can be associated with tokens to convert them into a "Voucher token") according to an embodiment of chapter 2 or 3, and the duration of placing on sale ends when the voucher-token is formed (that is to say at the time of marking the token voucher-token).

These rewards advantageously allow the regulation of the price of a token, and this is what will now be described. As already mentioned, for each token, an underlying is the utility of the network formed by this token. In this sense, with each purchase (each generation) of units of a second token up to a unit of the first token, a portion of the IH * p reserve units of the first token (which would cause its price increase - see description above) is dedicated to the operation and development of this network, in particular redistribution to the nodes according to their contributions to the network effect as described above.

The price of the token is regulated by adjusting the size of this part.

In addition, the volume of earnings received by each node (user or provider) for its contributions (contribution to network operation / development, contribution to the network effect) determines to what extent this node participates in the governance of the network (to decide of these adjustments).

A case of application of this process is the creation of a first "cooperative" token whose second tokens (which have it as a reserve) are generated by nodes (token nodes) belonging to the members of a given group for example, a producers' cooperative. Prior to the creation of a cooperative token, the group members together decide the reward rate for the rewards that will automatically be allocated to them as actual suppliers contributing to the network effect of the cooperative token. Thus, they will set the size of the part of the (1-RR-IH) * p reserve units of the first token that will be allocated to the operation and development of this network, and in particular they will set the size of the part dedicated to the redistribution to the actual member nodes of the group (based on their contributions to the network effect as described above) as well as to the nodes of their customers.

Chapter 9 - Amortization of Token Value Fluctuations

According to this embodiment, the system further comprises means for controllably transferring reserve count units between token nodes so as to act on the values of the token units via their respective reserves by attenuating the fluctuations of said values caused by the token units. transactions for obtaining and returning tokens (reciprocity).

According to advantageous characteristics:

the means of transfer of reserve account units are able to control the quantities of reserve units transferred according to scores established for each token.

* The score for a given token is related to the importance of the transactions made on the token in question.

* this importance of the transactions on a given token is determined from at least one of the following factors: the unit of account volume of the transactions of the given token, the number of user nodes triggering unit transactions of the token, the seniority of the transactions of the given token, the changes in the value of the token that would be obtained by application of a gross reserve rule where all reserve account units go into the reserve (in particular the Bancor formula).

* The scores are determined by iterations on sets of token nodes and increasingly large user nodes based on links between such nodes, these links can be formed by the transactions.

* a reserve transfer to token node is realized only if the score of the latter is higher than a threshold.

the quantity of reserve units transferred to a token node is determined according to the score of the latter, this score being, for example, higher as the transactions of the given token are recent. Advantageously, this system is implemented in a decentralized peer-to-peer manner by processing integrated to the token nodes.

It is recalled that an object of the invention is to allow a user to use a token issued as a "purchase order" by a given producer to buy a product not only from this producer, but even from another producer , the conversion of one token to another is done transparently. And that, as already mentioned in the preamble, in the RBT process, the simple fact of converting one token into another (via their reserves) inherently causes a variation of their values.

In this embodiment, in order to reduce or even neutralize the value variations of the tokens during certain exchanges, a token node (or several token nodes) managing a second token automatically "lend ()" reserve units to Token nodes that manage a first token, which they must return to them later - they will do so when they in turn play the role of second token node.

In this system, these loans tend to offset each other automatically - this allows executable contracts to at least offset loan balances on both sides less frequently. For this purpose, in each token node is executed an algorithm for calculating "potential reciprocity scores" of tokens with respect to the node that executes the algorithm, being noted that a token to which no score is assigned implicitly has a score. no.

The algorithm is such that tokens with a high potential reciprocity score are first of all those that in the short term are sold / bought by a large number of same users, and the algorithm expands this set of high score tokens. iteratively by applying this same criterion to tokens already having a high score until the scores become negligible, as will be seen later. These scores are updated incrementally during the purchases / sales of these tokens by their respective users (or according to given rules).

In a particular embodiment, on the basis of these potential reciprocity scores, each token node of the second token is ready, following the purchase of its token (by user nodes) and consequently upon the resulting increase of its token. value (according to the "RBT method", for example according to the Bancor formula), from reserve units to token nodes of first tokens which have high scores of potential reciprocity and whose values have fallen (during token exchanges, as already described). He thus causes a decrease in the value of his token against the increase of the value of the tokens of the nodes to which he lent the reserve units.

A loan of reserve units can be provided selectively by verifying that the score exceeds a threshold, and possibly adjusting the number of loaned reserve units according to the value of the score.

In all cases, the number of units loaned is limited by the formula (1-RR) * n (where n is the number of reserve units received during the said purchase - as described above).

In connection with Figure 3, in a particular embodiment, the potential reciprocity score calculation algorithm executed on the token node of a given token (T0):

obtain, from all of its user nodes (U0), the information of the set (T1) of the tokens that these users buy / sell (T1 including T0),

and then obtains from the nodes of the set T1 the information of the union of the sets of their own users (U 1, including U 0),

and then obtains from the nodes of the set U1 the information of the set (T2) of the tokens that these users buy / sell,

and then forms, from the information obtained from the nodes of the set T2, the union of sets of their own users (U2), ... - And so on.

For the sake of clarity, only sets TO, UO, T1 and U1 are shown in Figure 3.

As already said, the algorithm aims to assign potential reciprocity scores to the elements of said sets of tokens (Ti). The algorithm also aims to assign "tribal scores" to the user nodes (Ui), the nodes to which a score has not been assigned having implicitly a null score.

Initially, a score of 1 is assigned to the starting token TO (and all other tokens implicitly have a null score). Note that alternatively, the starting point may be not a single token, but a set of starting tokens, in which case each token in this set has an initial score of 1 divided by the number of elements of the together.

The tribal scores of each user node of each set (UO, U 1, etc.) are (re) calculated by summing the potential reciprocity scores of the tokens they used (ie, which they have purchased or sold units) of the corresponding set (TO, T1, etc.), and normalizing them, that is by dividing each score by the sum of the scores so that their total equals 1.

Thus, in the example of Figure 3:

• The two UO nodes initially have a score of 1/2 each (Figure 3a);

• Then, when the potential reciprocity scores resulting from the three nodes of T 1 are 0.25,

0.5 and 0.25 (see below), the nodes of U1 obtain respectively the scores 0.1 1, 0.33, 0.33, 0.1 1 and 0.1 1 (Figure 3d).

The potential reciprocity score of each token of each set (T1, etc.) is (re) calculated by the formula (F) of dividing

• the sum of the tribe scores of the nodes of the corresponding set (U0, U1, etc.) using this token and the (or at least one) token (s) T0

by

• the sum of the tribe scores of the nodes of the corresponding set (U0, U1, etc.) using this token or the (or at least one) token (s) T0.

Thus, in the example of FIG. 3, initially the tribal scores of the elements of U0 being of 0.5 each (FIG. 3b), the respective potential reciprocity scores of the elements of T1 are of 0.5 / 2 = 0.25, 1/2 = 0.5 and 0.5 / 2 = 0.25 (Figure 3c). Then, once the scores of the users U1 calculated, being here of 0.1 1, 0.33, 0.33, 0.1 1 and 0.1 1 (see above), then by applying the formula F (see Figure 3e):

• the first token of T1 has 2 users of which only 1 uses T0, and its score is thus of

(0.1 1 / (0.1 1 + 0.3)) / 1.51 = 0.17;

• the second token of T 1 (this is T0) has 2 users, both using T0, and its score is (0.33 + 0.33) /1.51 = 0.44;

• the third token has 3 users, only 1 of which uses T0, so its score is

(0.33 / (0.33 + 0.1 1 + 0.1 1)) / 1.51 = 0.39.

The above calculations are iterated alternately to the user nodes and then again to the token nodes, with each time expanded sets Un, Tn, until convergence, ie until at the same time the new scores obtained no longer differ significantly from the previous iteration and the new nodes added do not have significant scores (use of appropriate thresholds).

Advantageously, during these iterations, when a token has a very high score of potential reciprocity (above a given threshold) it is inserted into the starting set T0. The sets in question and the scores of the nodes of these sets are incrementally updated (when buying / selling token units by users with scores deemed sufficient) or regularly, and the "raw" score values calculated as above are weighted by the volume of transactions (number of units purchased / sold) and by weighting more recently purchased / sold tokens.

Advantageously, said weighting is performed by taking into account in the volumes only (or more strongly) the exchanges comprising purchases of token units for the purchase of products provided by the nodes of these tokens and according to the amount of these purchases. (units burned in fine, in return for reserve units given to the supplier, as already described).

Advantageously, said weighting can also be done according to the own RR of the token bought / sold in question (higher weighting for a larger RR) and / or according to rating scores or reputation scores (for example the number of "Likes" in a social network or the like).

When buying units of a given token, the node of the latter lends reserve to tokens (which are in reserve deficit) according to the scores established as above (scores tending to indicate that when they will be bought in turn, they will automatically "return" this reserve if it is itself in reserve deficit - this is the meaning of the term "potential reciprocity").

Advantageously, the long-term frequency of users' purchases / sales of tokens is also taken into account in the weightings, and purchases / sales appearing exceptional are ignored or receive less weight; other rules (or configuration parameters) regarding weighting, loan amounts, etc. can be applied in addition, so that the loans really tend to offset one another (which can be self-learning), and - in order to implement a simple P2P protocol (the token nodes determining the willingness to perform decentralized) - a token node affects scores only to tokens whose nodes apply the same rules that it (the other tokens with a null score), or (or additionally) means are implemented to adjust the score calculations (and loans) performed at each token node by coordination with the other nodes according to rules adopted and implemented jointly.

Advantageously, said loans by a given token node are endorsed at the time of purchase of tokens (of this given node) used to purchase products provided by this node and are adjusted in proportion to the amount of this purchase (see above). the embodiment in chapter 2).

Some of the loan amounts are explicitly returned in Voucher token conversions as discussed in the Chapter 2 embodiment.

Advantageously, finally, each token is additionally associated with a "Worth score" which decreases with sales and increases with the purchases of this token according to the "RBT method", and which can be determined simply from the value of the token that would be obtained by applying the "RBT process" or the Bancor formula (without the above adjustments). The "Worth scores" are memorized in association with the times at which they were calculated. Taking into account the Worth score makes it possible to adjust the attenuation obtained by means of the mechanism described in the foregoing as follows: it has been understood that, following a recent decrease in reserve of a token causing its decrease in value, other tokens lend him reserve in order to amortize this decrease (in decreasing time) as described above; but if his Worth score falls, subsequent reserve loans decline further, which will lessen the decline. This avoids over-correcting the fluctuations in the intrinsic value of the product (s) corresponding to the token or the capacity of the Producer issuing the token: Loans of reserves between token nodes only attenuate temporarily and tend to smooth out fluctuations in value.

Tribal scores can be used for different applications, being representative of the relationship between a user node and its environment (we have seen some in the previous chapters).

Variant: Adjusted prices

In this variant, the system further comprises means for simulating controlled transfers of reserve account units between token nodes so as to obtain simulated values of the token units corresponding to their respective simulated reserves, said simulated values having attenuated fluctuations. , and means for performing transactions on said simulated values.

The simulated values are for example weighted by tribal scores.

Moreover, advantageously, the means for carrying out transactions on said simulated values are able to determine price adjustments on the basis of deviations between real values and simulated values, and to compensate for all the adjustments.

More precisely, according to this variant, to further limit the drawbacks of the fluctuations, it is possible to take advantage of the executable contract at the level of the user nodes: the fluctuations in the values of the tokens are ignored by users during their exchanges of tokens for their current purchases and they are values determined "in the tribe" which are considered instead. This can be implemented as follows: token nodes do not lend reserve, but determine and memorize the value that tokens would have if they did (by simulation loans according to the process described above) - a value called "simulated price" - and their users exchange token units according to their simulated prices weighted by the respective tribal scores of these users, the price differences thus obtained offsetting each other during the exchanges.

Specifically, at each purchase or sale of units of a given token, the node of this token indicates to the user an "adjusted price" which is equal to the "normal price" of the token (according to the "RBT process" ) adjusted by applying the difference between the normal price and the simulated price weighted by the user's tribal score for this token node, with a constraint to be respected: said adjustments are compensated (with a certain margin of tolerance) during the trades.

Here again, advantageously, to avoid speculative purchases / sales, the exchanges made according to this variant are confirmed at the time of purchase of products (by paying with the purchased tokens) and, if necessary, readjusted in proportion to the amounts of these purchases. purchases (see Chapter 2 for detailed steps on payments to suppliers).

Such exchanges required during the purchases can be made transparent to the user: the purchase of a product of a tokenl node triggers, on the node of the buyer user, a process of exchange of units of tokens in order to acquire the tokenl units that are missing for this purchase: the nodes of the tokens owned by the user that are likely to be exchanged to make this purchase, declare to the user's node their "adjusted prices" according to the respective tribal scores of the latter in these token nodes; the user's node generates a combination of purchases / sales with such adjusted prices to effect the exchange so that the adjustments are offset and he has the tokenl units necessary for his purchase - for example, if the adjustment is favorable on the buy side of the token (the price of this token is currently on the rise), the adjustments on the sales side will be unfavorable to him (the prices of at least some of these tokens being on the decline). As already noted, the underlying system implementing the executable contracts guarantees the integrity of these processing by token nodes and user nodes in combination.

This variant offers the advantage of not skewing the normal prices of tokens during arbitrations taking advantage of fluctuations in the price of the token on the external markets as mentioned in the preamble (see white paper already cited). It can be seen as complementary, especially in addition to loans of reserves between token nodes to mitigate their value fluctuations (as described above), by this variant the remaining fluctuations are ignored by the users of the tribe during their exchanges tokens for their everyday purchases. Thus, advantageously, this variant is combined with the method described above, for example the loans between token nodes are made for 20% and the price adjustments according to this variant for 80%.

Variation: Other accepted tokens

Instead of considering, as in the rest of the text, that in order to acquire a product from the issuer of a given token (the supplier), the user transfers to it units of the token of this supplier, the user transfers to the supplier of units of one (or more) other token (s) having a high potential reciprocity score in relation to the supplier's token (up to the amount of the purchase in question, expressed in common reserve units).

According to this variant, the executable contract of the supplier node does not immediately liquidate the units received from said other token (so as not to lower its price). Advantageously, the nodes of the tokens with a strong potential reciprocity score with the provider cover it against the risk of a decrease in their value. The implementation of such coverage can take many forms, including Token support (see above the embodiment of Chapter 6).

Thus, in one embodiment of this variant:

* the holding period of the said other tokens (or a rule to determine the timing of their liquidation, if any) is fixed in the executable contract and

* "Token support" is issued by each token node to cover nodes with a high potential reciprocity score relative to its token (or to cover nodes where it has a high score). Insofar as these nodes purchase token support units, they are covered with respect to said decrease in value (the "triggering event" of the support is here the price decrease of said other received token, found at the time of its liquidation, and the damage due to this decrease is compensated for consumption of these units, as described in Chapter 6). Conversely, these nodes could buy token support units automatically in the event that said other received token has increased its price when they liquidate it, the increases in value of said other token thus tending to compensate for the losses of token support units caused by the depreciations of the said other tokens.

It is understood here that each provider node is thus provided by a plurality of other nodes (those of high potential reciprocity score), which allows to spread the risks in the network of token nodes described above.

Finally, it is also possible to consider the case where, instead of transferring to the supplier units of another token having a high potential reciprocity score with respect to the supplier's token, the user transfers to the supplier units of another token expressly. accepted by the latter (up to the amount of the purchase in question, expressed in common reserve units) and that the hedges of the risk of decline in value of this token are implemented on a fee-based basis (by Token or other arrangement) . Typically, the tokens expressly accepted may be those of the other suppliers from whom the supplier intends to make purchases in the near future. Said other accepted tokens may be exchanged on an "exchange market", according to the following method:

In advance, the node willing to exchange tokens must communicate what it seeks to exchange to other nodes (typically, automatically nodes having a high score of potential reciprocity), the latter forming said exchange market.

To do this, the user declares a set'Montants + 'including the information of the units of the tokens he is willing to give up and a set'Montants -' including the information of the units of the tokens he is looking for in exchange .

The counterparties required for these amounts to be exchanged are also reported. So

for each to'Montants + 'token there is a price in units of at least one reference token (at least in units of the reserve token of the node in question) and

for each token of'Montants - 'is a max acceptable cost of at least one reference token (also the reserve token at least).

The exchange market is thus a network of nodes with associated'Montants + 'and' Amounts - ', where each edge (between two nodes) is a match of Amounts of opposite signs for the same token. Thus, between two nodes there are as many edges as tokens for which there are on both sides of the'Montants + 'and''Montants -' compatible in terms of price. (The edges are stored and updated by the nodes at the ends of these edges or dynamically recalculated upon request.)

More precisely, at each edge are associated:

• the token in question;

• the exchangeable amount (capacity in the sense of the "flow networks") by matching Amounts + and -. It is the minimum of the amounts of different signs indicated on either side of the stop for this token in case the price side'Montants + 'is smaller or equal to the maximum acceptable cost side'Montants -' (expressed in units of reference tokens); and

• the units (expressed in reference tokens) to be offset for this exchangeable amount (= exchangeable amount x price on the side of 'Amount +').

To take a purely illustrative example where the prices and costs declared are relative to the same reference token, the exchange market, seen as a flow network, allows to exchange different units of tokens between a node'A 'and a node'B':

• by determining the paths for transfers maximizing the transferred units in the direction 'A' to 'B',

• as well as in the opposite direction ('B' to 'A'), and

• by transferring units of tokens for the minimum between these two senses,

these transfers resulting in the maximum possible exchange taking into account'Montants + 'and'Montants -' declared by'A 'and'B'. (In practice, the flow networks include load balancing means which are known to those skilled in the art.)

These latter variants can advantageously be combined with the previous ones at the time of the liquidation to mitigate the price variations (and the resulting media triggers).

In summary, the system according to this embodiment tends to smooth, or even neutralize, fluctuations in the value of tokens during tokens exchange transactions that are "local", the locality of a token being represented by its potential reciprocity score ("locality" relative to the token node which calculates this score). This is obtained:

• either at the level of the executable contract on the token nodes, by a transfer of reserve between token nodes (each node which generates token units, and which thus sees its value rise, transfers units from its reserve to the tokens having (vis- to him) a strong score of potential reciprocity and having fallen in value, consequently, the second go back up and the first rebaisse but tends to be compensated automatically by the second ones which do like them in turn, because of their reciprocities) ;

• or at the level of the executable contract on the user nodes - these can, according to their scores, exchange the tokens according to "adjusted" prices fixed by the executable contract on the token nodes (by simulating the prices as if the transfers reserve had occurred), these adjustments being offset;

• at the level of the executable contract on the token nodes, these ones accepting the tokens of the nodes having a high score of potential reciprocity automatically (or accept them selectively, punctually or semi-automatically), with their current value of conversion, for a given duration (agreed in the contract) and with a possible coverage by other nodes, the latter being advantageously those tokens of high scores of potential reciprocity (coverage automatically implemented automatically); the tokens thus accepted being able to be traded at any time on a local token exchange market (these different approaches can be combined).

Thus, this invention also aims to provide the tokens issued individually the advantage of complementary currencies (also called local currencies, community currencies, tribal currencies, etc.), the latter being in addition freed from the constraint of "local" "(Here understood in the geographical sense), which solves many technical problems.

Other mechanisms using the idea of this invention may be implemented by those skilled in the art, including a method for performing arbitration between the exchange market and the RBT process. The stages of such a process are essentially as follows: according to the prices of the tokens according to the RBT process, keep prices up to date on'Montants + '(essentially keep them slightly above prices according to the RBT process) and the maximum acceptable costs on'Montants - '(hold them slightly below) and, as soon as an exchange transaction is triggered on the trading market (as described above), immediately trigger reverse trades according to the RBT process.

Chapter 9bis - "neo-barter" system and barter by "pretokens"

According to this embodiment, a first provider node associated with a token node of a first type of token is a provider node vis-à-vis a first user node which is also a second provider node associated with a token node. a second type of token, further comprising means for determining the existence or perspective of existence of reverse transactions where the first provider node would be a user node at one end and the second provider node would be provider at the other end , where appropriate via other provider nodes, and, depending on characteristics of these actual or expected reverse transactions, to transfer to the first user node from the first provider node a given amount of first token units in return for a simple transfer of reserve account units corresponding to that given amount of first token units, to assign that payment to the res erve.

According to optional features:

* for the other user nodes, the units of account of first token are obtained for their real value (P); * The volume and frequency of unit account transfers for the sole reserve account units are related to the volume and frequency of transactions in the reverse transaction chain;

The system comprises means for modulating the amount of the transfer between the reserve value and the real value according to the length of the reverse transaction chain.

This embodiment aims that tokens (mainly seen here also as "vouchers") can be automatically generated and "exchanged" between "local" nodes that are suppliers of products ("local" in the sense not necessarily geographical but proximity in the network, with a connotation of reciprocity as described below) to have the advantages of a Community currency, but without having to create a community token and without presenting limitations of extensibility such as geographical level.

The idea here is that, since nodes are habitual providers of each other more or less reciprocally (directly or indirectly in the network), they can, by exchanging tokens in advance, put in place a kind of evolved barter ("neo-barter") that softens the constraint of "double coincidence of exchange desires" (https://en.wikipedia.org/wiki/Coincidence_of_wants), with the advantage that the traded tokens are generated not at the prevailing P current price (determined by the RBT, see the Bancor formula) but by adding reserve according to the RR ratio only (ie adding just enough reserve for not to vary their price), the imbalance (ie the price P times the difference between the RR ratios in the case where the RRs are different) being compensated by direct transfer of what is not put in the reserve for the one with the lowest RR.

To illustrate this advantage: for two given tokens both having a RR of 10%, the units thus generated need only add reserve for 10% of the value of the generated token, whereas normally (by taking a price P of 1 for this token as an example), a unit of the token should be generated by adding a unit of its reserve token). So here we saved 90% in necessary input.

In the case where the RRs are different, for example RR1 = 30% and RR2 = 10%, the first node provides 10% (RR2) in the reserve of the second and directly transfers 20% to the second (total contribution 30%), and the second node provides 30% (RR1) in the reserve of the first. The actual contribution is then equal to the larger of the two reserve rates, and remains lower than the price P.

Referring to Figure 5, the actual or potential reciprocity (supplies in opposite directions) of supplies between a provider node F1 and a user node U1 is determined by means of an algorithm which, on each provider node, identifies characteristics of the "usual" supply chains starting from node F1, this time as user U2, and ending at node U 1, this time as provider F2, if necessary via other nodes which are at both provider and users. The essential characteristic is the length of this chain (a short chain being an index of a reliable reciprocity), the amounts, frequencies, ... being also taken into account. In the case where there are several chains, the characteristics of the different chains are advantageously combined.

The volume and frequency of transactions in the chain can determine the volume and frequency of available tokens at the RR price.

Other characteristics (including geolocation for convenience stores) can also be taken into account. If this reciprocity is at a real or sufficient potential level, the node U1 can benefit from tokens of the node F1 by paying a "local price" corresponding to the reservation RR only of the token of the first node, price which is put in this reserve, and not the normal price P of other users.

If the characteristics of the channel or chains result in a lower reciprocity (real or potential), advantageously the system sets an intermediate local price between RR and P. This approach must of course be symmetrical at the two nodes.

The actual or potential reciprocity can be characterized by accessing a history of transactions and / or other requests for units of account under the preferential conditions as explained above, history accessible via the P2P network and memorized preferably distributed and if necessary duplicated. To do this, we implement a transaction network traversal process (consisting essentially of a graph with volume and frequency factors at its arcs) to identify in this network the reverse transaction flows, their characteristics serving to determine the intensity of the reciprocity in question. To avoid adding to the process, limit this network path (maximum number of nodes crossed, minimum volume or frequency of a link (arc), possibly with a combination of these factors-for example, the network is traversed starting from a given link even further than the volume and / or frequency according to this link is high), especially for the first search for reverse transactions.

Moreover, to facilitate this search, it is possible to memorize at the level of a node information relating not only to its links with immediately adjacent nodes, but also to the links of the immediately adjacent nodes with other nodes, and so on.

In addition, when a reverse transaction path is found, the process may look for parallel sections at portions of that path, so as to somehow thicken that path with alternative road pieces.

The system according to the "neo-barter" embodiment for acquiring purchase orders without (or with less) reserve tokens in the presence of reciprocal circuits, this embodiment is particularly well suited for deployment in an environment (a community, a local market, etc.) where there is a high density of reciprocal circuits, as there will be less need for reserve tokens for the system to operate.

For the practical implementation of this process, a person skilled in the art can also refer to the known techniques implemented in the flow networks.

The implementation of the token nodes generating the token units of account can advantageously be carried out according to chapters 2 to 6.

Variant - indirect barter circuits (pretokens)

It is possible to implement the "neo-barter" embodiment above even without statistics when tokens units (vouchers) are purchased for supply in the future. Because the time between the purchase of the token and the supply in question can detect reciprocal circuits.

So far we have focused only on a user who wants to get tokens, such as baguette tokens, rice tokens, etc., and who takes the initiative to buy them. But it will often be the other way around: each node will receive proposals such as "do you want to buy my own tokens or tokens x, y or z in exchange for my purchase of tokens of your product ? Or more generally: "Do you want to buy tokens x, y or z to form (close, complete) an indirect barter circuit? "

In fact, if an indirect barter circuit can not be formed, and if the buyer does not have enough reserve token units to pay, the transaction can not be made (by paying you will pay the price P of the Bancor formula, or at a lower price in (RR + IH) * P, ie without paying the pre-financing or paying only part of it - if reciprocal chains have been detected, as described more above).

Advantageously, each node publishes in advance the list of tokens and their amounts (the number of token units) that it is ready to accept in indirect barter circuits, and the exchanges can thus be automatically triggered, the case appropriate, to close barter circuits. These will usually be tokens of current needs (commonly purchased products such as electricity, water, rice, etc.) that will be more frequently accepted to close the circuit.

An advantageous implementation by means of "pretokens" is now described. A pretoken is relative (associated) to a particular token and does not require reserve units to be acquired. The goal is to form with units of other pretokens (acquired by other nodes) an indirect barter circuit.

To find out whether an indirect bartering circuit exists, it is expected that at the request of a user node for a given amount of units of a relative pretoken (associated) with a given token, the token node of said token generates pretoken units. and propagates in P2P the pieces of information necessary to form the desired indirect barter circuit.

When such a circuit could be generated, the pretokens are replaced by good-sellers for supply (as are the tokens, except that these vouchers can not be returned to the executable contract as they are not based on a reserve), vouchers which are themselves destroyed during the supplies (as is the case for tokens, but the supplier does not touch anything more here because no corresponding reserve existed).

On the other hand, in the case where an indirect barter circuit could not be generated after a given time interval (predefined in the executable contract, before supply), the units of the pretoken can be automatically replaced by units of the token to which the pretoken is associated, against payment (transfer to the token node of reserve tokens units) at a price depending on the detection or no reciprocal strings, as previously described. In case of impossibility of such payment, the transaction fails and the pretokens are lost.

This variant has the advantage, even for immediate or near-immediate supplies, of allowing a user who does not have spare units to obtain this supply, provided that the system is able to quickly identify the existence an indirect barter circuit.

This constitutes an additional factor for the adoption of the system by the suppliers, because even in such circumstances a supply for consideration will take place. In addition, this encourages each vendor to create its own token to benefit from indirect barter detection.

Chapter 10 - Reciprocity and Network Insurance with Automatic Reinsurance

In this embodiment, the system uses the same potential reciprocity score determination algorithm as that in Chapter 9 but on token nodes of support tokens as defined in Chapter 6, and implements reinsurance commitments in the executable contract. automatically to nodes with high scores. The automatic reinsurance commitments are set up by nodes whose potential reciprocity scores are above a certain threshold and, advantageously, the height of the automatic reinsurance commitment may be a function of the score obtained.

Thus, a reinsurance commitment is automatically provided by each support engagement provider to support engagement providers who are "neighbors" in the sense of the scores obtained for it by them.

Advantageously, the degree of neighborhood is adjusted, by learning, to better match the needs of the real world - for this we will take the concrete example detailed in chapter 6: "blocked assets" is a provision of care, and the mechanism of this invention makes it possible for a care provider who is unable to provide them (eg lack of a hospital bed) to be provided by another care provider (a neighborhood hospital) to provide the care in question. ".

As already described in Chapter 6, the executable contract of a node that is the beneficiary of a reinsurance commitment (here it is an automatic reinsurance commitment) may, when exceeding its own blocked assets , directly draw on the blocked assets of the supplier of this commitment (hereinafter referred to as the "automatic reinsurance node"),

But, advantageously, the executable contract can also draw on the assets of another automatic reinsurance node according to its "need for substitution", that is to say which offers more directly the provision specifically sought (for example hospital care in France). general, hospital care of a certain type, etc.).

Thus, (using the same example) the present invention aims that in case of exceeding the blocked assets (You care units), the executable contract selects, among the neighboring nodes, sorted by decreasing potential reciprocity scores , the first one that has specifically matching reserve token units (hospital care units, To3- possibly units of some type of care) available in their blocked assets.

Advantageously, the reinsurers' choices by the beneficiary nodes are taken into account by the algorithm for determining the potential reciprocity scores, by learning, so as to progressively propose automatic reinsurance nodes that will be accepted directly.

In one embodiment, a "weight of specificity" (or several different weights, for different types of need for substitution, insofar as they are captured in a semiautomatic implementation) is (are) associated (s) at each automatic reinsurer node and incremented at each selection, and the potential reciprocity scores are weighted by means of the specificity weight (s) of the automatic insurer nodes to which they are associated (the different weights of specificity allowing refine the selection according to the type of specific need for current substitution).

Chapter 11 - Interactions with other input data

The system described in the foregoing, through the executable contracts, can interact with different input data received or captured by the system nodes.

In particular, the system may include "certifying" or "certifying" nodes comprising physical means (sensors, actuators, etc.) making it possible, for example, to certify that a product of a vendor owning a supplier node has, for example, been provided to a user who owns a node user. This attorney node may for example be owned by a delivery organization, or integrated into a mailbox detecting, for example by NFC technology, the actual deposit of the product in the box.

Alternatively, this functionality can be integrated into the executable contract of the user node.

In another embodiment, the data received may be location data (GPS or other), possibly secured by an envelope protection device as described in application PCT / IB2018 / 059003 filed November 15, 2018 at name of the applicant, the content of which is incorporated in the present description by reference, or by known mechanisms of "Proof of Location" exploiting the blockchain, see for example hMps; // dpcs.xyo, netwprk / XYO-VVhite-Paper pdf.

This GPS data can for example be combined with time data.

These GPS data may be confronted with the coordinates of one or more geographical areas in which (or for access to which) it is necessary or desirable to hold a certain token, where appropriate a minimum number of units of this token.

One can associate with this geographical verification a loading constraint in the considered node (typically a user node) of a certain executable contract making it possible to trigger the obtaining of this token.

For example, in the case of a motorway toll for a fixed-term national ski pass of a certain period of validity (eg Switzerland), the following operations, carried out in a smartphone with means of secure execution of executable contracts, may be provided:

• upon arrival in the country, detection of the change of cellular network

• in response to this detection, manually or automatically, loading an executable contract to obtain "motorway toll" token units

• execution of the executable contract to obtain by reserve reserve units of account X units of this token, which is assigned an expiry date,

Implementation by the executable contract, automatically or on demand, of an exit interface, typically visual on screen, proving in particular vis-à-vis the authorities holding the X token units.

A first advantage of the invention is to regulate the cost of the toll, either by leaving invariable, or by controlling the cost variations by varying the factor IH (and thus regulate the motorway traffic). A second advantage is that it makes possible the return of unused tokens (in this case a fraction of the X token units depending on the length of stay), or their exchange with other tokens.

Chapter 12 - Restitution of Tokens and Debt Management

In this embodiment, it is expected that the executable contract executed in a token node is capable, prior to a return of token units to the given token node, to check the availability of spare account units that were transferred to the node. provider when obtaining these token units and, based on this check, to perform the refund to the extent of available spare account units, and is also able to assign to the provider node a remaining debt attribute of reserve account units in the event of at least partial unavailability.

Optionally: * the executable contract is able, in a subsequent transaction involving a transfer of reserve account units to a provider node with such a remaining debt attribute, to transfer all or part of the reserve account units to be transferred for that purpose. subsequent transaction to the user node at the origin of said restitution, to at least partially complete the latter;

the system comprises means for associating the remaining debt attributes of the provider nodes with other attributes of these nodes, thereby dissociating these attributes from the key pairs of said nodes.

The registration of the debts vis-à-vis the various user nodes is advantageously performed by the executable contract executed in the token node in question.

In this way the system ensures that a debt born during an incomplete refund operation ends, as other users buy the same token, to be refunded to the creditor user.

Moreover, to avoid that debts are simply erased from the system during the failure or the disappearance of the token node considered (which is recalled that it can be confused with the associated supplier node), it is expected that the user nodes, typically a set of user nodes that have high tribe scores compared to the creditor user nodes, store the debt data not (or not only) in association with the key pair of the token node / provider considered, but (or additionally) in association with attributes that permanently characterize the provider.

In this way, when a provider reconstructs a token / provider node following a failure / disappearance, a recovery mechanism, managed by the executable contract, is implemented as soon as a link with the users is established. This mechanism advantageously comprises an automatic notification to all the user nodes, during the establishment of the new token / provider node, its public key and key attributes to find these attributes.

Depending on the nature of the provider, these attributes may be of a variable nature (for example, coordinates for a local business).

Of course, the inventions described above are not limited to the described embodiments, but the person skilled in the art will be able to make many variations and modifications, as well as any combination between the characteristics of the different inventions that can be made. he will apprehend as being technically compatible.

In particular, in particular the calculation of the quantity of reserve units that go into the proper reserve of a token node, we can substitute the formula RR * n or (RR + IH) * n, which is a function affine, other functions that are affine or not. In particular, it is possible to implement a non-linear function (in stages, or continuous), which contributes to a stabilization of the value of the token.

Claims

claims

A transactional networked system comprising a set of token nodes (TNs), a set of user nodes (UNs) and a set of provider nodes (PNs), the nodes being capable of executing an executable contract allowing a user node to obtain units of Tokens account (Voucher tokens) by setting reserve reserve units (R) according to a value of the token units which itself varies according to the reserve, the number of token units in circulation and the reserve ratio (RR), each token node being associated with a provider node and the token being representative of a product or asset (good, service, right or other advantage) of the provider, or a group of such products or assets, the system being capable, when a user node makes available spare account units necessary to obtain token units from a given token node at the current value, transfer a first part of these reserve account units to the reserve of said given token node, and to transfer a second part of these reserve account units out of said reserve, and to perform the reverse transfers during a restitution of units. from a token to the given token node, so as to limit or neutralize the value variations of the token unit during the obtaining and rendering of these token units.

2. System according to claim 1, and the system being able, during the supply of a good or service type product by the supplier, to delete the corresponding token units by transferring to the supply node the first part of the units of reserve account and, if not already transferred, the second part of the reserve units.

3. System according to claim 2, also comprising product delivery attestation nodes able to communicate with the token nodes to selectively remove all or part of the token units and transfer to the supplier node all or part of the first part of the token nodes. reserve account units and, if not already transferred, the second part of the reserve units, according to a certified or certified supply status of the product corresponding to a user.

4. System according to claim 3, wherein the delivery certificate node and the user node of the user concerned form a single node.

5. System according to one of claims 1 to 4, also comprising, at a user node, means adapted, in response to geographical location information, to cause obtaining units of a certain token associated with this location.

6. System according to claim 5, which comprises means for loading in the user node in question an executable contract allowing this obtaining.

7. System according to claim 5 or 6, wherein said units of the certain token are associated with temporal data, such as a period of validity.

8. System according to claim 5 to 7, wherein the fraction of units of account defining said first part is variable, of matter to vary the price of the certain token associated with the location, in particular for regulatory purposes.

9. The system of claim 1, wherein the product is constituted by a right to use the given token as a reserve account unit for token nodes of other tokens.

10. System according to one of claims 1 to 9, wherein said second part of the reserve account units is transferred at least in part to the supplier node.

The system of claim 10, wherein the executable contract executed in a token node is able, prior to a return of token units to the given token node, to check the availability of the spare account units that had been transferred. to the provider node when obtaining these token units and, based on this check, to perform the restitution to the extent of available spare account units, and is also able to assign to the provider node a remaining debt attribute reserve account units in the event of at least partial unavailability.

12. The system of claim 1 1, wherein the executable contract is suitable, in a subsequent transaction providing for a transfer of reserve account units to a supplier node having such a remaining debt attribute, to transfer all or part of reserve account units to be transferred for this subsequent transaction to the user node at the origin of said restitution, to at least partially complete the latter.

13. System according to one of claims 1 1 and 12, which comprises means for associating the remaining debt attributes of the provider nodes to other attributes of these nodes, thus dissociating these attributes of the key pairs of said nodes.

The system of claim 1 to 13, wherein said second portion of the reserve account units is transferred at least in part to an escrow account.

The system of claim 14, wherein the escrow account is managed within the given token node.

16. System according to one of claims 1 to 15, wherein the number of reserve account units of the first part is chosen to neutralize the changes in value of the token units during accessions and restitutions thereof.

17. System according to claim 16, wherein the token node is able to compare the number of token units obtained by the user nodes with a variable availability threshold and, if this threshold is exceeded, to modify the assignment. new reserve account units made available between the first and second parts.

The system of claim 17, wherein the modified assignment has a second portion with zero spare count units.

19. The system of claim 18, wherein the given token node is able to mark the token units generated beyond said threshold to form an availability waiting list, and transform this marking into a marking " Voucher "as the said threshold increases.

The system of claim 19, wherein the availability threshold is determined from an amount of assets associated with the provider node and a given asset blocking ratio.

21. System according to one of claims 17 to 20, wherein the availability threshold is determined by an executable contract at the provider node or the token node, responsive to information provided by asset blocking sensor means.

22. System according to one of claims 17 to 21, which comprises means for modifying the value of the availability threshold and / or the conversion value Voucher tokens assets in response to a decrease (generally out of control) of the number of assets from which the initial availability threshold was established.

23. System according to one of claims 1 to 22, wherein the supplier is able to provide fixed quantities of product constituting a reference good (such as gold metal), these fixed quantities of the reference good thus playing. the role of real money.

24. The system of claim 19, which comprises priority management means in the waiting list.

25. The system of claim 24, wherein the priority management means are able to take into consideration micropayments made with the token considered by different users with tokens waiting list.

26. The system of claim 20, which further comprises at the level of a provider node or token node secure means for certifying blocking or asset generation (typically sensor means managed by an executable contract), cooperating with the means to generate or modify the availability threshold for the asset in question.

27. System according to one of claims 1 to 26, wherein the first part of the reserve account units is constituted by a first sub-part whose number is such that they neutralize the changes in value of the token units during the accessions and restitutions thereof and a second sub-part whose number is such that they generate a controlled variation in the value of the token unit, with an increase on obtaining and a decrease on the return.

The system of claim 27, wherein the number of spare count units of the second subpart is determined based on a variable parameter (IH) associated with the token and managed by its token node.

The system of claim 28, wherein the parameter is a function of time data relating to the supply request and the supply offer at the provider node.

30. The system of claim 28 or 29, wherein the parameter is a function of a density and / or a distribution of possible supply instants in one or more time slots where the supply is requested.

The system of claim 28, 29 or 30, wherein the parameter is a function of population data of different user nodes that have obtained tu tu tu associated units.

32. The system of claim 31, wherein the population data of user nodes are weighted by coherence data, between these nodes, vis-à-vis token units of other types they obtained (compliance ).

33. System according to one of claims 28 to 32, wherein the parameter is a function of product delivery reliability data corresponding to the considered token.

34. System according to one of claims 28 to 33, wherein the parameter is a function of at least two of the data.

35. System according to one of claims 28 to 34, wherein a token node is adapted, in case of variation of said parameter, to redistribute the allocation of reserve account units to its first part and its second part by transferring 'outside the reserve to the reserve or vice versa.

The system of claim 27, further comprising means for automatically causing tokens unit accesses at a given token node in response to a reported variation of the underlying asset to that token unit, such as adjusting the value of the token unit to the value of the underlying asset that has changed.

The system of claim 36, wherein the variation is signaled by detecting a change in amount of a physical asset constituting the underlying asset.

38. System according to claim 37, comprises secure means (such as sensor means managed by an executable contract) for detecting said variation.

The system of claim 36, wherein the variation is signaled by detecting the change in value of an intangible asset constituting the underlying asset.

40. The system of claim 39, comprises secure communication means, managed by an executable contract, with a data source capable of providing the value of the intangible asset.

41. The system of claim 27, wherein the token units for a given token node are adapted to be converted into supplies of products or reserve units previously locked in blocked assets, and further comprising means for determining a number of units of tokens to obtain to obtain a given quantity of products or reserve units previously blocked according to data of probabilities of events triggering such a supply, at least a part of the units of account of reserve that allowed to get tokens units being transferred to the product supply node and / or to the blocked assets.

42. The system of claim 1, further comprising means responsive, in response to the occurrence of a trigger event, to convert token units of a given token into a supply of products or reserve account units. previously blocked in blocked assets, and means for determining a number of token units to be obtained for obtaining a given quantity of previously blocked pooled revenue or reserve account units based on event trigger probability data of such a supply, at least a portion of the reserve account units that have acquired the token units being transferred to the supplier supplier node of the products and / or to the blocked assets.

43. The system of claim 42, wherein said number of token units to be acquired varies according to a probability of occurrence of a triggering event according to an increasing law.

The system of claim 42 or 43, wherein the transfer of the reserve account units to the product provider node constitutes a down payment, the balance of reserve account units being transferred to the provider from the reserve (R). ) when supplying the product to a triggering event.

45. The system of claim 42 or 43, wherein the transfer of the reserve account units to the blocked reserve account unit node participates in the generation of the blocked assets, the reserve account unit complement being transferred to the user node from the pool (R) when releasing the trigger event assets.

46. System according to one of claims 42 to 45, wherein said probability data are established based on existing statistical data related to the triggering events.

47. System according to one of claims 42 to 46, wherein said probability data are adjusted by statistical learning.

48. System according to claim 1, in which the tokens of at least one token node are token supports that can be converted into support supplies at the occurrence of triggering events, the system comprising means for managing the payload units. reserve account apt, when obtaining additional tokens support with respect to a starting situation:

- to allocate these blocked reserve account units to the different tokens support holders (user nodes that are beneficiaries of the support commitment) according to the occurrence of the triggering events.

The system of claim 1 further comprising means for transferring units of account from a given token in response to an increase in utility or use of a token node network having token given as a reserve unit, to the reserve of token nodes contributing to this increase.

The system of claim 49, wherein the increase in utility or network utilization is determined by at least one of the following factors:

- the actual purchase of the good or service,

- increasing the threshold of availability of the specific token in Voucher token.

51. The system of claim 1, further comprising means for generating at least some token nodes offers and requests for tokens of other types, and means for managing a token exchange market based on offers and requests and the configuration of the network so as to optimize the exchange transactions.

The system of claim 1, further comprising means for controllably transferring reserve count units between token nodes so as to act on the values of the token units through their respective pools by attenuating the fluctuations of said values caused by the token units. transactions for obtaining and returning tokens (reciprocity).

53. The system of claim 52, wherein the means of transfer of reserve account units are able to control the amount of reserve units transferred according to scores established for each token.

54. The system of claim 53, wherein the score for a given token is related to a significance of the transactions performed on the token in question.

55. The system of claim 54, wherein the importance of the transactions on a given token is determined from at least one of the following factors: the transaction account unit volume of the given token, the number of nodes users initiating token unit transactions, the seniority of given token transactions, changes in token value that would be obtained by applying a gross reserve rule where all reserve account units go to the reserve (including Bancor formula).

The system of claim 55, wherein the scores are iteratively determined on sets of token nodes and larger and larger user nodes based on links between such nodes.

57. The system of claim 56, wherein the links are transactions.

58. System according to one of claims 53 to 57, wherein a reserve transfer to token node is performed only if the score of the latter is greater than a threshold.

59. System according to one of claims 53 to 58, wherein the amount of reserve units transferred to a token node is determined according to the score of the latter.

60. System according to one of claims 55 to 59, wherein a score is even higher than the transactions of the given token are recent.

61. System according to one of claims 52 to 60, which is implemented in a decentralized peer-to-peer manner by integrated processing token nodes.

The system of claim 1, further comprising means for simulating controlled transfers of reserve count units between token nodes so as to obtain simulated values of the token units corresponding to their respective simulated pool, said simulated values having attenuated fluctuations, and means for carrying out transactions on said simulated values.

The system of claim 62, wherein the simulated values are weighted by tribal scores.

64. A system according to claim 62 or 63, wherein the means for carrying out transactions on said simulated values are able to determine price adjustments on the basis of differences between real values and simulated values, and to compensate for all adjustments.

The system of claim 1, wherein a first provider node associated with a token node of a first type of token is a provider node vis-à-vis a first user node which is also a second provider node associated with a token node of a second type of token, further comprising means for determining the existence or perspective of existence of reverse transactions where the first provider node would be a user node at one end and the second provider node would be provider at the other end, if necessary via other provider nodes, and, depending on the characteristics of these actual or expected reverse transactions, to transfer to the first user node from the first provider node, a given amount of first units token in exchange for a simple transfer of reserve account units corresponding to this given quantity of first token units, to affect this pa to the reserve.

66. The system of claim 65, wherein, for the other user nodes, the first token units of account are obtained for their real value (P).

67. The system of claim 65 or 66, wherein the volume and frequency of the unit account transfers for the sole reserve account units are related to the volume and frequency of transactions in the reverse transaction chain.

68. System according to one of claims 65 to 67, which comprises means for modulating the amount of the transfer between the reserve value and the actual value as a function of the length of the reverse transactions chain.

The system according to one of claims 65 to 68, wherein determining the existence or perspective of existence of reverse transactions where the first provider node would be a user node at one end and the second provider node would be provider at the other end, if necessary via other provider nodes, is implemented with "pretoken" type tokens that do not require reserve account units to be set aside.

70. The system of claim 69, which includes means for requesting obtaining tokens by setting reserve account units when no reverse transaction chain expected with pretokens is detected.

71. System according to one of claims 1 to 70, wherein a token node and an associated supplier node are constituted by a single node.

72. A method comprising any succession of steps for the implementation of a system according to one of claims 1 to 71.