The Disputer Service re-executes a sample of real inference jobs and compares its outputs with the worker’s using semantic similarity. A low score flags possible model substitution or degraded output for further review. The MVP does not provide cryptographic proof of which model the worker ran.

User-initiated disputes provide another route to review. A user who challenges a low-quality response posts a bond, and the disputer re-executes the inference and compares the outputs. Dispute evidence is recorded on-chain. Workers must stake LCAI, with the amount varying by model. Timeouts, failed disputes, and repeated offenses can lead to progressive slashing and eventual worker suspension.

The production roadmap proposes hardware attestation through a Trusted Execution Environment (TEE) to establish model identity and execution integrity. Planned ZK proofs have a selective scope: cryptographic verification of high-value jobs. These mechanisms would add execution evidence beyond the MVP’s comparison of responses.

Geth hosts the execution contracts, while the Worker Sidecar runs inference through Ollama. The JobRegistry contract manages job state, inference-fee escrow, and dispute records. Prysm provides the consensus layer and EIP-4844 blob data availability for encrypted prompts and responses.

The worker delivers an encrypted response over WebSocket. On-chain completion uses a response blob and a completeJob call, handled asynchronously from that delivery. Receiving the response alone does not confirm that on-chain completion has occurred.

Blob data availability also has a separate fee market. The inference fee held in escrow and the cost of blob storage are distinct components of the documented architecture.

Lightchain AI’s central dispatcher no longer runs on mainnet or testnet. The AI Inference Architecture records October 19, 2026, as its mainnet retirement date, when AIConfig.getDispatcherAddress() began returning the burn address.

View full-size image

The WorkerRegistry tracks worker registration, stake, eligibility, and reputation. For a model-specific session request, SessionManager uses an on-chain draw seeded by the hash of the block after the request. Stake and reputation weight that draw, and the set of workers allowed to claim expands block by block until a worker claims the session. Contracts enforce registration, stake, model support, capacity, and suspension status. Jobs within the opened session go to its pinned worker.

P2P worker discovery and a draw seeded by an on-chain Verifiable Random Function (VRF) remain planned upgrades.

Session encryption uses a single AES-256 key for messages within that session. The frontend encrypts the key for the assigned worker and, for escrow, the disputer. Prompts and responses are encrypted before blob storage. The worker decrypts prompts to run inference, and the disputer can decrypt session data for verification and dispute resolution. On-chain observers and the relay see ciphertext. Encrypted blobs have a documented retention period of approximately 18 days, subject to DAO configuration.

The relay can still observe communicating parties, timing, and message sizes. The production roadmap proposes moving disputer processing inside a TEE to confine decrypted data to the enclave. Replacing relay delivery with libp2p messaging is a separate planned change intended to remove centralized visibility into traffic patterns.

View full-size image

• If cryptographic model identity is mandatory, the documented MVP does not meet that requirement.
• For sensitive sessions, account for the worker’s and disputer’s decryption access, alongside relay-visible traffic metadata.
• For job accounting, track on-chain completion separately from receipt of an encrypted WebSocket response.
• If an application depends on user-initiated challenges, allow for the required dispute bond.

View full-size image