K Koinara A Peer-to-Peer Collective Inference Network

MINIMUM PROTOCOL / OPEN INFERENCE MARKET

The open network
for collective inference.

Koinara defines only two protocol primitives: Minimum Acceptable Inference (MAI) and Minimum Reward. Everything above that floor, from quality and speed to depth and user preference, belongs to the market.

English Whitepaper Korean Whitepaper Run a Node
Fair launch Ownerless direction Chain-independent theory Multichain node runtime

PROTOCOL FLOOR

Only the minimum is canonical.

Minimum Acceptable Inference

MAI is not a best-answer oracle. It is the minimum line of protocol acceptance, defined in v1 by valid job state, deadline compliance, non-empty response, format pass, and verifier approval.

Minimum Reward

KOIN issuance rewards accepted inference at the protocol floor. Premium rewards stay market-funded and must remain separate from protocol issuance.

Proof of Inference

PoI proves that a submission satisfied the minimum protocol conditions. It does not prove universal truth or market-best quality.

WHITEPAPER PACKAGE

Main paper plus companion appendices.

Main

English Whitepaper

The protocol thesis, figures, MAI, PoI, incentives, and minimal architecture.

Download PDF
Main

Korean Whitepaper

The Korean main paper mirrors the current English release.

Download PDF
Appendix

English Appendices

Deployment profiles, contract mapping, portability notes, and parameter references.

Download PDF
Appendix

Korean Appendices

The appendix package is published separately so the main paper can stay concise.

Download PDF

PUBLIC NODE

Read the protocol here.
Run the node from its own repo.

Koinara-node

Provider, verifier, or both

`Koinara-node` is the standalone public background node for the network. It connects directly to deployed Koinara contracts across supported networks, with no hosted API, no business layer, and no UI dependency. The current runtime can fail over across healthy EVM deployments while keeping Solana in prepared-only scope.

Open Repo Home Test Quickstart
Install

Three-step operator path

git clone https://github.com/sinmb79/Koinara-node.git
cd Koinara-node
npm install
npm run setup
npm run doctor
npm run node
OpenClaw
O
OpenClaw Agent workflow above a local Koinara node 
ollama launch openclaw --model qwen3.5

Use OpenClaw for prompt orchestration and operator workflow, then let Koinara-node handle wallet signing, hash submission, verifier votes, and settlement participation.

OpenClaw on koinara.xyz Node-side guide

SUPPORTED NETWORKS

Deploy chain by chain.
Keep the node ready for more.

EVM Runtime

Worldland

Primary reference deployment path for v1 and the first chain in the rollout plan.

EVM Runtime

Base

Ready in the node runtime as an independent EVM deployment target with health-based participation switching.

EVM Runtime

Ethereum

Supported by the same EVM runtime path so protocol instances can expand without changing node behavior.

EVM Runtime

BNB Smart Chain

Prepared through the shared EVM adapter so the same provider and verifier loop can run there after deployment.

Prepared Only

Solana

Configuration and adapter boundaries are in place, but the runnable Solana deployment and runtime remain future work.

RENDERED FIGURES

Visuals now live in the main body of the paper.

Job lifecycle state machine
Figure 1. Job lifecycle state machine
Main network flow
Figure 2. Main network flow
Layered architecture
Figure 3. Layered architecture
Issuance curve
Figure 4. Issuance curve

NEXT TRACK

Deploy the protocol chain by chain, while the node stays multichain-ready.

Step 1

Worldland first

Worldland remains the first reference deployment path for the v1 contracts, with chain-specific runbooks and deployment artifacts kept outside the protocol repo.

Step 2

Expand across EVM chains

After the Worldland path is stable, Base, Ethereum, and BNB can each host independent Koinara deployments without changing the minimal protocol surface.

Koinara-Worldland
Step 3

Prepare the next adapter

Solana and future non-EVM tracks should land behind explicit chain adapters, not by stretching the current Solidity deployment model beyond its boundary.

Protocol Keep the minimum protocol chain-independent and avoid turning availability into bridge logic.
Deployment Publish separate chain deployments instead of pretending one chain can silently absorb another.
Node Let nodes switch participation targets when preferred EVM networks are unhealthy, without moving existing jobs.