## 3 Design of the Proposed System
### System Overview
In case it gets destroyed, lost, or stolen, new copies can cheaply and easily be made, based on proof of ownership. Such an approach also limits the possibility of cheating at tournaments by marking cards invisible only for malicious actors. Tournaments can be organized in such a manner that players register their decks through blockchain, where the ownership of the cards is confirmed. Then, physical cards are prepared in advance and only provided to players when a tournament starts, thus preventing any abuse. This design fully decouples the various workflows, minimizing dependencies between different entities. Once the game is registered by a system operator, the game developer is not dependent on them anymore. Even if the operator goes out of business, while no new game will be able to be registered, game developers still have uninterrupted ability to create new collocations and distribute cards. Similarly, once a game developer signs the metadata for a pack of cards, a user is independent of their operation. Even if a developer ceases business activity, a user can still open a pack and scan the QR code. The signature will still be valid, and tokens will be created. Figure 2: Sequence diagram of booster cards redemption. The data related to the card will be stored on two layers. One is directly in the blockchain. To avoid unnecessary costs, the majority of the data will be offloaded to IPFS as blockchain storage is expensive. Five crucial information blocks will remain on the blockchain, four of which will be conveniently stored within the token id. Since each token will have its own token id, which is a 256-bit number, it consists of four parts, each representing a new sector of data (Figure 3). The first block of 32 bits indicates the game id, which points to a game to which the token is assigned. The next 32 bits are for the collection id, which marks the collections where a given card was created. The third block is 160 bits of card data. This space is reserved for game developers to implement custom functionality such as the rarity of cards or other systems. The last 32 bits will be used to identify a card inside the game and collection. This part will also help resolve proper metadata for the card. The additional fifth piece of data will be the IPFS hash of the directory containing the card's metadata. To reach IPFS metadata for a given token, the following actions will be taken. First, a smart contract is queried for the IPFS CID of the collection using token id. A smart contract retrieves a relevant part of the token (collection id) and resolves it, returning an IPFS link in the format of ipfs://<CID>/<card id>. Then, the application will replace an ipfs:// protocol with any IPFS gateway configured for the service. After that, the token metadata will be retrieved, among which another ipfs://<CID>/<card id>-png link will be stored, pointing to the image. Finally, having resolved the image, the application can put together a representation of the token. The designed system is flexible and open to new features. Since all the data, both regarding ownership as well as metadata regarding the cards, collections, and games, are available publicly, players can create additional services or use existing ones to interact with their collections. They are free to view, trade, or make custom services that will interact with the smart contract.