Title: Idea__Standard_digital_receipts_using_ERC_721
Category: ERCs

Author: darcys22
Date: 2022-07-11T22:12:45.260Z

Hi Eth Magicians, wanted to discuss some thoughts I had regarding digital receipts on the blockchain and interested to hear what others think.
Simple Summary:
Using ERC-721/NFTs as a method of distributing digital receipts for physical purchases. Where the metadata represents an encrypted json receipt.
Abstract:
I’d like to propose the idea of a transaction that flows as follows:

A customer purchases an item from an online retailer, where checking out leads the customer to payment through a smart contract,
The smart contract verifys the amount transferred matches the order and provides the user with an standardized receipt NFT.
When fulfilling the order, the retailer will upload the metadata to this nft which will be encrypted against the customers public key.

Motivation:
If a customer purchases a physical item from an online retailer and uses a cryptocurrency to pay, the purchase will separately includes an invoice/receipt from the retailer that is emailed and/or physically   given to the customer. These receipts are critical for many reasons but digital receipts AFAIK have never gained traction. Instead we are left with PDFs and other analogue formats to represent transactions    that occurred digitally.
Including an NFT as a receipt will provide a traceable and private link between the funds leaving the customers account and the digital receipt which may include important information such as serial numbers   and delivery tracking etc. This means that the customer can automate their record keeping with systems and understand exactly what has been purchased without a human having to provide copies of the receipts.  Metamask for example could show this full receipt when you click into an item in your transaction history.
One of the major roadblocks to fully automating our current finance world is that businesses need to keep detailed records of our purchases and retailer systems distribute this detailed information outside of our transactional system (Printing a physical receipt, while separately processing payment through the EFTPOS machine). Requiring a human being to physically make the link between the two, usually by data     entry into the financial system. This is archaic and NFTs on the blockchain provide a method for this to be so much better.
Outstanding thoughts:

A less interesting thought is that the amount in this encrypted receipt could be proven by the retailer using some zero knowledge proof, which could mean a blockchain could reject the transaction if this   receipt does not match the amount transferred. Voiding the transaction.
A more interesting thought would be if the serial number encrypted in this receipt could be proven at a later time by the customer for use in warranty claims, maintenance requests, servicing etc.

Unsure if these are even possible, zero knowledge proofs are hard.
Next Steps:
If this has any sort of interest I could draft up the following standards for people to review:

Standard JSON format of the digital receipt
Standard for the encryption of digital receipt to be put as metadata
Standard for metadata of a NFT Receipt

Author: DAYvid
Date: 2022-07-12T20:34:05.859Z

I think this is an excellent idea. Provides the benefits of In Real Life (IRL) receipts and solves some of their problems (e.g. warranty claims).
JSON is a great choice for data format, too. Human readable and standardized for efficient digital use.
Here’s some feedback to consider:


In Real Life (IRL) receipts are issued by the vendor, which make them more valid when used as evidence to third parties (e.g. taxes). If the receipt is issued by a smart contract upon receipt of payment, it loses that evidentiary quality because it only serves as proof of transferred funds. Was the item exchanged as well?


If the primary purpose of the NFT is the receipt, shouldn’t we store the data in the image of the NFT (rather than in metadata)? Remember that the “image” of an NFT doesn’t need to be pixel data that translates into a visual picture. ERC-721 doesn’t require that.


Encryption is clearly necessary to preserve privacy. Are there other privacy risks presented by common use of this? Wouldn’t some be hesitant to reveal the link between their IRL persona and their pseudonymous on-chain account? Think about how IRL receipts don’t include the full credit card number but only the last 4 digits.


These considerations are only about implementation details. I’m looking forward to seeing the first draft of this.

Author: darcys22
Date: 2022-07-13T07:14:43.668Z

These are great points! Thanks for the reply


I guess when I refer to a smart contract here I am also assuming the vendor is in control of the smart contract and the receipt would include some form of signature to prove that they indeed issued the receipt. I guess proof that the vendor indeed delivered the goods is another problem (Maybe solved by tracking information?).


