ERC-20 standard extension procedure for granting pre-authorizations

Abstract

The invention proposes a method for extending the ERC-20 standard by implementing a smart contract, characterized in that it consists of implementing the smart contract (2) such that it includes at least: - a _preauths mapping which, to a first address, associates the addresses to which the first address has granted pre-authorization, as well as its amount, and - in at least one function transferring a value V from a debtor F to a beneficiary T, a query of the _preauths mapping to verify the existence of a pre-authorization granted by the debtor F to the beneficiary T for an amount greater than or equal to the value V. The invention also relates to methods for carrying out transactions on the blockchain. Figure 2

Description

Title of the invention: Method for extending the ERC-20 standard to grant pre-authorizations technical field

[0001] The present invention relates to the technical field of cryptocurrency transaction methods, and in particular to the field of transaction management according to the 8583-20022 standards, for currencies exchanged on the Ethereum blockchain. Prior art

[0002] The specialist's general knowledge includes in particular the ISO 8583 standards - ATM transactions - and 20022 - SEPA transfers - which govern payments in fiat currency, the Ethereum blockchain documentation available at this address: https: / / ethereum.org / en / developers / docs / transactions / , and the Ethereum ERC-20 standard, the documentation for which is available at this address: https: / / eips.ethereum.org / EIPS / eip-20.

[0003] In the cryptocurrency ecosystem, the only possible payment method is the instant transfer of currency from actor A to actor B, initiated by A. Each actor has at least one address. This address identifies them and serves as the identifier for a fund transfer. A person, whether natural or legal, may have several addresses if they so wish.

[0004] Some blockchains, such as Ethereum, also allow the deployment of "smart contracts." These are entities whose behavior is governed by computer code, which may include functions with predefined behavior. Users can activate these functions through specific transactions to the contracts. This is referred to as function exposure, in the sense that the smart contract is seen as an actor within the blockchain, capable of responding to requests received from other actors.

[0005] Within the Ethereum ecosystem, there are "ERC-20 Currencies." These currencies are governed by a Smart Contract conforming to the Ethereum ERC-20 standard. For each currency, a smart contract serves as the currency's general ledger: it stores a mapping of all Ethereum addresses holding that currency and the amount held. It also exposes functions allowing user A to transfer an amount X to user B and allowing user A to authorize user B to withdraw a maximum amount X from A's account.

[0006] In conventional cash payments, a merchant can perform a pre-authorization, whereby, through its acquirer, it requests a customer's bank to block an amount X for a certain period, in order to then be able to debit up to X, ensuring that the customer has sufficient funds to pay. This feature is notably used for card payments for fuel, rentals, and hotel reservations.

[0007] The invention aims, in particular, to implement existing fiat currency transactions, such as those defined in ISO 8583 and 20022 standards, within the cryptocurrency ecosystem. Another aim is to implement pre-authorizations for SEPA bank transfers or instant transfers.

[0008] One problem with the cryptocurrency ecosystem is that it lacks ISO 8583-20022 transaction standards for cryptocurrency payments. Merchants needing this type of transaction cannot accept customers who hold cryptocurrencies. Conversely, merchants who only accept customers who can pay them with cryptocurrencies cannot benefit from mechanisms that guarantee they will be paid. Summary of the invention

[0009] An object of the invention is a method for extending the ERC-20 standard, by implementing a smart contract, characterized in that it consists of implementing the smart contract in such a way that it includes at least: - a _preauths mapping which, to a first address, associates the addresses to which the first address has granted pre-authorization, as well as its amount and - in at least one function transferring a value V from a debtor F to a beneficiary T, a consultation of the mapping _preauths to check for the existence of a pre-authorization granted by the debtor F to the beneficiary T for an amount greater than or equal to the value V.

[0010] One advantage of the invention is that it enables ISO 8583-20022 transactions in an open-source and decentralized environment, rather than relying on a closed system controlled by a few actors. Another advantage is that it allows funds to be reserved without making a transfer, and therefore saves transaction fees.

[0011] The invention also allows: - flexibility in the transaction amount, - the ability to initiate a cryptocurrency transfer with the option to modify the amount. - to perform a pre-authorization in the Ethereum ecosystem if the customer only has this means of payment or in the event of a technical failure of an actor such as the customer's bank.

