Cómo funciona

Una sesión tiene cuatro pasos: descubrimiento, conexión, inferencia y liquidación. Ninguno de ellos lo opera GenKaKu Labs.

1. Descubrimiento

Un worker se registra en WorkerRegistry con:

• un digest del peer ID — keccak256("genkaku.peer.v0:" + peerId), que vincula su identidad libp2p a su billetera,
• un hash de política — un compromiso bytes32 que el worker fija al registrarse,
• un localizador opcional — una pista multiaddr para que un usuario pueda marcarlo.

El registro expone un count() y un isActive(address) públicos. Los plugins los leen a través de un RPC público; no hay ninguna API de directorio en la que confiar.

Los localizadores son opcionales. Un worker publica su dirección pública solo cuando el operador activa publishAddress de forma explícita, y un localizador publicado es permanente una vez que está en la cadena.

El hash de política es un compromiso, no una descripción del modelo. Lo que un worker ofrece realmente se publica aparte, en su tablón de ofertas (/genkaku/offers/0), que lista el nombre del modelo, el precio y las capacidades de Ollama.

2. Conexión

El plugin de usuario abre una conexión libp2p al peer ID del worker. El intercambio hello (/genkaku/hello/0) fija:

• el peer ID (debe coincidir con la entrada del registro),
• la dirección de la billetera del worker, demostrada con una firma en lugar de solo afirmada,
• la tarifa por hora y el modo de facturación.

Si los dos pares pueden alcanzarse directamente —misma LAN, una IPv4 pública, una IPv6 global—, los tokens viajan directamente entre ellos. Si no pueden, la sesión funciona a través del relay semilla público, accesible en staging.genkaku.app/seed.

El relay reenvía tráfico libp2p cifrado. No puede leer los prompts ni la salida, pero su operador sí ve metadatos de conexión: direcciones de los pares, tiempos y volumen. Trata una sesión retransmitida como privada en cuanto a contenido, pero no en cuanto a quién habla con quién.

En esta versión no hay atravesamiento de NAT (no hay DCUtR). O los pares son alcanzables directamente o el relay transporta la sesión.

3. Inferencia

El worker ejecuta el modelo localmente con Ollama y transmite los tokens de vuelta por la misma conexión. El mercado nunca ve el prompt; el operador del worker sí.

Una oferta a precio cero se salta la cadena por completo y se sirve gratis.

4. Liquidación

Las sesiones de pago usan una tarifa por hora con acumulación por minuto iniciado:

• el worker anuncia un precio por hora,
• cada minuto iniciado cuenta como un minuto,
• un trabajo de dos minutos paga dos minutos, no una hora.

Para un modelo de pago, el usuario abre un escrow en JobEscrow antes del primer token, lo que supone una transacción en la cadena. Cuando la sesión termina:

1. el worker firma un recibo sobre el ID de sesión, el gasto y un hash del recibo;
2. settle() verifica esa firma y libera el gasto;
3. el 99% va al worker y el 1% a la tesorería;
4. cualquier resto no gastado vuelve al usuario.

La liquidación es una segunda transacción en la cadena, así que una sesión de pago le cuesta al usuario dos transacciones en total: abrir el escrow y luego liquidar. El gas lo paga quien envía cada transacción.

Un worker acumula sus ingresos liquidados en el contrato y puede llamar a claim() en cualquier momento; el retiro se paga a la billetera del worker.

Qué reemplaza al orquestador

Modelo anterior	GenKaKu
El servidor asigna trabajos	El usuario elige un worker del contrato
El servidor guarda prompts	Conexión directa entre pares
El servidor mide el uso	Acumulación por minuto iniciado y recibo firmado
El servidor paga	Escrow liberado en la cadena

Los supuestos de confianza son menores porque hay menos en medio. No son cero: sigues confiando el prompt al worker, los metadatos al relay si tu sesión va retransmitida, y el código que ejecutas.