I powered through the cryptozombies tutorials and it gave me a real sense for how to build NFTs and create interactions between NFTs. But, the best part of the tutorial came from implementing ERC721x – NFTs that have limited quantities. I mentioned this in an earlier blog post but ERC721x are items that have multiples, like a sword in world of warcraft that has many copies in a game.
This is applicable to my prayer project since multiple people can have the same prayers -so there are multiple copies of the prayer.
It is also applicable to a supply chain idea I have for a while – refiedNFT- non fungeable tokens that you can turn into physical objects. This happen, if for example, I want to make my crypto kitty into 3D printed kitty, or crypto zombie into a real card, or my crypto tee shirt into a real tee shirt. Looking at the ERC721x gave me a sense for what it would be to create my own EIP or ERC for this type of token and I have been going through the EIPs/ERCs submitted to the ethereum repo on github.
For a refiedNFT we would probably want to expand on ERC721x since we might want to create multiple editions, but to keep things simple we can start with an ERC721. To reify, we need a reification address (the manufacturers ethereum address), a physical shipping address – although this maybe we can encrypt on IPFS since it is a security issue, a description of what the physical item is, and confirmation of delivery (maybe a tracking address or the ethereum address of a shipper).
I imagine a function makePhysicalItem where the manufacturer offers to reify an NFT. And then a reify function where someone orders the physical item. I am still mulling this over. Rather than only a _mint function there are 3 other funtions: _make, _order and _fulfilled.
In the meantime, I have settled on the basic structure of my prayer coin that I will post to github this week. It will have a message (prayer), a uri (optional), strength, execution schedule, (execution place?), perhaps a notion of execution type, and then a mapping of users with number of prayers, mapping of prayers id to prayers, mapping of prayers to prayer instances (ERC721x), mapping of prayers to number of prayers. My big issue with ERC721x is that it uses indexes to divide between types of NFT (multiples and singletons). Everything with an index under 1,000,0000 is a singleton, over is a multiple. I would rather keep separate mappings rather than use this convention.
I need logic for updating the strength of a prayer – this will depend on how many people share a prayer and the last time it was ‘prayed’. I also need logic for updating the execution schedule. This will depend upon the strength of the prayer.
Thinking about an execution type complicates things. What do you want your prayer to do? Should I define it or should the prayer define it? Can the same prayer have different executions depending on who owns that particular prayer? Maybe the prayer is written to the blockchain, or ethereum is donated to a particular charity (transferred to an address). I will probably leave this out for the first iteration of the prayer coin BUT I can imagine an EIP for this to create a new token standard. I will probably just write the prayer to the blockchain for this version or write the token id as Proof of Prayer!
But, what can you do with prayers like the eco system built around cryptokitties? Well, you could build out liturgies and rituals by chaining prayers. Maybe build altars or memorials or intention experiments. I do not really know. We can imagine that perhaps many games started out as prayers or rituals – or a connection between games and ritual or prayer. Is there a connection between pickup sticks and throwing the I-Ching? I searched the internet and found this, perhaps bogus, but thought provoking article on St Teresa of Avila – the patron saint of chess. St Terese encouraged because the attributes necessary to become a good chess player are similar to the attributes necessary to become a spiritual person. So maybe we can create a cryptokitties universe from cryptoprayers.