[0012] The contract inherits the rest of the functions defined in ERC-20.

[0013] According to a particular embodiment of the method, the latter implements the smart contract in such a way that it includes a preAuthorize function, using variables M [for Merchant] and A [for Amount], which checks that the function caller has at least A of the available currency, i.e., that it currently has more than the sum of A and all existing pre-authorizations; if so, the preAuthorize function grants the merchant M a pre-authorization of amount A on the caller by storing it in the _preauths mapping.

[0014] According to a particular embodiment of the method, the latter implements the smart contract so that it includes a collect function, using variables F [for from, or debtor in French], T [for to, or beneficiary in French] and V [for value, value in French], which consults the _preauth mapping and checks that F has granted a pre-authorization to T for an amount greater than or equal to V; if so, the collect function clears the pre-authorization from the _preauths mapping and transfers the value V from the debtor F to the beneficiary T; otherwise, the function returns an error.

[0015] According to a particular embodiment of the method, the latter implements the smart contract so that it includes a transfer function, using variables T [for To, or beneficiary in French] and V [for value, or value in French], which consults the mapping _preauths and checks that the caller of the function currently has more than the sum of V and all the pre-authorizations granted on it; if so, the transfer function transfers the value V to the beneficiary T; otherwise, the function returns an error.

[0016] According to a particular embodiment of the method, the latter implements the smart contract so that it includes a function transferFrom, using variables F [for from, or debtor in French], T [for To, or beneficiary in French], and V [for value, or value in French], which consults the mapping _preauths and checks that F currently has more than the sum of V and all the pre-authorizations granted on it; if so, the function transferFrom transfers the value V from the debtor F to the beneficiary T; otherwise, the function returns an error.

[0017] According to these two embodiments, the transfer function and the transferfrom function are modified compared to the transfer and transferfrom functions defined in ERC-20.

[0018] According to a particular embodiment of the process, the mapping includes a maximum delay and: - the preAuthorize function, if it exists, also stores the date on which this pre-authorization was granted in _preauth, - the collect function, if it exists, checks that the pre-authorizations granted by F have not expired, that is to say that the creation date is not further from the current date than the maximum period set in the contract, - The transfer function, if it exists, checks if the pre-authorizations granted by F have not expired. - the transferFrom function, if it exists, checks that the pre-authorizations granted by F have not expired.

[0019] This maximum period is used to ensure that pre-authorizations older than this period are deleted so that an account is not blocked by uncollected pre-authorizations.

[0020] In application of the implementation described above, the invention also relates to a computer-implemented method for carrying out a transaction of a given amount in two steps using the blockchain between a first address and a second address, comprising the following steps:

[0021] . initially: - Consult a _preauths mapping to retrieve all still-valid pre-authorizations already granted by the first address, sum the values ​​of these potentially still-valid pre-authorizations, add the given amount, then compare this result to the number of tokens held by the first address. - If the check shows that the first address has enough tokens, create a record in the _preauths mapping to add the pre-authorization of the given amount in favor of the second address; otherwise, refuse the transfer.

[0022] . in a second step: - consult the _preauths mapping and verify that there is a pre-authorization granted to the second address by the first address, and that the amount of this pre-authorization is greater than or equal to the given amount, if so, remove the pre-authorization and transfer the tokens for the value V from the first address to the second address, otherwise, refuse the transfer.

[0023] The invention also relates to a computer-implemented method for transferring a given amount in a single transaction from a first address to a second address using the blockchain, comprising the following steps: - consult a _preauths mapping to retrieve all the still valid pre-authorizations already granted by the first address, sum the values ​​of these potentially still valid pre-authorizations, add the given amount, then compare this result to the number of tokens held by the first address, - if the check shows that the first address has enough tokens, transfer the given amount from the first address to the second address, otherwise, refuse the transfer.

[0024] These two processes can receive the variants described above for the implementation of the smart contract, in particular the maximum time allowing the erasure of pre-authorizations that are too old.

