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.