## 4 Implementation
### Smart Contract  
ERC-1155, introduced in Ethereum Request for Comment 1155 [34], is a multi-token standard. It combines the qualities of NFTs, creating uniqueness and allowing them to store metadata and fungible tokens, allowing them to be owned by more than one user in more than one copy. After analysing other platforms, Ethereum Virtual Machine was the only one to provide a multi token standard. In other cases, it would be necessary to deploy more than one smart contract, which would not only require more technical knowledge from game developer but also could create issues once the system operator is down, or it would require a dependency on other third-party organizations. As one of the main design goals is for the protocol to be resilient to the system provider being unavailable, this was a crucial requirement. This standard is also widely supported and well-defined, which means that with minimal effort it was able to be adapted to use with  
Figure 3: Components of a token ID. popular platforms such as Opensea and Rarible. It means that users will have easy ways of trading and managing their collections without relying on system operators or game developer-provided solutions. Well defined standard also means that building additional services is relatively simple, which would allow users to maintain full control of their assets even in the case all available currently solutions were unavailable. In addition, the ERC-1155 standard provides many optimizations over the ERC-721 standard to the gas cost of execution, which can be observed in Table 1. The table presents the estimated gas costs of basic operations for the base implementations of ERC-721 and ERC-1155. Gas is a virtual entity used to describe the cost of operation in an Ethereum Virtual Machine. Each operation and each byte of stored data has a constant gas cost assigned, meaning the gas should be constant between different EVM implementations on different chains. This is true assuming the same version of EVM is used [24]. The minting of tokens and transfers is significantly cheaper in the ERC-1155 standard. As a trade-off, the initial deployment is more expensive. However, the difference is returned later. This proves that the advantages of the contract, enabling proper functioning of the protocol, are not incurring additional costs. Using the ERC-1155 standard, all basic actions for the tokens are provided by default. That includes trading, destroying, and viewing card data. The default minting (token creation) functionality was disabled to avoid abuse--as the system was designed to use lazy minting instead. The most important structure in the code is representing random card pack (Listing 1). This is the same structure that will be encoded in the QR code distributed to the user. The structure only contains a minimal amount of fields required for verification. A lack of some data may be observed compared to the amount of data verified in the signature (Listing 2). The reasoning behind this, is that protocol related data--such as blockchain id or contract address--are constant, and once the protocol is deployed, can be treated as known values. Their presence in the verification step is required to prevent abuse. Each card id is represented by 256-bit number, from which some of the card qualities can be derived. Nonce is a 32-bit number, tracked separately for each game and each collection. This will ensure that each QR code can be used to mint cards only once. Finally, a signature will be generated using the private key of a game developer. It is a confirmation of the source of this booster. The process of booster redemption can be described using the following algorithm. * IDs of the game and the collection the booster is tied to are calculated using the ID of the first card in the pack. * The nonce is verified to be unused against the memory of the calculated game and collection.