KLIK PASS
  • KLIK Initial Coin Offering (ICO) Requirements Document
    • UPDATED Instructions for Solidity and Next.js Developers for ICO Page (9/9/2024)
    • Core Functionalities
    • ICO Page Requirements
    • System Architecture
    • Liquidity Plan
    • Middleware Requirements
    • Smart Contract Requirements
    • API Descriptions
  • KLIKcoin Tokenomics Plan
    • Total Supply Breakdown (10 Billion KLIKcoins)
    • Class A vs. Class B KLIKcoins
    • Time-Locked Tokens for Future Sales
    • Funding Rounds and Allocations
    • Liquidity pools
    • Staking Mechanism
    • Vesting Mechanism for Class A KLIKcoins
Powered by GitBook
On this page
  1. KLIK Initial Coin Offering (ICO) Requirements Document

Smart Contract Requirements

6.1 KC Token Contract (ERC-20) - Name KLIKCOIN with suitable ticker on EVM

  • Minting: Mint 1 trillion Crypto KCs for the Seed Round and future rounds.

  • Time-Locked Supply: 75% of the token supply will be time-locked for release over 5 years.

  • Platform Fees: Ensure the 3% platform fee for transactions is applied to all trades involving Crypto KCs.

  • Use the existing smart contracts that were already unit tested. They can found here

MAIN_ERC20_ADDRESS = '0xA56ac1B7972c38e277eF3bac5f94aA60B2Ec467e'

MAIN_MINT721_ADDRESS = '0xf5c502A8c31A210EAB6b7837E7C56d65d3Af2F83'

MAIN_MINT1155_ADDRESS = '0xa8abA6bB110745e079Ad90cbbAF62102c8bA80Fe'

MAIN_MARKETPLACE_ADDRESS = '0xaA503BCFaA5388dAa6649161581332EdaA5e794f'

  • Have independent 3rd party auditor verify the new Token.

6.2 Claim Contract for KLIK ICO

The Claim Contract in Solidity will serve as the backbone for converting In-App KCs to Crypto KCs (ERC-20 tokens). It will securely map existing In-App KC balances to Crypto KCs and handle the process of claiming tokens by eligible users. Below is a detailed expansion of the Claim Contract functionality, covering its design, security measures, and execution logic.


6.2.1 Purpose of the Claim Contract

The Claim Contract is designed to:

  1. Map In-App KC Balances: Each user with a balance of In-App KCs (the in-app currency) will have their balance recorded in a central database.

  2. Enable Secure Claims: Users will interact with the contract to claim their equivalent balance in Crypto KCs based on their In-App KCs.

  3. Transfer Tokens: Once the claim is processed, the contract will securely transfer the corresponding amount of Crypto KCs to the user’s connected Ethereum wallet.


6.2.2 Core Functionalities of the Claim Contract

1. User Balance Mapping (Mapping of In-App KCs to Crypto KCs)

  • Mapping: A Solidity mapping will be created to associate each user's In-App KC balance with their Ethereum wallet address. This mapping will be initialized from a central database that holds users’ in-app balances.

    solidityCopy codemapping(address => uint256) public inAppKCBalances; // In-App KC balance mapping
    mapping(address => uint256) public cryptoKCBalances; // Crypto KC balance mapping
  • Initialization: The data from the In-App KC balance (collected off-chain) will be pre-loaded onto the contract through an initialization function, available only to the contract owner or administrator. This ensures that every eligible user’s balance is recorded correctly before the claim period starts.

    solidityCopy codefunction initializeBalances(address[] memory users, uint256[] memory balances) public onlyOwner {
        require(users.length == balances.length, "Input data mismatch");
        for (uint256 i = 0; i < users.length; i++) {
            inAppKCBalances[users[i]] = balances[i];
        }
    }

2. Token Claim Logic

  • Eligibility Check: When a user interacts with the contract to claim their Crypto KCs, the contract will first check if the user has a non-zero In-App KC balance recorded.

    solidityCopy codefunction claimCryptoKCs() public {
        require(inAppKCBalances[msg.sender] > 0, "No In-App KCs to claim");
        uint256 claimAmount = inAppKCBalances[msg.sender];
        inAppKCBalances[msg.sender] = 0; // Set the balance to 0 after claiming
        cryptoKCBalances[msg.sender] = claimAmount;
        _transferTokens(msg.sender, claimAmount);
    }