[0025] The invention also relates to a computer-implemented method for transferring a given amount from a first address to a second address, consisting of selecting, and then implementing, the process for carrying out a two-step transaction or the process for transferring an amount in one go, as described above. Brief description of the figures

[0026] The invention will be better understood upon reading the following description, given solely by way of example and made with reference to the accompanying drawings in which:

[0027] Figure 1 is a diagram illustrating the operations carried out on the Ethereum blockchain between a user, a contract according to the invention, and a merchant.

[0028] [Fig.2] is a diagram similar to that of [Fig.1] illustrating other operations. Detailed description

[0029] The sequence of operations diagram in [Fig.1] shows a user 1, a contract 2 implemented according to the invention and a merchant 3.

[0030] This example assumes the existence of a _preauths mapping in the blockchain. This mapping is not shown in the diagrams but corresponds to a concept well known to specialists.

[0031] User 1 wants to grant pre-authorization to merchant 3 M for an amount A. He calls the preAuthorize(M, A) function of contract 2, as illustrated by the preAuthorize arrow 4.

[0032] During the execution of the called function, contract 2 performs the operations represented by the preAuthorize block. It checks that user 1 has enough tokens to cover the amount A. This check consists of consulting the _preauths mapping to retrieve all the still-valid pre-authorizations already granted by user 1, summing the values ​​of these potentially still-valid pre-authorizations, adding the amount A of the pre-authorization to be granted, and then comparing this result to the number of tokens held by user 1. If the check shows that user 1 has at least enough tokens, the function creates a record in the _preauths mapping to add the pre-authorization of an amount A in favor of merchant 3M, and then returns a success notice 5. Otherwise, the function returns an error and the pre-authorization is not granted.

[0033] Later, when merchant 3 wants to collect a sum V on the basis of the pre-authorization granted to him, he activates the collect function of contract 2, as illustrated by the collect arrow 6. This function consults the _preauths mapping and checks that there is a pre-authorization granted to merchant 3 M by user 1, and that the amount A of this pre-authorization is greater than or equal to the sum V.

[0034] If so, contract 2 removes the pre-authorization and transfers the tokens for the value V.

[0035] If, before merchant 3 calls the collect function, the customer attempts to transfer all the money they have to another address, the transfer will fail because the transfer function fails if a transfer would leave less than the value M—or even the sum of M and any other still-valid pre-authorizations stored in the _preauths mapping—on the address of the customer who called preAuthorize. Merchant 3 is therefore guaranteed that the customer will be able to pay them up to the value M, as illustrated by the transfer arrow 7.

[0036] A sequence diagram illustrating this guarantee mechanism is shown in [Fig.2],

[0037] User 1 wants to grant a pre-authorization to the merchant 3 for an amount A. The first steps illustrated by the preAuthorize arrow 4 and the success notice 5 are identical to those already described with reference to [Fig.1].

[0038] When user 1 attempts to transfer their funds to another address, they use the `transfer` function of contract 2, as illustrated by the `transfer_attempt` arrow 8. Contract 2 then checks that user 1 has enough tokens available by also consulting the `_preauths` mapping. By definition, if user 1 wants to transfer everything, the amount checked exceeds the amount held plus the pre-authorization already given. Consequently, the transfer fails, and contract 2 returns an `insufficientFunds` error 9.

[0039] Next, when merchant 3 wants to be paid the exact amount, it calls the `collect` function of contract 2, as illustrated by the `collect` arrow 6. This function checks for the existence of a pre-authorization for an amount A that is greater than the exact amount. The contract then removes the pre-authorization from the `_preauths` mapping and transfers the tokens, as illustrated by the `transfer` arrow 7.

[0040] In addition to all the functions described above, time management can be added. In this case, each pre-authorization recorded in the _preauths mapping is associated with an expiration time. This time can be a date, or a combination of a start date and a lifetime.

[0041] In this case, at each check relating to pre-authorizations existing in the mapping _preauths, contract 2 only takes into account pre-authorizations which have not exceeded their expiry time.

[0042] The invention is not limited to the embodiments shown and other embodiments will be obvious to a person skilled in the art.

[0043] List of references 1: User 2: Contract 3: Merchant 4: PreAuthorize arrow 5: Success Report 6: Collective arrow 7: Transfer arrow 8: Transfer_attempt arrow 9: InsufficientFunds error

