ENA

ENA: useful work, retrieval and training on Animica

ENA is the CLI-first layer in the animica package (python/animica/ena/) for four things: a model-backed agent runtime, an embedding-backed retrieval layer, a useful-work job lifecycle with deterministic receipts, and a training orchestrator. Contributors run ENA workers on ordinary machines and are paid in ANM through the pool. The coordinator lives at pool.animica.org (ena.animica.org redirects there).

Contribute compute Useful work: designed vs live Mining guide

Jobs verified — Receipts — Training runs — Contributors — connecting…

Fetched by your browser from https://pool.animica.org/api/ena/stats. On 2026-08-23 it reported about 146,000 verified jobs, 71 contributors and 10 training runs.

What ENA is, concretely

The name gets used loosely, so here is the precise scope from docs/ena/overview.md. ENA has four production-facing pillars: a model runtime with pluggable providers (a deterministic extractive fallback, OpenAI-compatible endpoints, Ollama) and an auditable plan/act/observe loop whose every tool call is traced to SQLite and logs/audit.jsonl; a retrieval layer that chunks documents, stores embeddings from a real provider, and answers keyword, semantic and hybrid queries; a useful-work lifecycle with stable job hashes, typed states, verification records and machine-readable receipts; and a training orchestrator that tracks manifests, runs, checkpoints, artifacts and evaluation reports.

What ENA is not: it is not a consensus rule, and it is not the mainnet PoIES useful-work proof. ENA receipts are mirrored into a local AICF protocol-state ledger and credited to the contributor's address through the pool; the documentation describes direct chain anchoring of receipts as an explicit boundary that depends on a node-side submission hook. The useful-work article separates the designed PoIES proof path from the ENA path that actually pays contributors today.

How contributors earn

An ENA worker claims jobs from the coordinator, runs them locally, and submits results. The coordinator verifies the result (deterministic checks, score) and issues a receipt with a reward. Verified receipts accrue to the worker's ANM address as credits, paid out by the pool on its schedule alongside mining rewards. Every reward, whether from proof-of-work, useful-work, training or serving, lands on the same address, which is why animica up binds a single payout address for the whole machine.

Install and start a worker

    pip install --upgrade animica
animica ena config init
animica ena doctor

# Contribute CPU useful-work (paid to your ANM address via the pool)
animica ena worker start --worker-id "$(hostname)"

# Or run everything the machine supports (PoW + ENA + serving) in one command
animica up

Jobs are CPU-friendly by design: scraping, extraction, cleaning, deduplication, chunking, classification, labelling, summarisation, embedding and indexing, plus dataset construction and training preparation. A laptop can run them. GPU machines can additionally take fine-tuning runs.

Job types: scrape, extract, clean, dedupe, chunk, classify, label, summarize, embed, index, eval, dataset_build, training_records, train_prepare.

The job lifecycle

The same lifecycle is exposed on the CLI for anyone who wants to create work, not only consume it. A job gets a deterministic job_id, job_hash and aicf_task_id at creation, moves through typed states (awaiting payment, submitted, claimed, completed, verified, rejected), and ends with a receipt and an on-chain export envelope.

Create, claim, run, verify, receipt

    animica ena jobs create --type extract --source https://example.com
animica ena jobs list
animica ena jobs claim --worker-id miner-01 --types scrape,extract,index
animica ena jobs run   --worker-id miner-01 --types scrape,extract,index
animica ena jobs verify <job_id>
animica ena jobs receipt <job_id>
animica ena jobs export-onchain <job_id>
animica ena credits show --miner-address anim1zqp...

Every receipt carries these fields, which is what makes it checkable after the fact:

job_id · job_hash · manifest_hash · worker_id · event_timestamps · input_refs · output_refs · result_hash · verification_hash · score · reward · export_payload_hash

The receipt hash is deterministic (SHA3 over canonical fields), so two parties holding the same inputs compute the same result_hash and verification_hash. The export-onchain payload is the envelope a chain-side consumer would ingest; the documentation is explicit that the node-side consumer is the next boundary rather than something to assume.

Training

ENA training prepares manifests with dataset split records, launches runs, tracks checkpoints and artifacts, resumes interrupted runs, and evaluates results against a configured model provider. Two backends exist: command, which invokes an external trainer you supply, and python_transformers, a local path that works when the optional datasets and transformers dependencies are installed. The heavyweight GPU stack is therefore external by design; ENA owns orchestration, manifests, receipts and artifact tracking.

Dataset to fine-tune

    animica ena collect build-dataset crawl.jsonl --raw-out raw.jsonl --manifest dataset.json --split
animica ena train prepare --dataset raw.deduped.jsonl --out train_manifest.json \
  --base-model <model> --backend command --auto-split \
  --launcher-command "python external_trainer.py --manifest {manifest} --output-dir {output_dir}"
animica ena train run --manifest train_manifest.json
animica ena train status <run_id>
animica ena train eval --run-id <run_id> --model-provider ollama --model llama3.1

Retrieval and the agent runtime

The same package gives you a working local RAG stack: animica ena scrape url and scrape crawl (robots-aware, with depth and request caps, optionally sitemap-assisted), index build to chunk and embed, and search --hybrid or summarize to query. The agent loop persists sessions and traces, so an answer can be audited back to the documents and tool calls that produced it. Legacy hashing vectors remain as a fallback provider only.

Status, honestly

Live: worker onboarding via the CLI, the job lifecycle, verification, receipts, local credits, the coordinator statistics you see above, and training orchestration with the command backend.
External by design: the model or embedding endpoint itself, the GPU trainer when using the command backend.
Documented as a boundary: direct node-side anchoring of ENA receipt envelopes; credits are paid through the pool rather than enforced by consensus.
Not the same thing: PoIES useful-work proofs in block headers, which the reference miner does not produce on mainnet.

An older document, docs/ENA.md, describes an "Embedded Neural Agent" inference service with its own fee schedule (animica ena infer, animica ena pricing). It predates the current layer; treat docs/ena/ and docs/ena_overview.md as current.

Sources

docs/ena/overview.md · docs/ena_overview.md · docs/ena_useful_work_and_mining.md · docs/ena_training.md · docs/ena_operator_quickstart.md · docs/ANIMICA_2026_STATE.md · python/README.md · live pool.animica.org/api/ena/stats (2026-08-23)