I may have confused the term for metadata here. I thought I understood this but maybe not. But I guess if the URL in the token points to a JSON file (Stored on IPFS possibly) and structured like this:


{
  "version": 3,
  "id": "07a9f767-93c5-4842-9afd-b3b083659f04",
  "address": "aef8cad64d29fcc4ed07629b9e896ebc3160a8d0",
  "Crypto": {
    "ciphertext": "99d0e66c67941a08690e48222a58843ef2481e110969325db7ff5284cd3d3093",
    "cipherparams": { "iv": "7d7fabf8dee2e77f0d7e3ff3b965fc23" },
    "cipher": "aes-128-ctr",
    "kdf": "scrypt",
    "kdfparams": {
      "dklen": 32,
      "salt": "85ad073989d461c72358ccaea3551f7ecb8e672503cb05c2ee80cfb6b922f4d4",
      "n": 8192,
      "r": 8,
      "p": 1
      },
    "mac": "06dcf1cc4bffe1616fafe94a2a7087fd79df444756bb17c93af588c3ab02a913"
  }
}

And the cypher text decrypts to what our json receipt is.

Yeah there is definitely an element of privacy reduction in this, however I think a lot of it occurs simply by making the purchase. If you were analysing a wallet then knowledge that a transaction got a receipt (but not knowing the contents) is maybe only slightly more revealing than knowing they transferred to that business at all.

Appreciate the feedback, I might draft up an issue on the EIPS/ERC repos over the next few weeks to see what feedback I can get there.

Author: darcys22
Date: 2022-07-26T06:58:40.709Z

So I’ve typed up a rough draft of this here:

github.com


darcys22/digital-receipts-erc/blob/master/eip.md
---
eip:
title: Digital Receipt Non-Fungible Tokens
author: Sean Darcy <darcys22@gmail.com>
discussions-to: https://ethereum-magicians.org/t/idea-standard-digital-receipts-using-erc-721/9908
status: 
type: Standards Track
category: ERC
created: 
requires: 721
---

## Simple Summary

Using Non-Fungible Tokens as a method of distributing digital receipts for physical purchases. Where the metadata represents an encrypted json receipt.

## Abstract

This EIP proposes a standard schema for digital receipts of transactions occuring on chain. Digital Receipt Non-Fungibles Token are issued by a vendor when a customer makes a purchase from their store and contains transaction details necessary for record keeping. The transaction details are encrypted against the customers public key and kept off chain. Digital Receipt Non-Fungible Tokens extend [ERC-721](./eip-721.md) which allows for representing assets





  This file has been truncated. show original





Still have a bit of work to do on it, including doing up a reference implementation.
Would love some more feedback from the community

Author: buoynous
Date: 2022-07-27T06:32:57.435Z

Great idea!
Quick question. Given that NFTs are currently tied to an image, what image are you planning to use for this specific NFT?
I think what @DAYvid was suggesting is to use the metadata to generate an image with texts. Something like LOOT.
Also I am not a big fan of storing things in the IPFS, especially if it is not a PFP collection that has limited supply. This can easily grow into a very large number of supply without a ceiling. In this case I think storing it on chain makes more sense.
But then that brings to another question of how do we plan on storing a large json file on-chain in a graceful way.

Author: darcys22
Date: 2022-07-27T07:13:29.425Z

So wouldn’t mind getting this clarified, my understanding of ERC-721 is that it
defines a minimum interface a smart contract must implement to allow unique tokens to be managed, owned, and traded. It does not mandate a standard for token metadata or restrict adding supplemental functions.

Where as ERC721Metadata is what actually ties the standard to an image and the **metadata extension** is OPTIONAL for ERC-721 smart contracts
So in my draft EIP i have mentioned under the backward compatibility section that
This standard is an extension of ERC-721. It is not compatible with commonly used optional extensions (IERC721Metadata and IERC721Enumerable) mentioned in the EIP-721 standard.

