Skip to main content

Ticketing

Traditionally in blockchain-based ticketing systems, a user is expected to buy an NFT ticket and then on location of an event do one of the following:

  1. show the NFT and sign a message
  2. burn the NFT
  3. show the NFT

1 and 2 require the user to have a wallet, or surrender control of it - i.e. have a custodial wallet in his account in a centralized ticketing provider's system. This is neither very web3, nor very secure.

3 is very insecure in that anyone can just download the NFT and show it instead of the real owner. This will either let an infinite number of people in, or require centralized tracking on the gatekeeper side so make sure a single QR code did not enter twice. Even then, there is no guarantee the right person got in.

There is a better way: RMRK's Multi-Resource NFTs.

Using Multi-Resource NFTs for Ticketing#

Again, several approaches are possible. Here we document the recommended one.

A user buys an NFT ticket. The ticket, just by being a RMRK MR NFT, is compatible with ERC721 and thus all marketplaces, but is also enriched with more functionality. While buying, the user provides a custom string, like a special keyword, which is hashed and added as the ticket's attribute. Let's assume this special string is banana and the Sha1 hash of it is 250e77f12a5ab6972a0895d290c4792f0a326ea8.

The null-resource is set to be the ticket itself. The null-resource is the initial resource, the default shown when no other resources are available. Null-resources are typically used for revealable NFTs, and these come in very handy in this scenario.

The user shows up at the door of the event, and displays the NFT QR code.

The gatekeeper scans the QR code, and asks the user for the keyword. The user says "pineapple", and the gatekeeper's software automatically runs it through sha1 to get ff9907a80070300578eb65a2137670009e8c17cf. Whoops! You do not seem to be the real owner! NEXT!

This fraudster is kicked out of the queue and the processing continues. A few people later, another person shows up with the same QR of the NFT, and the correct word: banana. The software again runs it, this time it matches.

The gatekeeper's app now creates a new resource - a "ticket stub" image with some cool visuals, and adds it to the NFT that was just loaded via the QR code.

Since any resource takes precedence over null, the original ticket resource would be overwritten by this new one, the ticket stub, proving the attendance of this user, and marking the NFT as "used", all in a fully decentralized way - all on protocol.

Advantages#

  1. The users ends up with a really cool looking POA
  2. There is no need for a centralized database of used-up tickets
  3. There is no need for a user to carry around a mobile wallet

Downsides#

  1. Since only the collection issuer can issue new resources to NFTs, the software of the gatekeepers would either have to be a hot wallet, or connected to a server issuing these calls which in turn hosts the issuer wallet. We are working on a system that would allow an issuer to set additional resource proposers, solving this problem.
  2. If the internet goes out, you cannot verifiably "tear" people's tickets, and need to trust that they are the real owners. They probably miss out on the "POA" (proof of attendance) aspect of it then too, since they never get the extra resource.