urraca.xyz

"Urraca" is a marketplace for "Generative Object" NFTs. It is meant to enable artist and designers that produce serialized or serializable objects like prints, scarves, clothing, etc.

Each Generative Object is an NFT that can be minted for a price. When the NFT is minted, it also produces a Voucher NFT that can be used to claim the physical object. If the Generative Object's NFT is sold (over a certain threshold price), then a new Voucher is minted and assigned to the buyer. This means that selling a Generative Object NFT means 1) that the digital asset is transferred and 2) that the physical asset is multiplied!

For instance, if the NFT represents a scarf, each time the NFT is transferred, a new scarf is produced. Therefore owners of these NFTs decide whether the items remain unique/scarce, or if new instances can be produced.

These items are Generative because we also provide a smart contract to generate the images that represent the objects at mint time. Each object consists of a set of layers for an image (assumed to be images with transparency stored in IPFS), in which there's a set of options to choose for each layer. These are chosen at random during mint time, and the image will be dynamically generated from these layers when the token's URI is queried (much like Zora's Zorbs).

To launch the marketplace, we include a collection of generative scarves by teammate bigua.eth, titled "Wild Silks". Each token minted will produce a unique scarf, of which copies can be made whenever the tokens are sold on through a Zora Ask.

Sadly, we didn't have time to finish the MVP for the project, especially the frontend as we don't have a frontend dev in our team.

The project is based on scaffold-eth-typescript.

The core for this are the contracts, based on OpenZeppelin's ERC721 but borrowing a lot from ZorbNFT. The main contract is GenerativeObjectCollection, that inherits from an ERC721VoucherEmitter, that is an ERC721 to which we add the voucher creation whenever the token is transferred. We check the Zora contracts to validate that 1) there is an Ask with the correct price and 2) the transfer is initiated by Zora's ERC721TransferHelper. This ensures that the right amount of royalties will be distributed; otherwise no voucher is produced (so simply transferring the NFT to a new address won't produce a new voucher).

The plan is to use Lit Protocol for claiming vouchers, though we didn't get to implement this yet: When a user wants to claim a voucher, they first encrypt the shipping address and details, post the encrypted values to IPFS (using NFT.storage), and then call a claim() function on the voucher with the IPFS cid. When the object creator wants to ship the object, they have to decrypt the shipping details by proving they own the NFT contract. They then post the shipping tracking details in the same way, but only allowing the NFT holder to decrypt it.

(We did use NFT.storage to upload the layers for bigua's collection: https://bafybeic7uct265743l5sv5gcdwjnvlfd672rebphmy24mjek7u6tymfmxm.ipfs.nftstorage.link/ - the script to upload the folder is in a hardhat task, and then a separate task is used to post the URIs to the contract).

The plan is to deploy this to Polygon so we used Mumbai for testing, and the contract is initialized with the addresses for Zora Asks and ERC721TransferHelper from the corresponding network.

Eventually we would integrate this with the Zora SDK to query the NFTs and Asks, and probably also add a Subgraph to address the specific voucher claim functionality that is not part of the Zora API.