Serve AI compute, earn ANM

What a provider does

Inference on Animica is not served by a central API box. When a request arrives at the OpenAI-compatible endpoint (animica.dev/v1, or a paid key from the console), it becomes an AICF job, and whichever registered worker claims it runs the model and returns the response. The worker signs a proof-of-inference receipt with its ML-DSA-65 key (domain animica.ai.proof-of-inference.v1) binding the model, a hash of the prompt, a hash of the output and the sampling seed, so the response can be verified and replayed offline with animica ai verify. Providers are therefore accountable for what they serve, and a client never has to trust the gateway.

A provider's obligations are the ones in the SLA: accept assigned jobs, return results within the latency target, stay available, and pass quality checks including trap prompts with known answers. Heartbeats carry the worker's capability snapshot and load; the registry keeps an exponentially decaying health score and routes only to healthy, active providers.

How to join

The shortest path is the animica CLI. It registers the worker, binds your payout address, and claims jobs for the tiers you enable. animica up goes further and plans every earning activity the machine can support (proof-of-work, ENA useful-work, model serving, and Bittensor serving on a GPU with 16 GB or more of VRAM), paying all of it to one ANM address.

    pip install --upgrade animica

# Serve inference as a registered AICF worker, paid to your address.
# Tiers: standard, small, flagship (flagship wants a GPU).
animica miner aicf-worker start --address anim1zqp... --tiers standard,small,flagship

# Or let the CLI pick everything it can run on this machine (PoW + ENA + serving)
animica up --plan     # show the plan first
animica up
  

The lower-level registry flow in docs/tutorials/PROVIDER_GPU.md shows the pieces the CLI automates: a provider identity derived from your registry key (provider:<sha3_256(pubkey || alg_id)[:12]>), capability flags (ai, quantum), an endpoint and region, a stake, and periodic heartbeats. Attestation bundles (TEE evidence for AI, facility certificates for quantum) are part of the registry specification; the reference worker runs without a TEE today.

    # Registry and staking flow from docs/tutorials/PROVIDER_GPU.md
python -m aicf.cli.provider_register --rpc $RPC_URL --chain-id 1 \
  --id "$PROVIDER_ID" --name "$PROVIDER_NAME" --caps AI \
  --endpoint "$PROVIDER_ENDPOINT" --region "$PROVIDER_REGION"

python -m aicf.cli.provider_stake --rpc $RPC_URL --chain-id 1 --id "$PROVIDER_ID" --amount <nANM>
python -m aicf.cli.provider_heartbeat --rpc $RPC_URL --chain-id 1 --id "$PROVIDER_ID" --print

# Read the registry back
curl -s -X POST https://rpc.animica.org/rpc -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"aicf.listProviders","params":[]}'
  

Hardware

Requirements come from the live model registry (GET https://aicf.animica.org/api/models, checked 2026-08-23), which lists a runtime floor per model. A GPU is optional for the small and standard tiers and expected for flagship; CPU-only workers can still serve embeddings and small models, more slowly.

How you get paid

Two flows are documented. The first is per-job: each model has a price in nANM per input token, per output token and per request, and the registry records how that price is split. For aicf-chat-1 the split is 85% to the provider and 15% to the treasury; for aicf-embed-1 it is 82/18. Rates and splits are shown on the pricing page and come from the same registry endpoint. Verified receipts release the provider share and update reputation.

The second flow is the block subsidy. Since block 75,000 the coinbase is split 50% to the miner, 25% to the treasury and 25% to inference providers; the inference share is paid pro-rata to workers with claims in that block's window, and any unclaimed portion rolls to the treasury. The AICF epoch model in docs/AICF.md describes credits per block, epoch finalisation two blocks after the epoch ends, and idempotent pro-rata claims limited to 100 epochs per transaction. Provider balances and payouts are visible through aicf.getBalance and aicf.claimPayout.

SLA and penalties

The defaults in docs/aicf/SLA.md (network policy can override them):

Measurements are aggregated per epoch with exponentially weighted windows; new providers get grace epochs with reduced penalties. Missed heartbeats lower health, and prolonged faults move a provider to JAILED. Stake unlocks linearly after the lock period on unstake, with a cooldown after slashing.

Current scale, stated plainly

As of 2026-08-23 the AICF status endpoint reports one registered provider and zero in-flight jobs or settlements, while the ENA useful-work layer (the CPU-side of the same earning story) reports about 146,000 verified jobs from 71 contributors. The free inference endpoint is served by the miner network and the foundation subsidises it. In other words: the accounting, registry and receipt machinery are live, the provider market is early, and a new provider today is joining a small registry rather than competing in a crowded one. The live counts are on the Network and Status pages and are never rounded up.

Before you commit hardware

• Rewards are paid in ANM; check the ANM/USDT market on NonKYC yourself before estimating revenue. This site gives no price forecasts.
• Mining and serving compete for the same machine; animica up --plan shows what it would run.
• Keep the worker's key separate from your main wallet and back up the payout address's mnemonic.
• Expose metrics locally only; the worker's Prometheus exporter is not meant to be public.

Sources

docs/ANIMICA_2026_STATE.md · docs/tutorials/PROVIDER_GPU.md · docs/aicf/PROVIDER_REGISTRY.md · docs/aicf/SLA.md · docs/AICF.md · python/README.md · core/network_params.py (FORK_TREASURY_25) · live aicf.animica.org/api/status and /api/models, pool.animica.org/api/ena/stats on 2026-08-23