Skip to main content

KGeN (Kratos Gamer Network)

KGeN (KGEN) — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

KGeN (Kratos Gamer Network) — an AI/Other | Gaming | Infra project about verified distribution and reputation: a “POGE reputation engine” and an oracle network for turning behaviour/actions into “verifiable reputation”. The website also describes a product, KAI Training & Evaluation — a network of verified experts for data collection/labeling and model evaluation for AI products. Token: KGEN (BEP‑20 on BNB Smart Chain).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: a reputation and distribution platform for gaming/digital ecosystems: “provable reputation” + participation/validation mechanics via an oracle network and keys.
  • Who it’s for: gaming communities/platforms, publishers/partners, network participants (keyholders/oracles), users of KGeN products.
  • Why onchain/token: the token and onchain mechanics are used for participation in the network (keys/validation/rewards/governance rights) and for verifiable accounting/qualification within the “reputation economy”.
  • What you can actually touch (Tier‑1): public product pages (including the Oracle Network) and the GitBook documentation on the oracle network and its roles.

How it works (very briefly)

  1. The user/participant does: uses KGeN products (for example, participates in the reputation system) and/or buys Genesis Keys with the KGEN token.
  2. The system does: Oracles aggregate/validate actions and translate them into reputation scoring; keyholders delegate keys, participate in governing the logic/disputes and receive rewards (as described on the product page and in the GitBook).
  3. The user gets: a reputation profile/score and access to the network’s mechanics (validation, rewards, qualification in programs).
  4. Where the blockchain is: Tier‑1 claims “on-chain behaviour → verifiable reputation” and participation in onchain consensus/governance; the onchain fact of the KGEN token (contract, supply) is verifiable via BscScan.
  5. Token role: KGEN is used for participation (buying keys), rewards and the claimed governance rights of keyholders/oracles.

Quick links: AI thesis fit

Project passport

Field Value
Project name KGeN (Kratos Gamer Network)
Also known as (aliases) KGEN | KGeN Foundation
Logo (logo) ../assets/42_kgen_logo.svg
Token symbol (ticker) KGEN
Category AI/Other | Gaming | Infra
Primary chain (chain) BNB Smart Chain
Type EVM
Network status mainnet
Consensus (consensus) PoSA (BNB Smart Chain; 21 validators)
Launch date (launch_date) —
Project status (status) active
Token (standard) BEP-20
Token contract 0xf3d5b4c34ed623478cc5141861776e6cf7ae3a1e
Token model (token_type) utility (payments + staking + governance)
Max supply 83,726,711.036364 KGEN (max total supply)
Issuance fixed cap
Tokenomics (tokenomics, brief) keys/validation/rewards and claimed governance rights for keyholders/oracles; “enhance token utility” in the roadmap.
Governance keyholders/oracles governance (described)
Admins/keys pausable + roles (AccessControl), blacklist; owner/roles (see verified contract)
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) AI data labeling + model evaluation (human experts)
Use‑case (use_case) verifiable reputation + distribution protocol
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 1 / onchain_score 3 / token_score 3 / evidence_score 2
Last verified 2026-02-11

General project overview

KGeN positions itself as a “Verified Distribution Protocol” and a reputation engine for digital/gaming ecosystems. The Tier‑1 description highlights:

  • POGE reputation engine and the idea of behaviour‑based “verifiable reputation”;
  • Oracle Network and Keyholders/Genesis Keys as roles that provide validation, consensus, governance of the scoring logic and qualification criteria (for example, for airdrops);
  • a product line (for example, Verified UA/Retention Protocol) and a separate direction, KAI Training & Evaluation — working with data/model evaluation for AI products through a network of verified experts.

Features/modules

  • KGeN Oracle (described): a “decentralized validator network” for protecting reputation integrity and onchain consensus (67% threshold) + dispute resolution.
  • Genesis Keys / Keyholders: participation and delegation of keys to oracle operators; governance rights and passive rewards are claimed.
  • KAI Training & Evaluation (described): a network of experts for data collection/labeling and model evaluation for AI products (positioned as a B2B service).
  • Verified UA / Retention Protocol / KStore: product modules for distribution/retention and a rewards storefront.

Typical scenarios

  • Scenario 1 (network participant): buys Genesis Keys with KGEN → delegates keys to an oracle operator → receives rewards.
  • Scenario 2 (oracle operator): aggregates/validates behaviour and scoring → participates in onchain consensus and dispute resolution → receives KGEN rewards.
  • Scenario 3 (AI client): uses KAI Training & Evaluation for data collection/labeling and evaluation of model responses/quality (within the offchain platform/contracts).

Getting started (wallet/network)

  • What you need: an EVM wallet; if necessary — the KGEN token (if the specific product flow requires the token).
  • Network/chain: BNB Smart Chain (token contract on BscScan).
  • Fees: BNB Smart Chain gas for onchain operations; additional fees depend on the specific product/flow.

