Hello - great presentation on ERC-1066 at devcon, @expede!
I’d like to propose a group of status codes specifically tailored to token transfers in the 0x5*
range (as a pretty significant proportion of transactions deal specifically in that department ). 5 is unused so far, and looks a bit like $ so seems a natural fit to me. Here’s the proposal for that range:
code | description |
---|---|
0x50 | transfer failure |
0x51 | transfer success |
0x52 | insufficient balance |
0x53 | insufficient allowance |
0x54 | invalid sender |
0x55 | invalid receiver |
0x56 | invalid operator |
0x57 | invalid value |
0x58 | invalid data |
0x59 | invalid approval |
0x5a | invalid state |
0x5b | contract paused |
0x5c | funds locked |
0x5d | invalid issuance |
0x5e | invalid redemption |
0x5f | token meta or info |
0x50
/ 0x51
would be for generic success / failure, 0x52
& 0x53
for the most common failure modes in a standard ERC20 token, then 0x54
through 0x58
would signify invalid parameters in more restrictive permissioned tokens. 0x59
would show that the transfer lacks approval (above and beyond the standard allowance), and 0x5a
would mean that the transfer would put the token into an impermissible state (for instance, maybe the token restricts the number of holders). 0x5b
would signal that all transfers are frozen (maybe the token has been retired or migrated to a new contract) and 0x5c
would mean that the particular tokens in question were frozen (e.g. there is a lock-up period for the tokens that is still in effect). 0x5d
& 0x5e
would be returned if the token transfer would invoke an invalid mint or burn operation, respectively, and 0x5f
would signal metadata in the same vein as the rest of the specification.