Lightchain
Lightchain: Studio or API for private prompts?
Last updated -
Lightchain AI's Studio 0.1.0 is an option when inference prompts need to stay confidential from the Developer API operator: it keeps session keys in the IDE and encrypts prompts locally. The Developer API supports app and server integrations, but its operator can read prompts and answers. With either route, the serving worker and protocol disputers can read the conversation carried by a job.
Where does the session key live?
The session key controls encryption and decryption of inference content. Studio creates and keeps that key in the IDE. The Developer API holds session keys on its servers because its OpenAI-compatible clients don't handle the protocol's session encryption themselves.
Both interfaces use Lightchain AI's inference network, but they expose different information to the API operator during a request.
| Stage | Lightchain Studio 0.1.0 | Developer API |
|---|---|---|
| Authenticate access | Wallet sign-in using SIWE, without an API key. | Ordinary requests use an API key. On servers supporting experimental per-call payments, a payment can authenticate a request without one. |
| Establish session-key custody | The IDE creates and retains the session key. | The API holds the session keys and performs encryption and decryption on its servers. |
| Send the prompt | The IDE encrypts inference prompts before they leave the machine. | TLS protects transport to the API, which receives readable prompts and encrypts them for the worker. |
| Process and check the job | The serving worker can read the job conversation; protocol disputers can read the conversation in jobs they check. | The serving worker and protocol disputers have the same access to the job conversation. |
| Return the answer | The IDE decrypts the answer locally. | The API decrypts the answer and returns it in the completion response. |
The Developer API stores its session keys encrypted under a separate key kept outside the database. That storage arrangement still allows the operator to decrypt inference content while serving requests. Local session-key custody changes that operator-access boundary; it doesn't remove the worker and disputers from the processing model.
There are other routes for holding session keys yourself. Lightchain Chat creates and keeps its key in the browser, and a direct protocol client can manage its own keys. Choosing local key custody doesn't require using an IDE.
Which interface fits your work?
Studio for interactive development
Lightchain Studio 0.1.0 is built on Code - OSS and includes a coding agent that runs inference on the Lightchain network. It combines that agent with wallet access, Foundry-based contract development, and a view for interacting with deployed contracts. You can review proposed code changes and accept or reject them inside the workspace.
Studio can connect to a browser wallet or keep local accounts in the operating system's keychain. Those wallet arrangements concern signing access; the inference session key remains in the IDE under the documented Studio design.
The Developer API for an app or server
The Developer API exposes
/v1/models
and
/v1/chat/completions
. Its compatibility is limited to the documented text interface: it doesn't provide images, audio, embeddings, tools, or function calling. Parameters such as
temperature
,
top_p
, and
max_tokens
are accepted but ignored because each worker uses the settings configured by its operator.
Conversation history must accompany each call. A
conversation_id
expresses a session preference; it doesn't store earlier turns for you or serialize concurrent requests. A job can carry about 124 KiB of conversation unless the server sets a smaller bound. Beyond that bound, the API removes older whole turns while preserving system and developer messages and the last turn. The response's
lightchain.dropped_messages
field reports omitted messages, so the submitted conversation and the conversation actually processed can differ.
What can an API caller verify?
A completion's
lightchain
object identifies the on-chain job, its session, the submission transaction, and the worker that served it. This lets the caller trace the response to a paid network job and its committed result.
The Developer API caller doesn't hold the session key, so they can't independently compare the returned plaintext with the encrypted answer committed on chain. Protocol disputers can sample and rerun jobs, but that process doesn't give the API caller the missing decryption key. Job provenance and independent checking of the returned text are separate capabilities.
Credits and spending authority
For the same wallet and network, Studio, Lightchain Chat, and the Developer API's delegate path draw from the same prepaid balance in the
JobRegistry
contract. Testnet uses chain ID 8200; mainnet uses chain ID 9200. Mainnet inference spends real LCAI, while the faucet supplies testnet tokens for testing.
Delegate-based spending
Studio lets the server's delegate spend prepaid credits under an allowance that you authorize. For the Developer API's delegate path,
depositAndAuthorize
funds the prepaid balance and grants spending authority. The delegate's allowance caps its spending on jobs for that wallet across its API keys, and a key's lifetime spend cap adds a separate limit.
The delegate can't withdraw or transfer the prepaid balance. The wallet owner can withdraw it or revoke the delegate through their own transaction. Revocation also zeroes the delegate's allowance, stopping delegate-based spending through every affected key until authorization is restored.
Experimental per-call payments
On a server configured to accept them, per-call payments use a signed debit authorization against the payer's funded prepaid balance. Each authorization covers one job, has a maximum amount and deadline, and uses a single-use nonce. An API key is optional for this route; when a valid key accompanies the payment, its limits still apply.
A request carrying a payment authorization uses that payment exclusively. If it's refused, the API doesn't fall back to charging through a delegate. Changing this payment method changes spending authority, while the Developer API continues to hold the inference session keys, encrypt prompts, and decrypt answers on its servers.