Which I think would be enough to say that the digital receipt NFT could point at a tokenURI that contains JSON that doesn’t comply with the IERC721Metadata extension. But I am not 100% sure on this. Would love some guidance here.
That way the tokenURI points to a JSON file of our encrypted receipt, containing none of the normal NFT image fields.
Alternatively I really like how loot have generated their image in the contract as a SVG containing all the text. So the image could be a printable representation of the JSON receipt. Which would be great. An SVG like this is way better than a PDF receipt.
In regards to IPFS, I actually think the vendors would host their digital receipts on their own servers. This means there is a risk that the tokenURI would eventually point to a dead link, but its probably reasonable to expect the purchaser to back that receipt up somewhere safe. If your digital receipt is signed by the vendor then you have proof that its real, even if the original disappears

Author: Property
Date: 2022-08-03T11:03:40.364Z

Love the idea, however i dont think id like giving my private key to third parties/finance systems to decrypt the receipts. Surely it would be better to encrypt the receipt with some derivative of the purchasers public key instead

Author: zzyalbert
Date: 2022-08-04T08:37:48.911Z

Great job, that will make NFT first class

Author: darcys22
Date: 2022-08-09T11:34:56.608Z

Yeah im liking this idea and still need to do some thinking about the encryption. It possibly should have optional encryption or no encryption in this ERC and then in another ERC design a way to encrypt all NFT types

Author: KeeJef
Date: 2022-08-15T05:33:38.059Z

Looks good to me, could this mix with existing digital ticketing proposals? Like buying a concert ticket and receiving a digital NFT to show as proof of entry?

Author: darcys22
Date: 2022-08-15T21:10:06.536Z

Yeah definitely, it would be the modern equivalent of showing your receipt to prove you bought a ticket

Author: darcys22
Date: 2022-08-30T09:58:29.248Z

Alright so pretty exciting times. Got a working demo, still got some rough ends to work on but we got ourselves a pretty cool looking digital receipt:
https://goerli.pixxiti.com/nfts/0xdce729ce90c35eaa36a2129bef25d0cf209fec10/12
This is all being hosted on receipts.darcyfinancial.com
and the source is all available here: GitHub - darcys22/digital-receipts-erc: NFT digital receipts demo
Would love to get some feedback from people. Got a draft of the EIP that im not far off submitting either (Also available in that github repo)

Author: darcys22
Date: 2022-09-01T07:36:13.967Z

And have opened the PR for this now in the EIPS repo:
https://github.com/ethereum/EIPs/pull/5570
EIP-5570

Author: radek
Date: 2022-09-05T11:16:34.114Z

Even though I like the general idea, there is a significant issue with digital receipts. Jurisdictions.
Eg here is the formal template for the receipt in one of the EU countries: https://www.etrzby.cz/assets/cs/obrazky/vzorova_uctenka.jpg
The solution would require some global research for common fields and extensibility for particular jurisdictions. The extensibility would need to be flexible as the govs requirements are changing from time to time.

Author: SamWilsn
Date: 2022-09-06T15:39:00.315Z

If the only address that can update the receipt metadata is the retailer, why do you additionally need to sign the structure?
Should implementations verify the signature of the receipt upon uploading?

Author: darcys22
Date: 2022-09-06T20:41:25.543Z

The metadata is hosted by the retailer and without enforcing that the metadata is hosted on ipfs or something there is a good chance that customers end up with receipts linking to dead tokenURIs.
By signing the receipt the customer has the option to copy the whole receipt into their own financial system and that copy being sufficient evidence without needing the link. It would be the modern equivalent of keeping a copy in case the original gets destroyed.
I don’t think implementations should need to actually verify the receipt, but I can see scenarios such as auditors receiving copies of the receipts and wanting to verify that the receipt isn’t falsified by checking the signature.

Author: darcys22
Date: 2022-09-06T21:05:54.824Z

