thedavidmeister
commented
21 hours ago it's intentional actually, because we want the metadata about receipts to be permissionlessly extensible which means that we don't know what structure is going to work for people for various use cases, which means binary data is the only thing that will definitely work
for our own work on GUIs etc. we use the rain metadata approach, which uses magic numbers and CBOR structured metadata wrappers to make sure all data is self describing, and still permissionlessly extensible for anyone who wants to use that structure
the spec is here https://github.com/rainlanguage/specs/blob/main/metadata-v1.md
some tools for working with it https://github.com/rainlanguage/rain.metadata
i didn't go into the metadata spec stuff because it was out of scope for the audit, but yes i'd highly recommend self describing data for anyone putting information into that event, otherwise downstream tooling is going to have a very difficult time knowing when and how it should interpret the information
The receiptInformation() function in the Receipt contract can be invoked at any time by any user. However, there is no specific event type associated with this function. This can lead to potential confusion when reading and interpreting events, as it may not be clear which function invocation triggered a particular event.