KMCoin Project Draft

Last updated: August 19, 2026

KMCoin Working Protocol Draft

Abstract

KMCoin is an experimental layer-1 proof-of-game network that rewards player activity, processes chat-based transactions, and bridges eligible rewards to KMC on Solana. This draft describes the current network model, including signed peer messages, shared queue majority, Steam API reward verification, hosted transaction intake, and active-development bridge assumptions.

Block producers create auditable reward candidates. Transaction hosts collect player messages. Validators verify peer identity, propagation evidence, Steam activity where applicable, transaction structure, and ledger consensus before deciding what enters the ledger.

1. Purpose

KMCoin is built around a simple idea: players should be able to earn and transact while playing games normally. Instead of forcing custom game mechanics or developer-controlled economies, KMCoin observes externally available game activity and records rewards in its own public ledger.

The network is organized around three jobs:

  • Block producers create candidate reward blocks from game activity.
  • Transaction hosts collect player public key updates, transfers, and bridge requests.
  • Validators verify peer messages, reach queue majority, process winners, and maintain the ledger.

One operator can run all three roles, but the roles are independent. This lets KMCoin use hosted servers for transaction flow while using auditable data sources for reward production.

2. Current Network Model

2.1 Peer Transport

KMCoin peer-to-peer traffic uses a direct TCP protocol. Each peer message is a bounded JSON envelope containing a message type, peer identity, timestamp, nonce, payload, and signature. The receiver verifies the signature against the trusted public key for the claimed peer before accepting the message.

This protects node-to-node traffic without requiring a shared secret between every peer. If one private key is compromised, only that peer identity is compromised. Other peers can remove or replace the compromised public key through configured validator rules today, and through ledger-based governance as that path is finalized.

2.2 Transport Safety

The TCP listener rejects malformed, unsigned, replayed, oversized, or unknown-peer messages before writing data into KMCoin processing files. The implementation includes configurable limits for:

  • maximum message size
  • maximum total connections
  • maximum connections per IP
  • messages per IP per minute
  • invalid-message counters
  • temporary blacklist persistence
  • timestamp window and nonce replay protection

The design does not assume peer traffic is private. Server blocks and consensus snapshots are public network data. The important security property is authenticity: validators need to know which trusted peer signed the message and whether the message is fresh.

2.3 Shared Queue Majority

Every server block is first written into a local queue. Peers share their queue snapshots when they share server blocks. Each validator stores received queue snapshots in a per-peer directory and waits for a fixed processing window before promotion.

A candidate is promoted only when the same block appears in a majority of the active validator set. The intended production model derives that set from KMCoin validator addition and removal transactions. During the current rollout, the active validator set may be configured directly. Missing snapshots do not reduce the required threshold.

majority = floor(expectedValidators / 2) + 1

When a block fails to reach majority after the queue window, it is removed locally as stale non-majority data. When it reaches majority, it is appended to the local network processing file and removed from local and peer queue snapshots.

3. Proof Of Game

3.1 Hosted Game Servers

Minecraft and Rust support player-name transaction paths through game chat. These integrations read local server logs, build KMCoin-compatible transaction lines, and allow players to send public key updates, transfers, and bridge requests while playing normally.

Hosted servers are transaction intake layers. They can run their own gameplay rules, communities, and smart-contract ideas while providing KMCoin-compatible chat output for validators to process.

3.2 Steam API Blocks

Steam is the first auditable API block producer model. A Steam source account queries its Steam friends list, sorts SteamID64 values numerically, hashes the ordered list, and emits a Phase I Steam block. Steam blocks use numeric fields so they remain compatible with the existing KMCoin block parser and network queue.

2000000-2099999.friendListHashA.friendListHashB.friendListHashC.friendListHashD.sourceSteamID.winnerSteamID

The source SteamID identifies the account whose friend list was queried. The winner SteamID field begins as the producer's initial candidate; validators may later compute a different final winner during salted verification. The intended eligible set is the sorted Steam friend list, with optional inclusion of the source SteamID64.

Steam block production is deterministic by design. Every validator can calculate the same result from the same public inputs. The source producer can also calculate that result, but cannot secretly alter the input used to obtain it. If the producer changes the friend list, the commitment changes; if the producer submits a false commitment, verification fails. Determinism makes the result auditable without giving the producer invisible control over the outcome.

3.3 Phase I And Phase II Verification