This is an awesome point and I’m glad it got raised. I know my own jurisdiction (Aus) well but seeing other countries requirements I immediately recognise that the structure needs some updating to be more flexible (variable number of taxes, additional purchase identification areas).
I think something that will both a blessing and a curse in this area is that countries will be slow to accept these digital receipts to substantiate expense claims. So even if our structure contains all the correct fields, a tax office auditor may still reject the receipt and require alternative proof of purchase (at least initially).
The opportunity that this brings would be that we don’t need to be compliant with all jurisdictions initially, and can work on making them compliant incrementally. As long as our first version is at least useful (which would be providing enough information to the customers financial systems to categorise the expense) then we can add additional fields to a v2 or even a subversion v2.1 for specific jurisdictions.
In saying that however, I have some ideas that should make the receipts more flexible and I want to add to the v1. So even if the structure isn’t perfect, a business could still achieve compliance with workarounds if necessary. For example putting an unstructured “extra” field so you can display additional fields such as the FIK, BKP and PKP fields in that cz structure you linked.

Author: SamWilsn
Date: 2022-09-06T21:15:20.132Z

darcys22:

The metadata is hosted by the retailer and without enforcing that the metadata is hosted on ipfs or something there is a good chance that customers end up with receipts linking to dead tokenURIs.


I’m still not quite sure why this needs to be on-chain. Couldn’t the retailer just send a signed receipt to the buyer over email or something?



 darcys22:

By signing the receipt the customer has the option to copy the whole receipt into their own financial system and that copy being sufficient evidence without needing the link. It would be the modern equivalent of keeping a copy in case the original gets destroyed.


Hm, so what differentiates that from copying the signed transaction adding the metadata? (I’m mostly playing devil’s advocate here, I do see the value.)



 darcys22:

I don’t think implementations should need to actually verify the receipt, but I can see scenarios such as auditors receiving copies of the receipts and wanting to verify that the receipt isn’t falsified by checking the signature.


So I’m imagining a scenario where a retailer uploads an invalid signature, and the buyer doesn’t check the signature until much later (say during a dispute.) Since the transaction signature is valid, but the contract doesn’t check the embedded signature, you can get a disagreement about what is correct.

Author: darcys22
Date: 2022-09-06T22:23:56.971Z

Awesome points, appreciate the reply.

I’m still not quite sure why this needs to be on-chain. Couldn’t the retailer just send a signed receipt to the buyer over email or something?

The value of being on chain is the initial link between the transaction and the receipt. A financial system monitoring a wallet sees a transaction for 10 eth which includes the nft receipt also saying 10 eth can be certain that transaction is represented by that receipt. It’s also an easy convenient place to store your receipts, even if you aren’t actively tracking them. You can come directly to the transaction if you need to review the receipt.
A good alternative would be a retailer emailing a json receipt and a financial system capable of retrieving the email and matching that to a transaction. Although less convenient to go back through emails to find the receipt if you aren’t running a system, this would be sufficient if it existed. Unfortunately the world has decided that PDFs via email is the easiest method here and parsing the pdf is actually the roadblock preventing progress. Because the retailers need to comply with tax regulations for evidence of purchase it needs to be the tax offices that lead the standardisation of the digital structure to take this pathway. Unfortunately they have shown no initiative to do so despite having decades of opportunity.
I actually expect if we get some traction for digital receipts in the cryptocurrency world that will start the fire that forces the old financial system to also standardise their local jurisdictions in a digital format. And we can update our standard to directly copy that if they eventually do.

Hm, so what differentiates that from copying the signed transaction adding the metadata? (I’m mostly playing devil’s advocate here, I do see the value.)

This actually is interesting to explore, from the customers perspective there is no difference. The receipts purpose is simply to clarify the details, and the certainty that the receipts contents are true comes from directly experiencing the transaction. A third party needing to verify the transaction however cannot rely on an unverified statement, so the receipt contents need to be signed by any retailer to meet their evidence requirements. My thoughts are that we require the receipt contain the https url of the retailer, and their ssl certificate is used to sign the contents of the receipt. That way a third party can have 100% certainty of the receipt contents (and the customer isn’t trying to hide an alcohol purchase with a fake receipt).

