## 3 Design of the Proposed System
### System Overview  
The proposed system provides a platform for game developers to easily add the capability of blockchain-based security to their games. This aims to create an interoperable platform where multiple games can exist. Users' experiences would be unified, thus reducing the entry threshold. The operator of the system has two responsibilities. First, it deploys the smart contract to a chosen blockchain using its private key. This key, if it is a perquisite, should be required for operation and should be generated using available tools, which are dependent on the platform of choice. Then, their private key has the authority to register new keys in the system with the role of game developers. Game developers need to request approval, e.g., through simple registration process, where details about the game and responsible entity is provided (Step 1) in Figure 1. A game developer will need to provide the public key to which ownership over a game on the blockchain will be given. The responsibility of generation for this key is on the game developer. Available tools should be used, depending on the platform at which the system operator decides to deploy the system.This step will be required to prevent malicious entities from flooding the system with malicious names. This step should only validate the authenticity of the entity. If the game exists, and the requesting entity proves their ownership of the game, a new game id shall be provided to them, and their public key will be registered within the smart contract by the system operator. Once their key is registered, they obtain full ownership over a given name space in which all of their tokens will exist. Having the registered key provides game developers with two crucial options. First of all, it is able to register new collections of cards within its game namespace. This is used to create new collections of cards. To do this, a new collection must be created by uploading both images and metadata information of all cards to IPFS to obtain a content identifier, which is a hash of uploaded data; this will guarantee immutability (Step 2 in Figure 1). Now, the game developer can call the blockchain and register this content identifier (IPFS CID) to the given collection (Step 3). This finalizes all required steps to store data on the blockchain. Following this event, booster packs can be generated off-chain. At this point users have  
Figure 1: Sequence diagram of game registration and creation of a new collection. full capability to view cards and collections and to redeem boosters. The structure of card ids and how they are tied to game and collection are discussed later in this section. A game developer with a registered game and collection acquires the second capability: it can sign digital data representing a random pack of created cards, including a unique number, which ensures each pack can only be redeemed once. Such signed metadata will be put inside of the pack as a QR code and distributed to users. Initial contact with the game will not change from the users' perspective. They can buy the pack as usual. Once they open it, they will see the cards. Then, using their phones, they will be able to scan the QR code contained inside the pack, which will prompt them to create (mint) NFTs representing proof of ownership of the cards they opened. This process is presented in Figure 2. To avoid unnecessary costs, users can decide the cards that require proof and the cards to ignore. To prevent an abuse of the system, the cards will, once ignored, never be redeemable again. Having had their cards added to their collections, users own them fully. They can trade, transfer, view, and destroy their assets to the same extent they would with physical goods. Now, their cards can be simply printed; they can use their own printers or specifically designed processes provided by game developers to increase the quality of the cards. The physical representation does not carry any value besides the material it is made of thought.