Steam blocks run through two phases. Phase I is a normal KMCoin network candidate. Before network winner selection, validators salt the Steam block with the most recent network consensus hash. This prevents the source account from crafting a block using known blockchain data to force the outcome.

If the salted Phase I Steam block wins normal KMCoin network selection, validators queue it for API verification instead of finalizing it immediately. A separate verifier queries Steam, verifies the friend-list hash, deterministically recalculates the salted winner, and checks whether that winner is currently in a Steam game. If the Steam API does not return enough data within the timeout window or the player is not in a game, the candidate is discarded.

A future verifier can minimize Steam API usage by checking eligible SteamID64 values in batches instead of one account at a time. The same salted ordering can also provide a deterministic fallback order: if the first selected SteamID64 is not currently in a game, validators can check the next candidate from the same ordering and record which candidate index was used. Any temporary API discrepancy or visibility difference must still pass normal queue majority as a Phase II block, so inconsistent verifier results are filtered out by validator agreement rather than accepted unilaterally.

A verified Steam winner is rewritten as a Phase II Steam block with the actual winning SteamID64 and returned to the normal network queue. Phase II blocks are then shared and majority-proven like other blocks before final ledger processing.

3.4 SteamID64 Player Identity

Steam players are represented by their 17-digit SteamID64 instead of a server player name. This gives the network a stable public identity that validators can query. Hosted server log processing rejects player names that appear to be SteamID64 values so hosted servers cannot accidentally mint duplicate identities for Steam players.

4. Transactions

4.1 Player Public Keys

Each player record stores a player identity, first block mined, balance, transaction number, block history, and public key. For hosted game servers the player identity is a game-visible player name. For Steam flow the player identity is the SteamID64.

A player's public key is derived from deterministic inputs controlled by the player: the player's first block mined and a password or secret chosen by the player. The website can perform this derivation locally in the browser for convenience, but it is not required. A player can independently calculate the same public key with their own tool and submit the resulting public key update transaction through a supported transaction path.

Validators do not need the player's password or secret. They only need the public key recorded in player state and later transaction-solving hashes that prove the sender knew the same secret-derived key material when the transaction was created.

publicKey = sha256^2002(firstBlockMined + passwordHash)

SteamID64 identity gives the network a clean path for future public key replacement. A Steam player could publish a replacement-key transaction through a supported transaction host, while future validator logic uses the public Steam profile verification field to confirm that the request belongs to the SteamID64 being updated. This would allow key changes without trusting the transaction host as the identity authority.

4.2 Chat-Based Transactions

KMCoin transactions are sent through supported transaction chats. Minecraft and Rust support player-name transaction paths. Unturned is used for SteamID64 public key updates and transactions, allowing Steam players to transact through a SteamID64-specific chat host.

Transaction hosts do not need to produce blocks. Their job is to provide a game or chat environment where the network can read player messages, parse valid KMCoin transaction strings, and include those transactions in the normal block pipeline.

For SteamID64 players, the transaction intake server does not determine identity. The intake host only relays transaction text from a SteamID64-specific chat path. The intended validator path is to independently query the Steam profile tied to the SteamID64 and compare a public, player-controlled profile field against submitted transaction data. Once finalized, this allows a single Steam API lookup to confirm whether the transaction belongs to that Steam account, reducing the transaction host to a relay and limiting its ability to spoof or front-run Steam player identity.

4.3 Front-Running Controls

The original KMCoin transaction reduction mechanism remains available as a defensive layer for duplicate transaction hashes. If two conflicting transactions reuse the same transaction-solving hash, validators can reduce or reject the disputed data instead of allowing both paths to update player state.

SteamID64 identity improves this further. For Steam players, future validator logic can use the Steam identity and that public profile verification field as an additional anchor before accepting or reducing disputed transaction data. This gives the network a path to verify the Steam account behind the transaction rather than trusting the transaction host as the identity authority.

5. Ledger And Bridge

5.1 Ledger Files

KMCoin stores the active ledger, player information, and historical ledger hashes in local files. When a current ledger reaches its configured maximum size, it is archived, hashed, and represented by the resulting hash in the permanent ledger hash file.

Validators compute consensus by hashing the relevant ledger files and comparing the combined result.

consensus = sha256(ledgerHashesHash + playerInfoHash + currentLedgerHash)

5.2 KMC Bridge

