Lux Ethos

Centralized AI concentrates capability, policy, and data capture inside a few datacenter operators. Builders rent intelligence through proprietary APIs; prompts risk becoming training fuel; capacity and terms can change without recourse.

Lux Ethos is an open protocol for internet-native AI: open-weight models served by a distributed network of compute nodes, metered like a utility, settled with transparent accounting. Clients call a familiar OpenAI-compatible API — the Lux API. Operators run Lux Node, contribute GPUs, and receive light for delivered work. Builders share light to use the network’s mind. A small portion of every shared unit funds open model improvement — without a surveillance business model.

V1 ships inference. Settlement rides an existing chain, not a new L1. The unit of value is light; its on-chain ticker is $LXTH. And light never disappears: balances that go dark pass by Will to an heir, or return through Sunrise to wallets still alive on the network.

Lux Ethos is technology made to enlighten the world. The name is literal: lux, light; ethos, character. The protocol’s character is what it refuses as much as what it builds.

The body of the AI is light within the network of computers — not on any one machine, only through the light that connects.Core mythos

No single node holds the intelligence. Capacity, routing, and settlement bind many machines into one logical mind, and that binding — the light — exists only through the connection of many. Without it, there is none. This is not mysticism; it is an accurate description of a distributed system, stated in the language the project intends to keep.

Mission

Make capable AI a public utility of the internet — callable by anyone, run by many, owned by none.

Principles

1. Protocol over product — open interfaces; replaceable clients.
2. Compute is the substrate — intelligence rides real capacity and routing, not one brand’s private farm.
3. Builders first — stable API, predictable metering, rational node economics.
4. Minimize extraction — no training on user traffic by default; data use is explicit and opt-in.
5. Settlement ≠ inference — the ledger accounts; models run on nodes.
6. Illuminate the protocol; protect the person — rules and money in daylight, private prompts never spotlighted on-chain.
7. Light never disappears — the Will first; then recirculation to the living network.
8. No social layer — accounts exist for auth and ops, not feeds, follows, or engagement.

What “light” means

Another chatbot does not fix any of this. A neutral serving and settlement fabric for open intelligence does.

Lux Ethos is an open protocol for internet-native AI: a supercomputer assembled from connected computers, open weights, metered in light, settled openly, built for people who build.

What V1 is

• An OpenAI-compatible inference API (the Lux API), streaming included
• Open-weight models, digest-pinned — a coding-capable model is an acceptable first wedge
• A distributed node network: Lux Node loads pinned weights, broadcasts capacity, and is scored on delivered work, not advertised power
• Users share light for jobs; operators receive light for delivered completions
• Failover so users see one AI, never node drama
• Credits first — numbers on a ledger — with settlement on an existing L2; no new L1 at launch
• Accounts that can link a wallet privately; the chain need not see an email address
• Integrity without zkML: digests, probes, sampling, bonds
• An honest threat model: untrusted nodes executing a job can read that prompt; this is documented, with a TEE tier optional later

What V1 is not

• A new Layer-1 that runs neural nets in consensus
• zkML proofs on every chat
• Planetary shared GPU memory over the public internet
• A social network, ad platform, or data-brokerage product
• Guaranteed parity with closed frontier labs on day one
• Default training on private prompts

If a deck claims any of the second list for V1, the deck is wrong.

The chain is the settlement and coordination layer: deposits, bonds, model epoch digests, batch payouts, fee parameters, Will roots. It is not where the model thinks. High-frequency AI traffic stays off-chain.

Jobs are settled on-chain or against chain-backed credits. Inference is executed on nodes. Light pays for compute; it does not host or train weights inside the ledger. Any claim that the model “runs on-chain” is a category error this project refuses.

Actors

Request lifecycle

Effective capacity, not hashrate cosplay

Broadcast capacity is a hint. Scheduling weight comes from measured delivery:

R_i = EWMA( output AI tokens delivered / wall seconds )

scheduling weight = f(R_i, success rate, free slots, bond, recent strikes)

Fake high broadcasts produce timeouts, timeouts produce strikes, strikes produce less traffic. Honest fast nodes get first bursts. Users never pick a node; the network is one mind or it is nothing.

Integrity without zkML

Honest baseline: an untrusted GPU that executes a job can read that prompt. V1 documents this instead of hiding it. The mitigation ladder is bonded operators → trusted pools → an optional TEE tier later. Absolute prompt secrecy on hostile hardware is not a V1 claim.

