PSP62 imporved PSP22

[Nradko]

The PSP22 and ERC20 are very inconvenient and somehow unsecure for every user. These problems come from the mechanism of giving other accounts an allowance to spend tokens.

A lot of users' transactions include interaction with smart contracts (like Dexes, Lending Protocols, Yield Optimizers, Bridges, etc.) that want to spend users' tokens. In most of the DeFi platforms users before interaction with the smart contract need to give the smart contract allowance, so it is allowed to access the users' funds.

Such a design creates inconvenience and unnecessary costs for DeFi users because they need to send two transactions.

Moreover, it puts additional responsibility and unnecessary risk on the user. Until very recently, when giving allowance to the smart contract most platforms and wallets by default vere set U256_MAX as the "amount to be allowed" parameter. This is of course, very convenient for the user if he wants to interact with the smart contract often but it also creates the risk in the case of the smart contract upgrade. If the smart contract logic is maliciously upgraded then the user is at risk of losing all of his funds. Thus we can see that the design we have right now (PSP22 and ERC20) put users at play between convenience and risk.

Here I propose a modified PSP22 token that solves these problems. The idea is to add an additional method transfer_from_with_signature(from: AccountId, to: AccountId, value: Balamce, signature: [u8], data: [u8] ) which allows transferring "value" of tokens from account "from" to account "to" without the need of account "to" to have an allowance from account "from" but with the need to provide the appropriate message signed by the account "from". The signed message should be Encoded struct {from: AccountId, to: AccountId, value: Balamce, data: [u8] }.

[xgreenx]

You don't need to add a new method like transfer_from_with_signature=) The transfer_from method already has a data argument that you can use to pass any kind of data. For example, you can pass and work with a signature like with permit.

Instead of standardization of the new method, maybe it is worth to standardize the format of the data.

[PierreOssun]

@xgreenx If you have a lot of PSP22 in the wild how do you differentiate the one that will use data argument for sig verification (ECDSA or sr25519 ?) and the one not supporting it ?
As having a dedicated method ensure it supports the feature.
But I partially agree with you still, as we used a data field in our meta-tx implementation because of this