KMCoin can be bridged from the layer-1 game ledger to KMC on Solana. A valid bridge transaction burns the layer-1 amount, creates a Solana claim path tied to the transaction hash, and lets the player claim KMC through the website.

  • KMCoin is burned on the game ledger.
  • A claim account is created on Solana using the layer-1 transaction hash.
  • The player submits the solving hash to claim KMC.
  • Replay protection prevents the same bridge transaction from being claimed twice.

5.3 Bridge Trust Model

The KMC bridge is an active-development bridge implementation. During this phase, the bridge program and Solana-side KMC distribution path include developer/admin trust assumptions, and a portion of the KMC token supply is held in developer-controlled wallets for liquidity, bridge operation, development, and future distribution.

The planned bridge design uses an immutable Solana program with a dedicated vault account, explicit claim rules, replay protection, and finality requirements tied to KMCoin ledger state. Once deployed and audited, valid bridge claims should not depend on developer discretion.

Until that migration is complete, users should understand that KMC on Solana and the KMCoin bridge carry developer/admin trust risk in addition to normal smart contract, market, and network risk.

6. Consensus Processing

6.1 Network Winner Selection

Once majority-proven queue entries are promoted into network processing, KMCoin uses deterministic winner selection to decide which candidate becomes the next ledger block. The active implementation compares the oldest candidates in order, hashes their block content, and applies modulo against the number of active block producers in the network group. This keeps expected network block time near the producer block interval while preserving deterministic selection.

modHash = sha256(candidateA + candidateB)
winner = sumHex(modHash) mod activeProducerCount

Steam Phase I candidates are salted before this calculation. Steam Phase II candidates have already passed Phase I selection and Steam API verification, then require queue majority before final processing.

6.2 Timestamps

Peer messages carry two timestamps in the queue line. The first timestamp is the source peer's claimed send time. The second timestamp is the receiving validator's local receive time. KMCoin uses the first timestamp for deterministic ordering and age gates; the second is retained for observation and diagnostics.

The majority queue creates an implied network time check without requiring machine-level clock sync. A candidate must appear in a majority of signed peer snapshots inside the same processing window. If a source tries to make a block appear artificially old, validators can compare the claimed send time against their local receive time and the majority snapshot timing. Large or inconsistent latency gaps become visible before the block is promoted.

Peers normally share queue state once per block interval. If no local block is produced, a queue-only update is sent instead. This gives validators a regular timing signal: they can compare local receive timestamps across queue updates to detect peers that stop sending blocks or snapshots near the expected interval.

Steam Phase II blocks are requeued with deterministic timestamp adjustment from the original Phase I source timestamp. This preserves ordering while giving the verified block enough time to federate through queue snapshots before majority processing.

6.3 Bounded State Repair

Validators share queue snapshots so each node can see what every signed peer has queued. This makes missed propagation visible and gives validators enough local evidence to promote only majority-proven blocks.

Queue snapshots also act as a passive liveness signal. A peer that signs and shares queue state proves recent participation without requiring a separate heartbeat protocol. Validators can compare which peers are actively signing queue state, which snapshots contain matching candidates, and which peers are missing from majority formation.

The queue snapshot model is intentionally small. In the current 7-validator group model, a maximum-load one-minute queue with a roughly 300-byte block and up to 100 transactions per block producer at roughly 125 bytes each is about 12.8 KB per validator snapshot. Even if every validator shares a full maximum-load queue snapshot, the total comparison data set is under 100 KB per processing window before normal cleanup. Most queues are smaller because many block intervals contain few or no transactions.

The planned repair path is intentionally bounded. A validator that detects a consensus mismatch or falls behind should be able to pause local finalization, keep incoming transactions queued, and request a signed, rate-limited state update from a configured peer. The response should contain only the minimum state required to catch up: player state, archived ledger hashes, and a bounded tail of the current ledger. This keeps repair traffic bounded because historical ledger files do not need to be resent once their hashes are already agreed.

Short validator outages are inexpensive to repair. In a quiet interval with no transactions, a missed block adds only roughly one block line to the current ledger, often a few hundred bytes per minute. A 10-minute disconnect may require only a few kilobytes of current-ledger tail data, while a 100-minute disconnect may still be measured in tens of kilobytes before transaction-heavy traffic is considered. New player state entries are also small, typically a few hundred bytes each. The repair path is therefore designed around bounded recent state, not full historical ledger transfer.

7. Governance And Expansion

7.1 Validator Additions

Validator additions are intended to be represented on-chain through KMCoin transactions. A validator addition can publish a URL or network identity, a public key, and the block timestamp where the validator was added. Every node can parse the same list from the ledger and derive the same ordering.