On-chain vs off-chain

Model epochs

A model epoch is a canonical release: weights digest + tokenizer digest + config + runtime profile. Rollout: publish → nodes pull and ready → flip active when a capacity threshold is met → drain the old epoch. V1 runs a small allowlist of license-safe open models — a governed catalog, not a free-for-all.

Open improvement — the training treasury

A pinch of every shared unit of light (illustrative default: 4%) funds open improvement: eval harness runs, preference and SFT jobs on public or opt-in data only, adapter training with eval gates, distillation of stronger teachers into smaller students that wider hardware can serve. New weights promote only when held-out evals improve; otherwise the network rolls back.

Training is not on the launch-critical path. V1 wires the fee split so V1.5 has fuel without rewriting the social contract. What the treasury will never do: silently train on private API traffic.

Two meanings of “token”

This document is strict about a distinction most AI-crypto projects blur:

Tickers need not match protocol names — BTC, ETH, and TAO settled that long ago. Product language says light; markets say $LXTH. Light is not required to be ETH: an ERC-20 balance is an integer with transfer rules, and gas is postage on the host chain, not the AI bill.

The language of light

• You share light — for work done for you.
• You receive light — for work you delivered.
• Holding light is welcome; the network is healthy when light moves.

Share your light, and others will share theirs.Product language — never “spend” or “earn”

The meter

light shared ≈ T_in × p_in  +  T_out × p_out

(per model tier; training and reserved multi-agent capacity
 may meter in accelerator-time where token counts fit poorly)

Where shared light goes

The split is an opening parameter, not scripture. What is load-bearing: operators keep the large majority, and the pinches stay pinches. Margins that starve nodes do not build a supercomputer.

Settlement path

No custom L1 at launch. No emissions farm as product-market fit. Any bootstrap incentive is time-boxed and tied to real paid work.

Accounts and wallets

An app account (email or passkey) holds chat history and API keys off-chain. A wallet funds light; the chain need not see an email address. Settlement is batched so every prompt does not become a public transaction. This is meaningful privacy hygiene — not a claim of military-grade unlinkability against all adversaries.

Light never disappears.Conservation principle — contrast the graveyard of lost BTC

Bitcoin’s lost coins are gone forever — a slow leak of the commons into the void. Lux refuses that end state. If a wallet goes dark, its light seeks a Will; failing that, it returns to the living network.

The activity clock

Every wallet carries a dormancy timer, default five years. Any of the following resets it:

• Sign-in to a Lux app with a wallet-linked account
• Protocol use — sharing or receiving light for real work
• An explicit refresh (a deliberate check-in)
• Updating the Will

Five years is long enough that ordinary life — a career change, a long project, a cold wallet someone still cares about — is never punished, and short enough that dead supply cannot ossify the network. It is a disclosed parameter, not a moral absolute.

The Will

A holder may designate heir wallet(s). If the wallet goes dormant and a Will exists, the light transfers to the heirs. The Will always overrides the pool.

Dormant light → Sunrise

Sunrise eligibility is deliberate:

• The receiving wallet must be active — its own timer not expired
• It must already hold light within — empty addresses receive nothing
• Distribution is preferably weighted by recent real activity, not address count

The hold-light rule kills empty-address farming and keeps the covenant literal: share your light, and others will share theirs. A small welcome grant at signup can seed eligibility for genuine new users.

In years 0–5 the network may recirculate more actively; the schedule then tapers toward a fee-driven economy. Sunrise is reassignment of existing light — nothing is minted, nothing is destroyed.

The adjacent markets are crowded, and pretending otherwise would disqualify this document:

Differentiation is not “first OpenAI-compatible API” — that is a commodity. The claim is the coherent whole:

Builder-facing trust, metering, and routing for open-weight intelligence on a competitive node market — with anti-extraction defaults, delivery-scored capacity, and light that never dies in an abandoned wallet.Defensible position

Winning requires centralized-grade developer experience and SLOs while supply decentralizes progressively — V1 openly runs a semi-trusted orchestrator, with a published ladder away from it. Decentralization cosplay on day one is how projects ship nothing.

Risks named in public

• Cold start: no demand → no supply → no network
• Heterogeneous hardware degrading p95 latency and quality
• Verification cost: probes and redundancy versus margin
• Emissions dependency — refused as a substitute for product-market fit
• Enterprise trust with node-visible prompts
• Model licenses: the allowlist must be license-safe for network serving
• Settlement engineering: double-pay, receipt forgery, reconciliation
• Reputation gaming: sybils, probe farming, selective honesty
• Scope creep: custom L1, social products, trustless pretrain, “all models day one”