3. Token Transfer

  • Transfer Function: Once the claim is processed, the contract will securely transfer the Crypto KCs (equivalent to the user’s In-App KCs) to the user’s Ethereum wallet. This function leverages the ERC-20 token standard to ensure seamless token transfers.

    solidityCopy codefunction _transferTokens(address recipient, uint256 amount) internal {
        require(amount > 0, "Invalid amount");
        require(tokenContract.balanceOf(address(this)) >= amount, "Insufficient contract balance");
        tokenContract.transfer(recipient, amount);
        emit TokenClaimed(recipient, amount);
    }
    • TokenContract: The tokenContract is an instance of the Crypto KCs ERC-20 token contract. The contract will hold a supply of Crypto KCs reserved for claim purposes.

    solidityCopy codeIERC20 public tokenContract; // Reference to the Crypto KC ERC-20 token contract
    • Emit Events: Emitting an event after each claim ensures that there is a record of every token claim on the blockchain, which can be monitored by external services or block explorers.

    solidityCopy codeevent TokenClaimed(address indexed user, uint256 amount);

4. Gas Fee Calculation

  • Real-Time Gas Fee Estimation: The claim contract will estimate the gas fees involved in token transfers to ensure that users are informed of potential costs. This can be integrated with an off-chain oracle that retrieves real-time gas prices.


6.2.3 Security Measures

1. Role-Based Access Control

  • Owner and Admin Functions: Only the contract owner (or a trusted admin) should be able to update users’ balances in the contract. This ensures that only verified users with legitimate balances can claim tokens.

    solidityCopy codemodifier onlyOwner() {
        require(msg.sender == owner, "Caller is not the owner");
        _;
    }

2. Re-Entrancy Protection

  • Non-Re-Entrant Claims: A nonReentrant modifier should be implemented to prevent re-entrancy attacks during the claim process, ensuring that tokens cannot be claimed multiple times in a single transaction.

    solidityCopy codemodifier nonReentrant() {
        require(!locked, "Reentrant call detected");
        locked = true;
        _;
        locked = false;
    }

3. Audited ERC-20 Contract Interaction

  • Audited ERC-20 Integration: The Crypto KC contract should be thoroughly audited by a third party (e.g., Certik, OpenZeppelin) to ensure the integrity of the token issuance and transfer mechanisms.


6.2.4 Process Flow for the Claim Contract

  1. Balance Initialization:

    • The admin initializes the contract with users’ In-App KC balances before the claim process begins.

  2. User Interaction:

    • Users initiate a claim transaction by interacting with the contract through a claimCryptoKCs() function.

  3. Validation & Transfer:

    • The contract checks the user’s eligibility by verifying their In-App KC balance.

    • If valid, the equivalent amount of Crypto KCs is transferred to the user’s wallet.

  4. Gas Fees:

    • The contract estimates the gas fees required and informs the user.

  5. Record-Keeping:

    • An event is emitted to track each successful claim, ensuring transparent record-keeping on the blockchain.


6.2.5 Example Code Snippet

solidityCopy codepragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";

contract KlikClaim {
    address public owner;
    IERC20 public tokenContract;
    bool private locked;

    mapping(address => uint256) public inAppKCBalances;
    mapping(address => uint256) public cryptoKCBalances;

    event TokenClaimed(address indexed user, uint256 amount);

    constructor(address _tokenContract) {
        owner = msg.sender;
        tokenContract = IERC20(_tokenContract);
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Caller is not the owner");
        _;
    }

    modifier nonReentrant() {
        require(!locked, "Reentrant call detected");
        locked = true;
        _;
        locked = false;
    }

    function initializeBalances(address[] memory users, uint256[] memory balances) public onlyOwner {
        require(users.length == balances.length, "Input data mismatch");
        for (uint256 i = 0; i < users.length; i++) {
            inAppKCBalances[users[i]] = balances[i];
        }
    }

    function claimCryptoKCs() public nonReentrant {
        require(inAppKCBalances[msg.sender] > 0, "No In-App KCs to claim");
        uint256 claimAmount = inAppKCBalances[msg.sender];
        inAppKCBalances[msg.sender] = 0;
        cryptoKCBalances[msg.sender] = claimAmount;
        _transferTokens(msg.sender, claimAmount);
    }

    function _transferTokens(address recipient, uint256 amount) internal {
        require(amount > 0, "Invalid amount");
        require(tokenContract.balanceOf(address(this)) >= amount, "Insufficient contract balance");
        tokenContract.transfer(recipient, amount);
        emit TokenClaimed(recipient, amount);
    }
}

This Claim Contract ensures that the conversion process from In-App KCs to Crypto KCs is secure, transparent, and efficient, enabling users to claim their tokens with confidence while maintaining the integrity of the system.

PreviousMiddleware RequirementsNextAPI Descriptions

Last updated 8 months ago