The Brave wallet assumes that all transaction starting with the same hash as ‘transfer(address,address,uint256’) will necessarly be a erc20 transactions and expect it to have always 18 decimals. I haven’t tested but I do assume that other ERC20, ERC721, ERC1155 may be affected similarly.
As a consequence, Brave will be prevent executing theses transactions without any work around available.
Similarlly, the Brave wallet currently does not support custom tokens with 0 decimals.
The only work around I’ve found yet, is to create a custom token with an invalid non 0 decimals, which breaks the transaction display but at least does not prevent the transaction to execute…
My previous message don’t explicit describe my expectations.
I am adding them below:
Allow the definition of 0 decimals custom tokens
Don’t prevent executing transactions based on non guaranteed assumptions targeting not yet known contracts. A simple warning is preferably better.
Rely on transaction gas estimation check to prevent transaction, not on erc20 balance. But consider that failing a transaction is as well a valid scenario which may have an impact on contract. Rather than preventing failing transaction, allow a way to by pass the warning.
Don’t prevent executing transactions based on non guaranteed assumptions targeting not yet known contracts. A simple warning is preferably better.
Do you mean you’re unable to send a transaction for an arbitrary contract with arbitrary data? This should already work, we just don’t parse the Data sent in the transaction.
Rely on transaction gas estimation check to prevent transaction, not on erc20 balance. But consider that failing a transaction is as well a valid scenario which may have an impact on contract. Rather than preventing failing transaction, allow a way to by pass the warning.
Allow to bypass insufficient gas if we calculate that the transaction will not work? Can you give a use case where this is useful?