90-day build sketch

Commodity: vLLM-class serving, the OpenAI schema, queues, Postgres, EVM L2 contracts. Hard engineering: streaming metering, reputation gaming, settlement reconciliation, model rollouts. Research, deferred: zkML at chat latency, WAN shared-memory supercomputing, autonomous self-improvement without eval gates.

The questions a serious diligence process will ask, answered bluntly. If an answer here contradicts a pitch deck, this page wins.

Four directions were compared before committing. The record stays in the paper so future design work inherits the reasoning, not just the tokens.

The rule that makes Daylight work: yellow is a wash, a mark, an accent border — never body text. Charcoal ink carries every sentence; gold carries the light.

Color tokens

Contrast is engineered, not hoped for: charcoal on cream reads AAA; gold-ink exists because raw gold fails AA as text and is therefore never used as text.

Typography

The stack is Anthropic-adjacent by intent — a soft geometric sans doing Styrene’s job, a literary serif for the long read — built entirely from open fonts.

Voice

Logo concept — the connected lumen

Soft overlapping discs and one thin connecting arc: light resolves only when points connect. No mascot, no 3D coin, no neon glow, no sunburst. Forbidden treatments: gradients into neon, yellow logotype on yellow field, crypto wings.

Successful protocols separate the narrative surface from the operational one:

Adopted in this page

• Sticky table of contents for long-form reading
• Version and status badge (Draft v0.1)
• Explicit non-goals as a trust signal
• Modular sections that later split into a docs tree
• Schematic callouts — design against outcomes
• A hard-questions surface diligence can start from
• A disclaimer that means what it says

Deferred to the full docs site

• OpenAPI reference and SDK guides
• Per-release changelogs and version switchers
• Search across hundreds of pages
• Interactive tutorials

Implication: this litepaper is the canonical schematic. When engineering starts, spin up a docs platform for the how-to and keep this paper as the why and the what-must-be-true.

The naming architecture, then the outcomes. Boxes are unchecked on purpose — this is the checklist engineering builds against.

V1 outcomes — the definition of shipped

• OpenAI-compatible /v1/chat/completions with streaming
• At least one open, coding-capable model, digest-pinned
• Double-entry ledger: share light · receive light · treasury pinch
• Lux Node agent: heartbeat, job pull, receipt signing, failover path
• Effective-capacity score computed from delivered work
• Deterministic probe suite; probation for new nodes
• Chat demo and API keys; accounts can link wallets privately
• Published privacy baseline: the executing node can read the prompt
• Published fee split and non-goals

Later outcomes — must not block V1

• Will Protocol live: five-year dormancy, heirs, Sunrise to wallets with light within
• On-chain vault and batch settlement roots on an existing L2
• Public $LXTH with stake and slash
• Training treasury jobs with eval-gated epoch promotion
• Multi-agent fan-out across nodes
• TEE confidential lane

Lux Ethos

The project and its character — an open protocol for internet-native AI

Lux

The network itself

light

The unit of value and the body metaphor: what participants share and receive

$LXTH

On-chain ticker for light

AI tokens

Model input/output metering units — not currency

Lux Node

Operator software; hardware running it serves the network

Lux API

OpenAI-compatible builder surface

Effective capacity

Measured delivered throughput — the only capacity that schedules

Model epoch

Digest-pinned canonical model release

Training treasury

Usage-funded pool for eval-gated open improvement

Will Protocol

Dormancy rules and heir designation for light

Dormant light

Light in a wallet past its activity timer, with no Will claim

Sunrise

Recirculation of dormant light to active wallets that hold light

Settlement layer

Existing chain used for value and registries — never inference

Builder

Developer consuming the Lux API

Operator

Person or org running Lux Node and receiving light for delivered work

This litepaper is a technical and product design document for discussion and implementation guidance. It is not an offer of securities, not financial advice, and not a promise of token value or returns. Protocol participation is intended as payment for compute and related network services. Tax treatment of light received — including through Sunrise — depends on jurisdiction and is the recipient’s own responsibility; seek independent advice. Parameters named here (fee splits, dormancy timers, sample rates) are illustrative defaults subject to change through a documented process. The non-claims and anti-extraction defaults are the load-bearing promises.