Architecture/tech (non‑AI)

  • Components: the KGEN token contract (verified), the oracle network (operators), keys/delegation, offchain product services (UA/retention/KAI).
  • Participant roles: keyholders, oracles/validators, consensus coordinators, product users.
  • Where logic runs: the token and onchain accounting — on BNB Smart Chain; part of the product logic and data collection — offchain (per the product descriptions).
  • Dependencies: BNB Smart Chain + the infrastructure of oracle operators, KGeN web products.

Token/economics (expanded, no forecasts)

  • Token utility: participation in the network (buying Genesis Keys) and rewards; the roadmap claims “enhance token utility” and a growing role of the token in KGeN Play / Gaming Oracle Network.
  • Protocol necessity drivers: the Oracle product (Tier‑1) and the GitBook on the oracle network + the BscScan token page.
  • Who pays fees: users/operators in onchain operations (gas), participants buying keys/participating in the mechanics.
  • Where fees go: — (not established from the extracted Tier‑1).
  • Issuance/burn: max total supply on BscScan; the further issuance model was not extracted as Tier‑1 within this card.
  • Security/incentive mechanisms: rewards for participation; governance rights for keyholders; dispute resolution (per the oracle network description).
  • Distribution/vesting: the KGeN Foundation documentation describes backloaded vesting over 4 years (10%/20%/30%/40% unlock after Y1..Y4); at the same time, the total supply (1B) in this documentation conflicts with the onchain max total supply of the KGEN BEP‑20 contract on BscScan, so we record this as a CONFLICT and do not carry the numbers into the passport.
  • Treasury: — (not established).

Governance

  • Who makes decisions: keyholders/oracles (claimed: governance led by keyholders; governance rights for keyholders).
  • How protocol parameters change: via consensus/governance of the scoring logic and dispute resolution (Tier‑1 description).
  • Where decisions are discussed/made: — (not established).
  • Keys/multisig: — (not extracted).

Security and incidents

  • Audits: — (no Tier‑1 confirmation found).
  • Bug bounty: —.
  • Incidents: — (not established).
  • Threat model: centralization of individual components (product services); risks of role/pause/blacklist management in the token contract; correctness of oracle validation and dispute resolution.

Project status and timeline

  • Current status: the KGEN token is active on BNB Smart Chain; product modules and documentation are public.
  • Key releases/milestones: — (not established per Tier‑1).
  • Roadmap: Future Roadmap in the GitBook (Tier‑1).

Ecosystem/integrations

  • Integrations: BNB Smart Chain (BEP‑20); GitBook docs; smart contract repository.
  • Partners: — (not extracted per Tier‑1).
  • Where it’s actually used: the KGeN reputation/distribution stack and the oracle network (per the product description).

AI component of the project

  • What is real AI here? The official website describes the KAI Training & Evaluation product for AI products (data collection/labeling, human response generation, model evaluation). This is an AI‑relevant service, but Tier‑1 does not show the project’s “own” model or model quality metrics.
  • What is truly onchain? The KGEN token (BEP‑20, contract on BNB Smart Chain) and the described oracle network, which claims onchain consensus/governance of the scoring logic and “on-chain behaviour → verifiable reputation”.
  • Why is a token needed? The token is used for participation (Genesis Keys), rewards and the claimed governance rights of keyholders/oracles.
  • Red flags (based on the information found): AI‑washing (AI is mentioned via a B2B service, but without metrics/versions of an “AI core”); onchain‑washing (part of the product modules is obviously offchain); token‑washing (it must be checked that the token’s utility is actually required in key flows, not only in marketing).

DecAI Fit component summary

  • DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality low 1
