Visit the KGeN website

System Overview

The POG Service comprises the following primary components:

1. Data Lake:

  • Purpose: Stores large volumes of user-related data, including:

    • User’s POG and POX scores

    • Lifetime earnings in K-Cash

  • Technology Stack: AWS S3

2. Repository:

  • Purpose: Fetches user-specific data for POG card generation, including:

    • Clan information

    • Age on the platform

    • Reserved username

    • Country

    • State machine state data

  • Technology Stack: DynamoDB, RDS

3. S3:

  • Purpose:

    • Temporarily stores the user’s uploaded selfie until the avatar is generated.

    • Stores the AI-generated POG avatars.

  • Technology Stack: Amazon S3

4. Segmind (3rd Party Service):

  • Purpose: Facilitates avatar generation using AI.

  • Workflow: Processes the uploaded selfie and character selection to produce a unique avatar image.

5. POG Web3 Service:

  • Purpose: Handles the minting process of the POG card NFT, including:

    • Uploading the rendered POG card to decentralized storage (e.g., Pinata).

    • Encrypting the user’s POX scores.

    • Minting the NFT with attributes like media CID, POX badge levels, reserved username, and encrypted scores.

    • Tracking blockchain data, such as transaction hash, gas fees, and sponsor details.

  • Special Feature: Utilizes APTOS gas sponsor functionality to handle minting costs.

6. SQS (Simple Queue Service):

  • Purpose: Manages asynchronous communication between the POG service and POG Web3 service for NFT minting.

  • Workflow: Ensures reliable and decoupled processing of minting requests.

System Diagram

Technical Specifications

Input Requirements:

  • User Data: Username, clan, age on platform, POG and POX scores, lifetime earnings, platform, game genre, country.

  • Selfie: Uploaded by the user for avatar generation.

  • Avatar Preference: Selected character during the mint process.

Output:

  • POG Card NFT: An NFT containing:

    • Media CID of the POG card.

    • User attributes (e.g., badges, scores, username, etc.).

    • Encrypted POX scores.

POG Aptos Contract

Mainnet: Link

Overview

The POG NFT contract is implemented on the Aptos blockchain, adhering to the Aptos Digital Asset (DA) Standard. It uses the Move programming language to ensure robust functionality and secure management of the token lifecycle. The contract leverages on-chain metadata storage to maintain dynamic NFT attributes and offers a comprehensive suite of features, including controlled minting, dynamic updates, and secure data handling.

Key Features:

  1. Soulbound NFT

    • NFTs are non-transferable and tied to a specific player's wallet address.

    • Implemented using object::disable_ungated_transfer() to restrict token transfers.

  2. Minting and Burning:

    • Controlled minting and burning processes, with role-based access.

    • Admin authorization is required for minting operations.

  3. On-Chain Data Storage:

    • Dynamic attributes like badges and scores are stored directly on-chain using the PropertyMap module.

    • Scores and sensitive data are encrypted for privacy.

  4. Dynamic Token Properties:

    • Attributes like avatar CID and badges can be updated post-minting.

    • Efficient property mutation using property_mutator_ref.

  5. Event-Driven Architecture:

    • Events are emitted for minting, burning, updating, and data retrieval.

    • Key events include NFTMintedToPlayerEvent, PlayerScoreUpdatedEvent, and TokenURIChangedEvent.

Functional Components

1. Minting

  • Method: mint_player_nft

  • Features:

    • Mints NFTs directly to a user’s wallet as soulbound tokens.

    • Parameters include avatar CID, badges, scores, and username.

    • Unique token names are generated using a counter mechanism.

    • Avatar images are fetched from IPFS using the CID.

  • Event Emission: Emits NFTMintedToPlayerEvent with details like token name and wallet address.

2. Updating Attributes

  • Method: update_player_score

  • Features:

    • Updates on-chain attributes such as scores and badges.

    • Requires both user and admin signatures for execution.

  • Event Emission: Emits PlayerScoreUpdatedEvent with token details.

3. Changing Avatar CID

  • Method: change_avatar_cid

  • Features:

    • Updates the CID of the avatar associated with a token.

    • Generates a new token URI by combining the base URI with the CID.

  • Event Emission: Emits TokenURIChangedEvent with updated details.

4. Managing Role-Based Access

  • Admins have exclusive rights to:

    • Mint tokens.

    • Update or remove token attributes.

    • Burn tokens if necessary.

  • Admin roles can be transferred securely via change_admin.

Security Measures

  1. Validation:

    • Enforce supply caps during minting.

    • Validate roles for all sensitive operations.

  2. Encryption:

    • Sensitive data such as scores are encrypted before storage.

  3. Testing:

    • Includes unit and integration tests for minting, updating, and burning logic.

    • Extensive edge case testing on the Aptos testnet.

PreviousThe POG AttributionNextImpact of The POG

Last updated