Method for extending the ERC-20 standard to grant pre-authorizations

Abstract

The invention proposes a method for extending the ERC-20 standard by implementing a smart contract, characterized in that it consists in implementing the smart contract (2) in such a way that it comprises at least: - a mapping _preauths that associates, with a first address, the addresses to which the first address has granted a pre-authorization, along with the amount thereof and - in at least one function that transfers a value V from a debtor F to a beneficiary T, consulting 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. The invention also relates to methods for carrying out blockchain transactions.

Description

ERC-20 standard extension procedure for granting pre-authorizations

[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. State of the art

[0002] The specialist's general knowledge includes, in particular, ISO standards 8583 – ATM transactions – and 20022 – SEPA transfers – which govern fiat currency payments, 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. The ERC-20 standard has been stable and finalized since its creation in 2015.

[0003] In the cryptocurrency ecosystem, the only possible payment method is the instant transfer of funds 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. An individual or legal entity can have multiple addresses if they 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 directed to the contracts. This is referred to as function exposure, in the sense that the smart contract is viewed 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 adhering 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 traditional cash payments, a merchant can perform a pre-authorization, whereby, through their acquirer, they request a customer's bank to block a certain amount (X) for a specific period, allowing them to subsequently debit up to X, confident that the customer has sufficient funds. This feature is commonly 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 objective is to implement pre-authorizations for SEPA bank transfers or instant transfers.

[0008] Additions and extensions have been made to the ERC-20 standard, but none allow for the use of pre-authorizations. Therefore, users must resort to workarounds to secure transactions. For example, they can use an escrow contract, which is an intermediary contract designed to receive funds in advance and release them under certain conditions (delivery, date, etc.), a method well-suited to smart contract management. Another known solution is to use an online marketplace and implement deferred payments. Finally, token locking can be used to ensure that tokens are not spent elsewhere. This is the solution disclosed in US2023095679.

[0009] In summary, none of these solutions guarantees a payer's solvency in a simple and cost-effective way. The ERC-20 standard alone is insufficient to guarantee future payment. This shortcoming has been tolerated since 2015 because adding logic to a smart contract (escrow, conditions, marketplace, locking) is standard practice for a specialist in the field.

[0010] One problem with the cryptocurrency ecosystem, however, is that non-specialist merchants lack the ISO 8583-20022 transaction protocols for cryptocurrency payments. These merchants, needing this type of transaction, cannot therefore accept customers who hold cryptocurrencies. Conversely, merchants who only accept customers who can pay with cryptocurrencies cannot benefit from the mechanisms that guarantee they will be paid.

[0011] From the specialists' perspective, even with the ability to specifically manage transaction security, a technical problem remains related to the resources involved. All workarounds require the mobilization of network and storage resources, which multiplies the data exchange requirements, while blockchain transactions are relatively slow.

[0012] An object of the invention is a method of 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 mapping _preauths which, to a first address, 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 mapping _preauths 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.

[0013] 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 the ability to reserve funds without transferring them, thereby saving transaction fees and technical resources, as all verifications are limited to the two addresses involved in the transaction.

[0014] The invention also allows: - flexibility in the amount around the transaction, - deferral of a cryptocurrency transfer with the possibility of modifying the amount, - pre-authorization to be carried out 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.

[0015] The contract inherits the remaining functions defined in ERC-20.

[0016] According to a particular embodiment of the process, 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 caller of the function has at least the quantity A of the available currency, that is to say that it currently has more than the sum of A and all existing pre-authorizations; if this is the case, the preAuthorize function grants the merchant M a pre-authorization of amount A on the caller by storing it in the mapping _preauths.

[0017] According to a particular embodiment of the process, the latter implements the smart contract in such a way 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.

[0018] According to a particular embodiment of the process, the latter implements the smart contract in such a way 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.

[0019] According to a particular embodiment of the process, the latter implements the smart contract in such a way that it includes a transferFrom function, 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 _preauths mapping and checks that F currently has more than the sum of V and all the pre-authorizations granted on it; if so, the transferFrom function transfers the value V from the debtor F to the beneficiary T; otherwise, the function returns an error.

[0020] 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.

[0021] According to a particular embodiment of the process, 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, that is to say that the creation date is not further from the current date than the maximum time limit set in the contract, - 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.

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

[0023] 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:

[0024] 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 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.

[0025] . 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 amount given, if so, delete the pre-authorization and transfer the tokens for the value V from the first address to the second address, otherwise, refuse the transfer.

[0026] The invention also relates to a computer-implemented method for transferring a given amount in one go 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 possible 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, transfer the given amount from the first address to the second address, otherwise, refuse the transfer.

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

[0028] The invention finally 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 method for carrying out a two-step transaction or the method for transferring an amount in one go, as described above. Brief description of the figures

[0029] 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:

[0030] This is a diagram illustrating the operations performed on the Ethereum blockchain between a user, a contract according to the invention, and a merchant.

[0031] This is a diagram similar to the one illustrating other operations. Detailed description

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

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

[0034] 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.

[0035] 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 involves 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 notification 5. Otherwise, the function returns an error and the pre-authorization is not granted.

[0036] Later, when merchant 3 wants to collect a sum V based on 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.

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

[0038] If, before merchant 3 calls the `collect` function, the customer attempts to transfer all their funds 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.

[0039] A sequence diagram illustrating this guarantee mechanism is shown in.

[0040] User 1 wants to grant pre-authorization to 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 the.

[0041] 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 granted. Therefore, the transfer fails, and contract 2 returns an `insufficientFunds` error 9.

[0042] Next, when merchant 3 wants to be paid the exact amount, they call 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.

[0043] 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.

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

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

[0046] Reference List: 1: User 2: Contract 3: Merchant 4: PreAuthorize Arrow 5: Success Notification 6: Collect Arrow 7: Transfer Arrow 8: Transfer_attempt Arrow 9: InsufficientFunds Error

Claims

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. 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 pre-authorizations; if so, the preAuthorize function grants M (3) a pre-authorization of amount A on the caller (1) by storing it in the mapping _preauths. 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. 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. 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. 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. A computer-implemented process to perform 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: First: - 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 amount given, 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. A computer-implemented process to transfer 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 pre-authorizations already granted by the first address (1), sum the values ​​of these possible 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, transfer the given amount from the first address (1) to the second address (3), otherwise, refuse the transfer. 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