So I’m imagining a scenario where a retailer uploads an invalid signature, and the buyer doesn’t check the signature until much later (say during a dispute.) Since the transaction signature is valid, but the contract doesn’t check the embedded signature, you can get a disagreement about what is correct.

Yeah this would be possible, this is why it would be prudent to check the receipt signature is correct. But I don’t think we should enforce it here in this system, instead allow the customers to complain to the retailer, saying their receipts are incorrect and allowing the retailer to upload an amended and corrected receipt at a later date.
A business customer running a formal financial system that would likely be the place to check. Non business customers rely on the retailer satisfying its business customer needs who will complain.
I don’t think there is too high of a risk from retailers intentionally creating false receipts, there isn’t much to gain. And if we allow the metadata to change when mistakes/errors occur then it addresses the more common reason for incorrect signatures

Author: benmills
Date: 2022-09-10T04:10:17.991Z

I think this is a very interesting idea.
Would it be possible to use this to provide better security options for NFTs? Here is one way I could imagine it working as an example:
If I receive an NFT Receipt with a valid NFT purchase, I could move the Receipt NFT to a cold wallet. If I lose my NFT due to fraud, I can present the NFT Receipt to reclaim the NFT.

Author: darcys22
Date: 2022-09-10T06:22:59.421Z

I hadnt thought too deep into that side of things! But love it!
Like a nft recovery method!

Author: darcys22
Date: 2022-09-15T21:15:59.540Z

Drafted up a long form introduction to ERC5570 - Digital Receipts:
https://medium.com/@darcys22/introducing-digital-receipts-and-erc5570-30955e3f99b

Author: darcys22
Date: 2022-09-25T03:15:59.555Z

Have published a video demonstrating the usage of the demo application here:

Author: poojaranjan
Date: 2023-01-09T15:01:44.456Z

PEEPanEIP #95: EIP-5570: Digital Receipt Non-Fungible Tokens with @darcys22

Author: nickjuntilla
Date: 2023-01-12T17:56:27.604Z

There are two main improvements that need to be made:


You need to be able to put the items in an array.


The items should be able to be NFTs themselves. Therefore each item should have a property for smart contract and tokenId.

Author: nickjuntilla
Date: 2023-01-12T17:58:29.844Z

Another improvement would be to make the price queryable so it would be a module you can add to the smart contract so things like oracles can read the price. If the price data is only in the metadata then it cannot be integrated into smart contracts.

Author: xinbenlv
Date: 2023-01-12T18:08:30.642Z

This sounds an interesting idea worth pursuing!

Author: darcys22
Date: 2023-01-12T21:46:23.651Z

Could you clarify your point on putting items in an array? They already are in an array:
       "items": {
          "title": "Items",
          "description": "Items included into the receipt",
          "type": "array",
          "minItems": 1,
          "uniqueItems": true,
          "items": {
            "$ref": "item.json#"
          }
        },

I like the idea that the items themselves could be NFTs, If the NFT was issued in the same transaction as the receipt you would be able to find the NFT easily enough but i guess if the receipts was copied you would lose this link. It sorta falls into the same category as serial numbers for product so I think it would need to be general enough to handle both here.

Author: darcys22
Date: 2023-01-12T21:48:56.822Z

This is also an interesting idea! Did you have an example use cases where a smart contract would query the price of an item receipt?

Author: wwhchung
Date: 2023-01-13T03:09:03.626Z

Echoing above. Why does this need to be an nft issued on chain? You could accomplish the above by simply emitting an event with the data you need (signed and encrypted receipt data along with the uri string), which would be much cheaper than creating an nft. Systems can observe and index these events.

Author: nickjuntilla
Date: 2023-01-13T04:11:55.081Z