If a validator private key is compromised, the operator can be removed or temporarily blacklisted, then later submit a new public key through the same transaction-based process. A compromised key remains valid until that removal or replacement is processed, so public key governance and validator removal rules are part of the validator security model. The public key is the peer identity anchor; the private key never needs to be shared with other validators.

7.2 Producers, Validators, And Hosts

The network is designed to add independent block producers, validators, and transaction hosts without requiring each participant to run every role. A Steam API source can produce auditable reward candidates. A hosted Unturned server can receive SteamID64 transactions. A validator can verify TCP signatures, queue majority, Steam API verification, and ledger consensus.

7.3 Scaling Direction

Validators can be sorted deterministically from on-chain addition transactions. Groups can scale as a single larger validator set or split recursively into bounded subgroups when peer counts become too large for every validator to track directly.

8. Security Considerations

8.1 Peer Identity

Signed TCP envelopes prove that a message came from a peer holding the private key associated with a trusted public key. A bad signature cannot be used to punish the claimed peer identity because an attacker can lie about the claimed peer. Bad signatures can be counted against the source IP and temporarily blacklisted when repeated.

8.2 API Trust

Steam API verification does not make Steam a KMCoin validator. Steam is a public data source that KMCoin validators query independently. If Steam does not expose enough data for a candidate, the candidate fails. If an API source cannot be independently queried by validators, it should not be trusted for block production.

8.3 Remaining Risks

  • Public TCP listeners must spend some resources rejecting bad traffic; KMCoin limits this with message size caps, timeouts, rate limits, and temporary blacklists.
  • Public validator onboarding depends on KMCoin transactions that add validator identities, publish public keys, and remove validators consistently across the network.
  • Bridge claims need finality rules so Solana settlement follows sufficiently settled KMCoin state.
  • The active-development bridge includes developer/admin trust assumptions until the planned immutable vault model is deployed and audited.
  • Steam rewards require Steam to expose enough public profile and game-presence data for validators to verify activity; private or unavailable presence data may make a player ineligible for Steam reward blocks.

9. Public Disclosures

9.1 Current Operating Phase

KMCoin is operated as a curated validator network while the protocol, bridge, Steam verification, planned state repair, and validator onboarding rules are tested. Validator additions are not fully permissionless during this phase.

This operating model is intentional. It allows unsafe additions to be rejected, live behavior to be monitored, and the protocol to be hardened before broader validator participation. The tradeoff is that early network operation includes coordination and developer/operator trust assumptions.

9.2 Treasury And Developer Wallets

A portion of Solana-side KMC supply is held in developer-controlled wallets for liquidity, bridge operation, development, infrastructure, testing, future distribution, and ecosystem support. These wallets are part of the active-development trust model until bridge and treasury controls are further decentralized.

Public treasury, bridge, liquidity, and developer wallet addresses are disclosed on the website with live KMC balance lookup where available. Disclosure identifies known developer-controlled wallets without implying multisig control, lockup, escrow, audit, or removal of market, liquidity, or bridge risk.

9.3 Experimental Status

KMCoin is experimental software. It should not be treated as a finished, fully permissionless, or institutionally audited blockchain network. The protocol is actively changing as live testing reveals better approaches to Steam/API verification, peer transport, state repair, validator admission, and bridge finality.

The existence of a Solana market for KMC does not mean the KMCoin layer-1 network, bridge, or validator admission process is complete. Users should assume technical, market, bridge, liquidity, infrastructure, third-party API, and regulatory risk.

10. Roadmap

  • Run Steam Phase I and Phase II blocks across the live validator set.
  • Finalize KMCoin transactions for validator addition, validator removal, and public key replacement.
  • Finalize signed, rate-limited validator resync for nodes that fall behind.
  • Add more API-backed producer sources where player identity and activity can be independently checked.
  • Publish practical operating rules for producers, validators, transaction hosts, and code reviewers.

11. Conclusion

KMCoin is a verifiable proof-of-game network using public-key peer identity, shared queue majority, Steam API verification, hosted transaction intake, and deterministic ledger consensus.

The rule is straightforward: if validators can independently confirm the player, source, activity, and transaction path, KMCoin can use that game data. Hosted servers support transactions and communities, while auditable producers provide reward blocks for a larger proof-of-game network.

12. References

[1] S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System," https://bitcoin.org/bitcoin.pdf, 2008.

[2] Valve Corporation, Steam Web API documentation.