How it works

A session has four steps: discovery, connection, inference and settlement. No step is operated by GenKaKu Labs.

1. Discovery

A worker registers in WorkerRegistry with:

• a peer ID digest — keccak256("genkaku.peer.v0:" + peerId), binding its libp2p identity to its wallet,
• a policy hash — a bytes32 commitment the worker pins at registration,
• an optional locator — a multiaddr hint so a user can dial it.

The registry exposes a public count() and isActive(address). Plugins read them through a public RPC; there is no directory API to trust.

Locators are optional. A worker publishes its public address only when the operator explicitly turns publishAddress on, and a published locator is permanent once it is on-chain.

The policy hash is a commitment, not a description of the model. What a worker actually offers is published separately on its offer board (/genkaku/offers/0), which lists model name, price and Ollama capabilities.

2. Connection

A user plugin opens a libp2p connection to the worker's peer ID. The hello exchange (/genkaku/hello/0) pins:

• the peer ID (must match the registry entry),
• the worker's wallet address, proven by a signature rather than claimed,
• the hourly quote and billing mode.

If the two peers can reach each other directly — same LAN, a public IPv4, a global IPv6 — tokens travel straight between them. If they cannot, the session runs through the public seed relay, which is reachable at staging.genkaku.app/seed.

The relay forwards encrypted libp2p traffic. It cannot read prompts or output, but its operator can see connection metadata: peer addresses, timing and volume. Treat a relayed session as private in content, not in who is talking to whom.

There is no NAT hole punching (no DCUtR) in this build. Either the peers are directly dialable or the relay carries the session.

3. Inference

The worker runs the model locally with Ollama and streams tokens back over the same connection. The marketplace never sees the prompt; the worker operator does.

A zero-price offer skips the chain entirely and is served for free.

4. Settlement

Paid sessions use an hourly quote with started-minute accrual:

• the worker advertises a price per hour,
• each started minute counts as one minute,
• a two-minute job pays two minutes, not one hour.

For a paid model the user opens an escrow in JobEscrow before the first token, which is one chain transaction. When the session ends:

1. the worker signs a receipt over the session ID, spend and a receipt hash;
2. settle() verifies that signature and releases the spend;
3. 99% goes to the worker, 1% to the treasury;
4. any unspent remainder returns to the user.

Settlement is a second chain transaction, so a paid session costs the user two transactions in total: open escrow, then settle. Gas is paid by whoever sends each transaction.

A worker accumulates settled income in the contract and can claim() it at any time; the claim is paid to the worker's wallet.

What replaces the orchestrator

Old model	GenKaKu
Server assigns jobs	User picks a worker from the contract
Server stores prompts	Direct peer connection
Server meters usage	Started-minute accrual, signed receipt
Server pays out	Escrow released on-chain

The trust assumptions are smaller because there is less in the middle. They are not zero: you still trust the worker with the prompt, the relay with metadata if your session is relayed, and the code you run.