Idea: Standard digital receipts using ERC-721

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:

  1. A customer purchases an item from an online retailer, where checking out leads the customer to payment through a smart contract,
  2. The smart contract verifys the amount transferred matches the order and provides the user with an standardized receipt NFT.
  3. 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:

  1. 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.
  2. 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:

  1. Standard JSON format of the digital receipt
  2. Standard for the encryption of digital receipt to be put as metadata
  3. Standard for metadata of a NFT Receipt
2 Likes

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:

  1. 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?

  2. 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.

  3. 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.

These are great points! Thanks for the reply

  1. 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?).

  2. 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.

  1. 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.

1 Like

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

Still have a bit of work to do on it, including doing up a reference implementation.

Would love some more feedback from the community

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.

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

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

Great job, that will make NFT first class

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

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?

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