Ok for the items array I think you just have a syntax error in the json. There should be a bracket instead of a curly brach after the colon or at least that’s what I was looking for when I scanned the json so:
"items": {
          "title": "Items",
          "description": "Items included into the receipt",
          "type": "array",
          "minItems": 1,
          "uniqueItems": true,
          "items": [{
            "$ref": "item.json#"
          }, ...]
        },

I’m not sure I understand what you mean that if the receipt was copied you would lose the link. A smart contract and an NFT ID on that contract will always point to the same NFT. The only case it could be different would be if it was on another blockchain so you could put the NFT ID (int), smart contract (string: address) and blockchain (string) to really triangulate an NFT. You don’t have to include any prefix or anything. Software can use that data to find the meta data of any NFT you have those 3 items for.

Author: nickjuntilla
Date: 2023-01-13T05:11:30.492Z

I made this code snipped: receipt-standard/eip-5570-solidity.sol at main · Ownerfy/receipt-standard · GitHub
It’s inspired by: EIP-2981: NFT Royalty Standard
The idea is that blockchain apps can then also query this data. This can be very useful for DAOs, accounting, royalties, defi and all kinds of financial services.
pragma solidity ^0.8.0;
import "./IERC165.sol";

///
/// @dev Interface for eip-5570 Receipt Standard
///
interface IERC5570 is IERC165 {
    /// ERC165 bytes to add to interface array - set in parent contract
    /// implementing this standard
    ///
    /// Below needs to be calculated depending on final interface
    /// bytes4(keccak256("receipt(uint256,uint256)")) == 0xUNSET
    /// bytes4 private constant _INTERFACE_ID_ERC5570 = 0xUNSET;
    /// _registerInterface(_INTERFACE_ID_ERC5570);

    function paid(
        uint256 _tokenId,
    ) external view returns (
        uint256 goodsAndServices,
        uint256 fees,
        uint256 tax,
        bytes8 symbol
    );
    
    function buyer(
        uint256 _tokenId,
    ) external view returns (
        address buyerAddress
    );
    
    function seller(
        uint256 _tokenId,
    ) external view returns (
        address seller
    );
    
    // Optional - Used for the sale of things represented by NFTs
    // Returns all the tokenIds that were sold, their contracts, and prices 
    // The price should be in the symbol designated above.
    // It might be useful to have an NFT reference the receipt it was sold in 
    // and the reference receipt NFT would have to conform to this standard
    function purchasedItems(
        uint256 _tokenId,
    ) external view returns (
        uint256[] tokenId,
        address[] contract,
        uint256[] price
    );
}

interface IERC165 {
    /// @notice Query if a contract implements an interface
    /// @param interfaceID The interface identifier, as specified in ERC-165
    /// @dev Interface identification is specified in ERC-165. This function
    ///  uses less than 30,000 gas.
    /// @return `true` if the contract implements `interfaceID` and
    ///  `interfaceID` is not 0xffffffff, `false` otherwise
    function supportsInterface(bytes4 interfaceID) external view returns (bool);
}

Author: darcys22
Date: 2023-01-15T20:14:01.809Z

Could you confirm what the bracket recommendation is based off? As far as I can see the syntax that is in the schema is correct according to array — Understanding JSON Schema 2020-12 documentation

Author: darcys22
Date: 2023-01-15T20:24:41.357Z

Yeah this is an awesome suggestion, instead of an NFT it could define a standard event structure. @Pandapip1 raised similar concerns.
At this point in time I can’t think of any real advantages as to why an NFT would be better than an Event being emitted.
It’s like maybe you could use the NFT in another smart contract, but Nicks suggestion that the receipt should contain a field to link to another NFT (or serial number) makes more sense for that too.
I’m going to shoot some messages out to the people I know who were building things using this and see if changing this would affect them.
Thanks for the feedback!

Author: nickjuntilla
Date: 2023-01-15T20:46:11.905Z

No you’re right, sorry my mistake!

Author: darcys22
Date: 2023-02-17T05:42:35.296Z