Onchain necessity high 3
Token necessity high 3
Evidence Tier‑1 present 2
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 1
  • Claim (one line): the official KGeN website describes an AI‑relevant product, KAI Training & Evaluation (data/labeling/model evaluation), as a direction/offering.
  • Evidence: Tier‑1 — https://kgen.io/products
  • Why sufficient / why not (one line): this confirms an AI direction, but does not prove the existence of the project’s own AI model/metrics.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): the project’s own AI component (model/inference) is not confirmed by Tier‑1.
  • Evidence: Tier‑1 — https://kgen.io/products
  • Why sufficient / why not (one line): an AI‑relevant service is described (human experts for data/evaluation), but not an “AI engine” with a description of the project’s model.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): no reproducible AI demos/tutorials (Tier‑1) for the KAI direction were found in the reviewed Tier‑1 sources.
  • Evidence: Tier‑1 — https://kgen.io/products
  • Why sufficient / why not (one line): there are product descriptions and a “request a demo”, but this is not a public demo/guide.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://kgen.io/products
  • Why sufficient / why not (one line): Tier‑1 contains no quantitative quality metrics for the project’s AI model/inference.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 0
  • Claim (one line): a technical description of the project’s AI core/model versions was not found in the extracted Tier‑1.
  • Evidence: Tier‑1 — https://kgen.io/products
  • Why sufficient / why not (one line): there is a description of tasks/processes (data labeling/evaluation), but without the architecture/versions of the project’s model.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: BNB Smart Chain
  • Addresses/identifiers: token KGEN (BEP‑20): 0xf3d5b4c34ed623478cc5141861776e6cf7ae3a1e
  • Evidence: Tier‑1 — https://bscscan.com/token/0xf3d5b4c34ed623478cc5141861776e6cf7ae3a1e
  • Why sufficient / why not (one line): the onchain facts of the token/contract and max total supply are verifiable.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: the oracle network claims onchain consensus/governance of the scoring logic, dispute resolution and qualification criteria (for example, airdrops).
  • Evidence: Tier‑1 — https://kgen.io/products/oracle, https://kgen.gitbook.io/kgen/kratos-oracle-network/oracles
  • Why sufficient / why not (one line): Tier‑1 describes onchain consensus and governed logic, not just “there is a token”.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without onchain consensus and verifiable accounting, the “verifiable reputation economy” loses its claimed trustless component (disputes/qualification/scoring logic).
  • Evidence: Tier‑1 — https://kgen.io/products/oracle, https://kgen.gitbook.io/kgen/kratos-oracle-network/oracles
  • Why sufficient / why not (one line): Tier‑1 links reputation scoring and its integrity to onchain validation/consensus.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, KGEN (BEP‑20 on BNB Smart Chain).
  • Evidence: Tier‑1 — https://bscscan.com/token/0xf3d5b4c34ed623478cc5141861776e6cf7ae3a1e
  • Why sufficient / why not (one line): the onchain fact of the token/contract is verifiable.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): the KGEN token is used for participation in the network via the purchase of Genesis Keys (as described on the Oracle product page).
  • Evidence: Tier‑1 — https://kgen.io/products/oracle
  • Why sufficient / why not (one line): Tier‑1 directly links “acquire KGEN tokens and buy cryptographic keys”.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 1
  • Claim (one line): rewards in KGEN for participation in reputation validation/delegation (oracle/keyholders).
  • Evidence: Tier‑1 — https://kgen.io/products/oracle
  • Why sufficient / why not (one line): Tier‑1 describes “Earn KGEN tokens” for oracles and keyholders.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): keyholders (owners of keys acquired with KGEN) are claimed to lead the governance of the reputation system; governance rights are mentioned on the product page.
  • Evidence: Tier‑1 — https://kgen.gitbook.io/kgen/kratos-oracle-network/oracles, https://kgen.io/products/oracle
  • Why sufficient / why not (one line): Tier‑1 explicitly speaks of governance led by keyholders and governance rights for keyholders.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the replaceability of the token (for example, with USDC) is not established per Tier‑1; we do not draw strong conclusions.
  • Evidence: Tier‑1 — https://kgenfoundation.gitbook.io/docs.kgenfoundation.com/about/future-roadmap
  • Why sufficient / why not (one line): Tier‑1 describes utility/decentralization, but does not compare with alternatives.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://bscscan.com/token/0xf3d5b4c34ed623478cc5141861776e6cf7ae3a1e Onchain facts of the KGEN token: contract, max total supply, verified source (roles/pause/blacklist).
Tier‑1 https://kgen.io/products/oracle Oracle network: oracles/keyholders roles, onchain consensus (67%), dispute resolution, “buy keys with KGEN”, rewards/gov rights.
Tier‑1 https://kgen.gitbook.io/kgen/kratos-oracle-network/oracles Definition of the oracle network and governance (keyholders + Genesis Keys) as a Tier‑1 description of the system.
Tier‑1 https://kgen.io/products Official description of the products, including KAI Training & Evaluation (an AI‑relevant direction/service).
Tier‑1 https://kgenfoundation.gitbook.io/docs.kgenfoundation.com/about/future-roadmap Roadmap: “enhance token utility”, decentralization, the role of the $KGEN token.
Tier‑1 https://kgenfoundation.gitbook.io/docs.kgenfoundation.com/tokenomics/usdkgen Tier‑1: $KGEN is described as the ecosystem’s governance + utility token (KGeN Foundation docs).
Tier‑1 https://kgenfoundation.gitbook.io/docs.kgenfoundation.com/tokenomics/usdkgen/usdkgen-allocation-and-unlock-schedule Tier‑1: backloaded vesting over 4 years (10%/20%/30%/40% after Y1..Y4) + total supply 1B (CONFLICT with the onchain max total supply on BscScan for the KGEN contract).
Tier‑1 https://github.com/kgen-protocol/smartcontracts/tree/main/KGeN-Token Official smart contract/releases repository (development context).
Tier‑2 https://coinmarketcap.com/currencies/kgen/ Profile/context (not proof).
Tier‑3 — —

No comments to display

Back to top