Hey @0age 
great presentation on ERC-1066 at devcon
Yey thanks 
5 is unused so far, and looks a bit like $ so seems a natural fit to me.
To me as well 
The 5 = $ is in fact the visual metaphor that I’m using in my working designs, too. They’re currently in a notebook and on sticky notes on a wall.
but think a minimal implementation might be the best first step
I agree with @pakaplace here. We don’t want to prematurely impose codes, and empty ranges are a feature not a bug. Since these need to keep forward compatibility, a bit of restraint and investment in design early on will go a long way later. It’s only safe to add codes; removing them is problematic since contracts may depend on them.
I do think that there’s value in the codes that @0age proposed; I’d be surprised if these codes need to land in the final design. However, many aren’t specific to finance. For example, “invalid approval” belongs in the authorization column. Since we want consistency for both DX and (autonomous) code efficiency, some of these will need to be laid out differently.
I know that I mentioned this during the Devcon talk, but I truly apologize that ERC1066 v1.1 proposal isn’t up yet 
Our past few weeks (ie: Devcon and Tachyon) have been B-A-N-A-N-A-S, repeatedly flying intercontinentally, working on last-minute presentations, interviewing companies working with FISSION/ERC1066, possibly getting them on ETC, and so on.
Automerge is also currently broken on the EIPs repo 
, and we’re waiting for some changes like [restricted] placeholders (ie: @schemar’s suggestion) to be merged.
I’ll try to get a WIP Google Sheet up for everyone to see the current state. I’ll post to FEM when it’s live.