KIP Ecosystem Core Contracts

• KIP Ecosystem Protocol (smart contracts) consist of:

  • KIPManagement Contract:

    • The contract is used as the KIP Ecosystem Governance contract.

    • Manages the Treasury wallet that receives incoming fees.

    • Manages the payment acceptance token used in the Ecosystem.

    • Manages a list of special actors granted special privileges in the Ecosystem.

      • DEFAULT_ADMIN_ROLE:

        • Manages settings in the KIPManagement contract.

        • Has the authority to grant/revoke other roles.

        • Has the authority to set/revoke roles for itself.

        • Has the authority to set Treasury wallet.

        • Has the authority to set payment acceptance token.

      • OPERATOR_ROLE:

        • Has the authority to perform special tasks, such as managing contract settings.

      • MINTER_ROLE:

        • Has the authority to mint NFT items (e.g., KIP Identification).

  • KIPIdentification contract:

    • The contract is used to manage identities in the KIP Ecosystem.

    • Currently, there are three types of users:

      • App Owner (e.g., idType = 1)

      • Model Owner (e.g., idType = 2)

      • Dataset Owner (e.g., idType = 3)

    • Each identity is represented by an NFT using the ERC-721 standard.

    • Identities are transferable and tradable.

    • The contract uses ERC721URIStorage, implemented by OpenZeppelin, which offers:

      • Each tokenId can have its own custom tokenURI that links to its metadata.

      • The owner can easily update the URL as needed.

  • KIPRegistration contract:

    • The contract is used to manage identification registration.

    • Assigned the MINTER_ROLE so it can generate Identity NFTs.

    • Currently, the contract manages three types of registration:

      • App Register: mintApp() function

      • Model Register: mintModel() function

      • Dataset Register: mintData() function

  • KIPService contract:

    • The contract is used to manage payment-related features in the Ecosystem.

    • As the User:

      • Call payment() to make a payment for one appId.

    • As the App Owner | Model Owner | Dataset Owner:

      • Set/Update a listing price for their items.

      • Set/Update a payment pool that will receive accumulated revenues generated by their items.

      • The payment pool could either be:

        • An Externally Owned Account (EOA) if the owner doesn't need to share a profit.

        • A contract (e.g., Multisig Wallet or Payment Splitter) if the owner wants to share the profit with a limited number of shareholders.

        • A special contract, implemented and deployed by the owner, that handles effective profit-sharing among a large list of shareholders.

        • It's updatable by the tokenId's owner.

    • Accumulated revenues per tokenId are claimable by calling the claimRevenue() function.

    • The commission fee will be accumulated and stored in the contract (accumulatedFee).

      • The accumulatedFee is claimable by calling claimFee() function