Legal

Privacy

Silicon Network routes your request to a machine someone else owns. That shapes everything below, so this page says plainly who holds what, including where we are not private yet.

Last updated 3 October 2026.

The short version

We store the metadata needed to bill you and nothing you wrote, with two exceptions you opt into: a batch job, and the file you upload for it, is kept until it runs and then for at most 30 days; and a conversation you save in the Chat app is kept, encrypted, for the period you pick (at most a year after its last message) or until you delete it. A LoRA adapter you upload is kept until you delete it. The machine that runs your request currently stores your prompt and the reply on its own disk. If that is not acceptable for your data, run your own node and point your client at it. The software is Apache-2.0 and the wire protocol is identical.

What we hold about your account

Your email address, a hash of your password, your organization name, and, if you top up, the wallet address you bind to prove a payment came from you. We do not ask for a legal name, a postal address, or a card.

What a served request records

Organisation, the API key used, the model id, prompt and completion token counts, latency, status, the region of the serving node, and a timestamp. There is no field for your prompt or the reply in that record: not truncated, not hashed, not sampled.

The gateway also sees the IP address each request comes from. It is not written to that record. For API key anomaly detection (a key suddenly used from many more addresses than usual, or from a new country), each address a key is used from is kept only as a keyed hash, never the address itself, together with its country when a GeoIP database is configured, and is deleted once the key has not been used from it for 30 days.

Batch jobs and uploaded files

Asynchronous work has to be stored to run later, so the Batch API is the one place our control plane holds content. When you upload a batch file or submit a batch, we keep the file, the requests in it, and the responses in our database. An uploaded file is deleted when it expires: 30 days after upload, or sooner if you set an expiry, or the moment you delete it. A batch's requests and responses are deleted 30 days after the batch finishes, or as soon as you delete its output and error files. Upload with X-Silicon-No-Retention: true and the file is deleted as soon as a batch is created from it, or an hour after upload if none is. What remains of a finished batch is its status, counts, timestamps, the metadata you attached to it, and the custom_id of each request.

Conversations in the Chat app

The Chat app at /chat is the one place we keep what you wrote by default, because a chat you can come back to has to be stored somewhere. For each saved conversation we store its title, its system prompt, and every message, including any image or text file you attached, all encrypted at rest with a key held apart from the database. Next to them, unencrypted, we store which model answered, the token counts and cost of each reply, and timestamps, so the app can show what each answer cost.

A saved conversation is visible only to you, and only while you are acting in the organization you started it in: other members of that organization, its owners and admins included, cannot list or read it. It is deleted automatically 1, 7, 30, 90 or 365 days after its last message, whichever you choose (30 by default). You can delete one conversation or all of them at any time, export them as JSON, and deleting your account deletes every conversation you saved. Deletion removes the rows from our database; our database provider's backups age out on their own schedule.

A temporary chat stores nothing on our side: the conversation lives only in your browser tab, and every request is sent with X-Silicon-No-Retention: true, which does what the section on the serving node below describes, no more. Chat replies are ordinary requests billed to your organization, made with a short lived key our web server holds for your session and never sends to your browser; each person's chat spend is capped at $5 per rolling 24 hours by default. Like any other request, the serving node processes what you send, saved or temporary.

LoRA adapters you upload

An adapter you upload (its config and weights) is stored until you delete it, and is copied to each node it is deployed on, where the operator can read it. Deleting it removes the stored files and uninstalls it from those nodes. An adapter holds no prompts or replies.

What the serving node retains: read this one

The Silicon Network engine appends every internal event to a log on the operator's disk, and by default those events carry the messages you sent and every token generated back. The engine also serves that log over its own local API. So, unless you ask otherwise, the operator of the machine that answered your request can read that request until the log rotates away. Only operators we have approved can receive traffic, and today that is hardware we run ourselves.

Send X-Silicon-No-Retention: true and that stops. Our gateway skips verification sampling, so your prompt is never copied to a second machine, and the engine honors the header on every surface: it redacts your prompt and the output from its event log, its API logs and the log it serves locally, and never caches the request. A generated image is held in memory only, for up to an hour, so you can fetch its URL. A temporary chat sends the header with every request. This is enforced by the engine software on the node, which is why we only route to approved operators. The details are in the API docs.

What our gateway does with a request in flight

It holds the body in memory long enough to verify your key, resolve the model id, forward it, and count the tokens that came back. It does not write bodies to disk. Two optional features widen that when enabled: content moderation sends prompt text to a moderation service before serving, and verification sampling re-runs a sampled request on our own engine to score the node that served it. Both are currently off.

Who else sees your data

Our hosting providers process traffic and store our database on our behalf, and blockchain RPC providers (for Arbitrum One, Base and Tron) see the public blockchain queries we make to detect your top-up. If you pay by card, Privy holds the wallet the purchase lands in and sees the email you sign in to it with, and the card provider you choose at checkout (such as Stripe or MoonPay) processes your payment and any identity check it needs; we never see your card details. We do not sell your data, we do not use your prompts to train anything, and we run no advertising or analytics trackers on this site.

How long we keep it

Usage records persist so that you and we can reconcile what was billed. The keyed hashes of client addresses used for key anomaly detection are deleted 30 days after their last use. Account records persist while your account exists. Saved chats persist for the period you chose, as described above. Ask us to delete your account and we will remove it, its keys and its saved chats; we keep the minimum billing record we need for our own accounts.

Your choices

You can revoke an API key instantly, set a spend cap, export or delete your saved chats from the Chat app's settings, ask for your data, or ask for deletion. Because Silicon Network is open source, you also have an option most providers cannot offer: run the engine on your own hardware and send nothing to us at all.

Contact

Write to support@siliconnetwork.io. If you need a data processing agreement or a named sub-processor list before you can use Silicon Network, say so and we will tell you honestly whether we can meet your requirement yet.