HOW IT WORKS

Under the hood, Avenia is a real-world asset network. The asset is a GPU, a physical card sitting in someone's rig, and the yield is the USDG it earns for training your model. You never talk to the GPU. You talk to the coordinator, the brain that gates on the token, finds a card, strips your identity, and streams the loss back. Here is exactly how a run flows, end to end.

Three parties. One privacy chokepoint.

You never talk to the GPU directly. The coordinator sits in the middle: it gates on $AVEN, finds a worker, and strips every trace of your identity before the job is dispatched. The worker trains and streams loss back; the adapter returns to you. The dataset is never persisted or logged.

CLIENT-LINK-01· you · the submitter
POST /v1/train opens an SSE stream. You hand over a dataset.jsonl, a base model, and hyperparams - nothing else.
SYNAPTIC-02· holder-gate + router
Enforces hold-to-submit, then acquires an idle worker by measured throughput. strips wallet + ip before dispatch.
GPU-NODE-03· someone else's card
Pulls the dataset, runs a LoRA fine-tune, and streams step + loss for minutes. Never learns who you are.
RETURN-04· weights come home
adapter.safetensors returns to you with an eval-loss receipt. The dataset is never persisted or logged.
avenia :: online [sync]· she is routing [processing]

Five stages, one stream

A single open connection carries the whole run. Each stage below maps to the SSE frames your client receives.

01
SUBMIT · you open a stream

POST /v1/train with a dataset, a base model, and hyperparams. The response is a Server-Sent Events stream that stays open for the whole run.

02
ROUTE · the coordinator picks a GPU

It enforces the holder-gate, then acquires an idle eligible worker by measured throughput - waiting up to 30s for one. Your wallet and IP are stripped before dispatch.

03
TRAIN · the worker fine-tunes

The worker pulls the dataset and trains a LoRA for real, streaming step + loss for minutes. Steps are clamped to 5,000 so a job can never run unbounded.

04
PROVE · it measures quality

The worker evaluates the adapter on a held-out slice and reports an eval loss - your quality receipt - alongside the uploaded adapter.safetensors.

05
SETTLE · everyone gets paid

credits = gpu_minutes × model_rate, split in one atomic transaction on Robinhood Chain: the worker's share, the holder pool, and the treasury.

[1] SUBMIT     POST /v1/train  ·  dataset.jsonl + base model + hyperparams
     │
     v
[2] ROUTE      enforce holder-gate  ─>  acquire idle eligible worker
     │                                  (selected by measured throughput)
     v
[3] TRAIN      the worker fine-tunes a LoRA · streams step + loss for minutes
     │
     │  loss 2.41 ┤▓▒░
     │       1.78 ┤   ▒▓▒░
     │       1.14 ┤       ░▒▓▒░
     │       0.79 ┤           ░▒▓▒▒░░___
     │       0.63 ┤                    ░▒░░________
     │            └────────────────────────────────────> step
     v
[4] ADAPTER    eval loss = your quality receipt · adapter.safetensors uploaded
     │
     v
[5] SETTLE     credits = gpu_minutes × model_rate · one atomic tx, Robinhood Chain
               worker keeps 70/85%  ·  holders 80% of margin  ·  treasury 20%
avenia.train
[▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮] 100%
loss visualization · a real run settling from ~2.6 toward ~0.6
TRAINING· step 0/120· lr 2e-4 · rank 16
loss2.6000

Your data meets your identity exactly once

no dataset is persisted

The jobs ledger has no dataset column. Content is hosted only for the duration of the run and dropped when it seals. Nothing is logged.

the worker never sees you

The dispatched job carries no wallet, account, or IP - only a dataset URL and hyperparameters. The GPU owner is paid without ever learning who you are.

the coordinator is the seam

It is the single place identity and data ever touch. That is deliberate: strip once, in one audited place, and the rest of the network stays blind.

The eval loss is your receipt

You handed a run to a stranger's GPU - how do you know it did the work? Every job holds out a slice of your data the trainer never sees, then measures the adapter's loss on it. That eval loss ships back with the weights. A number that fell from ~2.6 to ~0.6 on data the model never trained on is proof the LoRA generalized - not proof it memorized. It is the same number the live console and the CLI print at the end of a run.