Claims

Demands

1. A method for extending the ERC-20 standard, by implementing a smart contract (2), characterized in that it consists of implementing the smart contract (2) in such a way that it includes at least: - a _preauths mapping which, to a first address (1), associates the addresses to which the first address has granted a pre-authorization, as well as its amount and - in at least one function transferring a value V from a debtor F to a beneficiary T, a consultation of the _preauths mapping to verify the existence of a pre-authorization granted by the debtor F (1) to the beneficiary T (3) for an amount greater than or equal to the value V.

2. A method according to claim 1, wherein the latter implements the smart contract (2) so that it includes a preAuthorize function, using variables M [for Merchant] (3) and A [for Amount], which verifies that the caller (1) of the function has at least the quantity A of the available currency, i.e., that it currently has more than the sum of A and all existing preauthorizations; if so, the preAuthorize function grants M (3) a preauthorization of amount A on the caller (1) by storing it in the mapping _preauths.

3. A method according to any one of claims 1 and 2, wherein the latter implements the smart contract (2) so that it includes a collect function, using variables F [for from] (1), T [for to] (3) and V [for value], which consults the _preauth mapping and checks whether F (1) has granted a pre-authorization to T (3) for an amount greater than or equal to V; if so, the collect function clears the pre-authorization from the _preauths mapping and transfers the value V from F to T; otherwise, the function returns an error.

4. A method according to any one of claims 1, 2 and 3, wherein the latter implements the smart contract (2) so that it includes a transfer function, using variables T (3) [for To] and V [for value], which consults the mapping _preauths and checks whether the caller of the function currently has more than the sum of V and all pre-authorizations granted on it; if so, the transfer function transfers the value V to T; otherwise, the function returns an error.

5. A method according to any one of claims 1, 2, 3 and 4, wherein the latter implements the smart contract (2) so that it includes a function transferFrom, using variables F [for from], T [for To], and V [for value], which consults the mapping _preauths and checks that F currently has more than the sum of V and all pre-authorizations granted on it; if so, the function transferFrom transfers the value V from F to T; otherwise, the function returns an error.

6. A method according to any one of claims 1, 2, 3, 4 and 5, wherein the mapping includes a maximum time limit and: - the preAuthorize function, if it exists, also stores the date on which this pre-authorization was granted in _preauth, - the collect function, if it exists, checks that the pre-authorizations granted by F have not expired, i.e. that the creation date is not further from the current date than the maximum time limit set in the contract (2), - the transfer function, if it exists, checks that the pre-authorizations granted by F have not expired, - the transferFrom function, if it exists, checks that the pre-authorizations granted by F have not expired.

7. A computer-implemented method for carrying out a two-step transaction of a given amount using the blockchain between a first address (1) and a second address (3), comprising the following steps: . firstly: - consult a _preauths mapping to retrieve all still valid pre-authorizations already granted by the first address, sum the values ​​of these potentially still valid pre-authorizations, add the given amount, then compare this result to the number of tokens held by the first address, - if the verification shows that the first address has enough tokens, create a record in the _preauths mapping to add the pre-authorization of the given amount in favor of the second address, otherwise, refuse the transfer, .secondly: - consult the _preauths mapping and verify that there is a pre-authorization granted to the second address by the first address, and that the amount of this pre-authorization is greater than or equal to the. given amount, if yes, remove the pre-authorization and transfer the tokens for the value V from the first address to the second address, otherwise, refuse the transfer.

8. A computer-implemented method for transferring a given amount in one go from a first address (1) to a second address (3) using the blockchain, comprising the following steps: - consult a _preauths mapping to retrieve all the still valid preauthorizations already granted by the first address (1), sum the values ​​of these possible still valid preauthorizations, add the given amount, then compare this result to the number of tokens held by the first address, - if the verification shows that the first address has enough tokens, transfer the given amount from the first address (1) to the second address (3), otherwise, refuse the transfer.

9. A computer-implemented method for transferring a given amount from a first address (1) to a second address (3), consisting of selecting and then implementing the method according to claim 7 or the method according to claim 8.

Images