ERC-5570 Digital receipt NFT (Digital Receipt Non-Fungible Tokens)
Final · NFTs & multi-token · created 2022-09-01
A standard that turns the digital receipt a seller issues when a customer buys something in a store into an NFT, and puts the receipt contents in JSON format in its metadata.
Why it is needed
Online shopping receipts are still delivered by email or on paper. The point-of-sale system is already digital, but the receipt is converted into a human-readable form and then has to be moved back into digital form to enter it into a household ledger or accounting program. This round trip from digital to analog and back to digital requires unnecessary manual entry or awkward receipt scanning apps. Also, even for a transaction paid on-chain, if the receipt is stored off-chain or in a separate contract, the user later has to find and match which transaction the receipt belongs to. This standard proposes linking the receipt NFT to the purchase transaction itself, so that tapping the transaction in the wallet brings up the receipt right away. The seller can also sign with a private key to prove the receipt is genuine.
In depth
ERC-721 extension and transaction flow
This standard extends ERC-721, which covers ownership and management of unique tokens. The flow has three steps. When a customer buys from an online store, the checkout process offers the option to mint an NFT, and the smart contract delivers a digital receipt NFT to the customer. Later, when the seller processes the order, the seller uploads a digital receipt that conforms to the JSON schema defined by the standard as that NFT's metadata. In other words, the token is minted first, and the receipt data is filled in when the order is processed.
Required fields of the root schema
The receipt JSON consists of two parts: the root schema and the line item schema. The root schema (receipt.json#) requires four fields: name, description, image, and receipt. name is a name indicating that the token is a digital receipt, description is a short description, and image is a receipt image that can be viewed or printed. The core receipt object requires id (a unique ID generated by the seller), date (issue date, in date format), vendor (information about the issuing party), and items (an array of line items, at least one, no duplicates), and may optionally include comments addressed to the customer. The root also has two optional fields: signature (the seller's digital signature) and extra (additional information).
Structure of the vendor object
vendor is an object holding information about the party issuing the receipt, and name (the seller's name) and website (the website URL) are required. Optional fields are logo (logo URL), address (an array of strings making up the address, 2 to 6 entries), and contact (contact person information). The contact object has no required fields and may hold name (contact person's name), position (job title), tel (phone number), email (email address, in email format), and address (the contact person's address, 2 to 6 strings).
Line item (item.json) schema
Each line item is defined by a separate schema (item.json#), and six fields are required: id, title, date, amount, tax, and quantity. id is the unique identifier of the product or service, title is its name, date is the supply date (in date format), amount is the unit price before tax (a number), and quantity is the quantity (an integer). tax is an array, and each entry is an object that requires name (the tax name, such as GST or PST), rate (the tax rate expressed as a percentage), and amount (the total tax charged). Optional fields are description (a description), link (a URL for the product page), contract (a URL or hash of an external contract), and serial_number (a serial number).
Compatibility with existing NFT tools and signatures
This schema follows the ERC-721 Metadata extension, so tools that already display NFTs can display this receipt as is. The newly added receipt property holds the receipt structure, and the signature property is used optionally when the seller wants to digitally sign the receipt data. For backward compatibility, it is compatible with both optional ERC-721 extensions, Metadata and Enumerable. The status of this proposal is Final, meaning it is a finalized standard.
Things to watch out for
- Protecting personally identifiable information: A digital receipt contains personally identifiable information (PII) such as the seller's name, contact details, and purchased items, which can be used to identify, locate, or contact an individual. Unauthorized access could lead to abuse such as identity theft or fraud, so PII must be encrypted so that only a party holding the correct decryption key can read it.
- Encryption method is outside the standard: Encrypting PII is essential, but this ERC does not specify which encryption standard to use. Implementers must decide that separately.