A phone has a capable processor, sits idle most of the day, and belongs to someone. Ailoos's bet is that those three facts make it the right place to train. This post is the on-device loop as it runs, with the numbers from a real phone.
The loop
- Fetch the base. The app downloads the current EmpoorioLM base (the 64M model, 258 MB) from SynoodoS and, if it has trained before, its previous LoRA adapter.
- Fetch data. A dataset that fits — the catalogue exposes each dataset's parquet size, so a phone with 5 MB to spare gets the 105 datasets under that.
- Train locally. ExecuTorch runs LoRA steps on device. Only the adapter's low-rank matrices change; the base stays fixed. A PII firewall keeps anything personal out of the batch.
- Sign and upload. The adapter is signed with the node's ED25519 key and uploaded to the coordinator, with an upload secret bound to the session so nobody can submit work as someone else.
- Validate and merge. The coordinator validates the adapter (geometry, signature, loss trajectory), merges it with others by FedAvg, and publishes the new adapter.
- Record work. Units of verified work are recorded per node per era for the on-chain reward pool.
Measured on a POCO F8 PRO (8 September 2026)
30 LoRA steps on the 64M base: loss 6.8669 → 6.4434. Signature, upload, validation, merge: all passed; the adapter was implemented into the production model. The whole path, from download to implementation, on one physical device.
The bug that made it necessary
Before that day, the artefact production served for mobile training contained randomly initialised weights. Every exporter in the repository built the model architecture and exported it without loading a checkpoint. Bytes from the trained 40M model were absent from the file; bytes from a seeded random model were present. Every phone in the network had been fine-tuning adapters on noise — and the loss went down anyway, the artefact was signed, merged and rewarded. On noise, loss hovered near 9.0; on the real 64M base it starts at 6.9. The fixed exporter loads the checkpoint, derives the architecture from the tensors, and verifies the real weights are inside the file before writing it.
A second finding: no mobile upload had succeeded since 6 August, because a security fix had added the upload secret to the coordinator and the app requested it and then discarded it — every upload returned 422. Confirmed in the production database.
Geometry belongs to the artefact
The same failure pattern appeared in four layers — a hardcoded layer count in the Android trainer ("expected 64 tensors, found 80"), a fixed hidden size in the coordinator's contracts, a global tokenizer, a hardcoded stop token. The fix in every case: derive the geometry from the adapter's own configuration file (empoorio_lora.v3) and check consistency, never fix it in code.
What the phone earns
DMS from pallet-ailoos-rewards, per era, proportional to verified units of work against the era's budget. The budget is set by the clock, so the pool cannot be exhausted by demand. First payout on the public testnet: pending an operational step. No APY is promised, and a store listing that promised one is being corrected.
Status
Ailoos App is in internal testing on Google Play (com.ailoos.ailoos). The debug build was used for the verification above; the release build is the next thing to test on the device.
Based on the mobile-training verification (2026-09-08) and the Ailoos production audit.