Lightchain
Lightchain AIVM
Last updated -
The Artificial Intelligence Virtual Machine is Lightchain AI's planned execution layer for AI applications. Lightchain Protocol AI v1 describes how it would assign AI work to nodes, verify results, and support model training, inference, and data transformation. The live text-inference API is a narrower documented service, so its availability doesn't confirm deployment of the full AIVM design.
How would an inference task run?
Within the Lightchain Protocol AI v1 design, an inference request follows this order:
- A user submits an inference request through an API or developer portal.
- The AIVM assigns the task to nodes with sufficient computing resources.
- The nodes execute the task, and the results undergo cryptographic verification before they're returned to the user.
The proposed execution engine handles operations such as matrix multiplication, neural-network computation, and data transformation. Its parallel architecture is intended to process multiple AI tasks at once.
Where would models and data sit?
The v1 architecture separates AI execution from blockchain records and large-file storage. It names IPFS, Filecoin, and Arweave as off-chain storage systems for datasets and models. The blockchain would retain metadata, cryptographic proofs, and access controls.
For federated model training, the proposed workflow divides training work among nodes. Raw data stays at its source in that workflow, while nodes submit encrypted gradients or weights. Contributions would be verified before they're integrated into the shared model.
Compatibility with TensorFlow, PyTorch, and ONNX is also part of the v1 AIVM design. That proposed framework support concerns deploying models into the execution environment. The Developer API exposes model discovery through
GET /v1/models
, which lists models that at least one worker serves.
How does Proof of Intelligence relate to execution?
AIVM provides the proposed AI execution environment, while Proof of Intelligence (PoI) connects useful computation to network participation and LCAI rewards. In the v1 whitepaper, participating nodes receive modular AI tasks and submit cryptographic evidence of their work. The network would evaluate submissions using predefined measures such as accuracy or efficiency, then reward accepted contributions according to the complexity and value of the work.
What does the live inference API establish?
Lightchain's Developer API overview lists the service as live on testnet (chain ID 8200) and mainnet (chain ID 9200). Its documented routes are
/v1/models
and
/v1/chat/completions
. The interface supports text inference; it doesn't provide model-training operations through those routes.
Each completion runs as a worker-served blockchain job, with its fee paid in LCAI from a prepaid balance in the
JobRegistry
contract. Mainnet calls spend real LCAI.
Worked example: Does a completed job mean a model update?
A text-completion job returns a model's answer. The v1 training workflow would instead produce encrypted gradients or weights, with verification before integration into a shared model.
Hypothetical case: an app developer requests a summary of a passage through the Developer API, receives a completion, and matches its job identifier to an on-chain record naming the serving worker.
That match lets the developer trace the summary to a served inference job. It doesn't establish that the passage changed the model: the v1 design describes model updates through verified training contributions, which are a different outcome from a returned text completion.
What do privacy and verification cover?
The v1 whitepaper proposes several protections with different roles. Zero-knowledge proofs would support verification without exposing underlying data; homomorphic encryption would allow computation over encrypted data; federated learning would keep training data local while sharing updates. These protections belong to the proposed architecture and its particular workflows.
The Developer API has a separate trust condition: its operator holds session keys and can read prompts and answers. Workers and protocol disputers can read the conversation carried by a job they serve or check. A caller can identify the job recorded on chain, but can't independently compare the returned plaintext with the encrypted answer committed there because the API holds the decryption key.