Right, I think we can both agree that we need proper specs and examples for interoperability 
Inspired by your proposal, we can add the value to the kind only for ephemeral resources. This ensures that the same ephemeral resources are correctly created and consumed within transactions. We don’t need to worry about tampering with the value for ephemeral resources since kind computation is constrained by compliance proofs. Although it makes no difference to put everything to labels and it would make the label and value have the same functionality for ephemeral resources, I think it might be fine as the value in ephemeral resources currently is useless or dangerous to use. This approach might address @mariari’s example and prevents misuse of ephemeral resource values with minimal changes to the current design.
3 Likes
That actually sounds like a pretty good idea to me. @mariari thoughts?
@xuyang’s proposal is very sensible to me and would fix the issue that I’m having on this front, so I’m happy with that.
1 Like
Yet one thing that I then keep asking myself is: if we accept Jeremy’s paradigm it seems that we have no use of quantity for non-ephemeral resources such as XAN or Spacebucks at all.
What will the delta proof actually check there?
I understand the point that at some point we might figure a way for it to breach interoperability yet even assuming we do, if we do not use the quantity field for these resources what would that delta proof actually be used for?