So I have been sending messages to people who have reached out and shown interest in this EIP so far and have been discussing their thoughts on whether this digital receipt format should stay  as an NFT or whether changing to an event would be better for their purposes.
The conclusion I have reached is that it should stay as an NFT even if this means more on chain data and gas. The reasons I have collected so far are as follows:

Simplicity: NFTs are well understood by the community and end users. When discussing the idea of a digital receipt as an NFT almost everyone immediately recognises how the transaction leads to an NFT and this NFT leads to some data. Although the usage of an event would contain a similar workflow this is not something many users have done before and most reactions I’ve had to using an event are whether its even possible (It definitely is, but the workflow for how this would work is foreign most users).
Versatility: When suggesting a receipt as an NFT people appear excited about the ideas of what can be built on top of this. Things like warranty claims and review websites have been suggested to me where a smart contract can check if you own the NFT. I believe a lot of these are still possible using events, but would be more difficult cause you would need to analyse blocks to see if it the receipt exists for this person.
Consistency: Ethereum as a whole uses tokens to do things, almost all of the things that have been built are done by moving tokens around. An NFT receipt is consistent with how ethereum end users do things. This is contrasted to events which are typically used by devs when doing tests and by analysts looking over the blockchain. End users don’t usually touch events so to make them follow an event here would be inconsistent.
Gas: The primary argument for events is that it would save on gas. Obviously the current proposal on L1 would be too expensive, even right now when gas prices are quite low the price of $2- $5 for a receipt is unfeasible. So L2s are almost immediately a requirement for this proposal where gas prices and block space is cheap enough for this to exist. So optimising this proposal for Gas I believe would be incorrect here.

Overall the tradeoff here is to save gas vs usability for users and I don’t believe the savings in gas justify the increase in difficulty for end users. So I have kept the structure as an NFT rather than adjusting to an event and keeping it entirely off chain.

Author: darcys22
Date: 2023-02-17T05:54:39.737Z

I’ve also pushed 2 changes to the schema today,

A field in the line items to link to a contract; and
A field in the line items to reference a serial number

Providing a optional serial number in the receipt seems like an obvious addition, and a link to an external document containing a contract might be useful here.
But this also allows us to link the line item to another NFT if we wanted, by referencing the smart contract hash in the contract field and the ID number in the serial number field.

Author: darcys22
Date: 2023-03-17T22:00:28.527Z

And have moved this to Final Call. Last call deadline set for 1 April 2023
https://github.com/ethereum/EIPs/pull/6703

Author: bawtman
Date: 2023-03-18T01:38:18.663Z

Hi @darcys22 , When I first started reading this thread I was not necessarily fond of using an NFT in this manner. But I am now convinced that this is definitely a unique and useful idea. Not only could this serve as a receipt and warranty, it could also serve as a maintenance record, recall system and much more. Kudos on your hard work with this, I am in hopes that it will be implemented. I feel it would not be the proper method for some items, with a price say < $300 or some amount. That could even be a choice made by the purchaser. It those cases the emitted event method could be more useful and save on gas. One last thought would be an additional field for a purchase order number when used in a business setting and/or a comment field.

Author: darcys22
Date: 2023-03-23T03:07:49.512Z

@Pandapip1 has raised an interesting point about privacy aspects of the data contained in the digital receipts.
The schema contains significant private information about the items a user has purchased, aswell as identifying information about the vendor (ie Name, Telephone, Email, Address).
This information should not be conveyed in clear text over any medium, and the full intent is for the information contained in this ERC to be encrypted. My first draft contained some details on how one would go about doing this encryption, but it quickly became apparent that it deserved its own ERC to describe a method for “encrypted NFTs”.
Essentially the encryption method is out of scope for this ERC.
Discussions already exist in ERC-5630 on how one would go about encrypting using ethereum keys, I personally am a big fan in this case of how it would allow the vendor to encrypt the metadata using the purchasers ethereum address, and only the purchaser would be able to decrypt.