No new chain
Launch a GPU growth program and product layer on top of Aleph Cloud and LibertAI.
- Public GPU/operator catalog
- Useful-capacity scoring
- Direct-host UX
- LoRA/adaptor marketplace
- Usage and royalty dashboards
Ecosystem evolution proposal
More GPUs, more usage, less subsidy theater.
A practical plan to grow Aleph Cloud and LibertAI: use the infrastructure that already exists, attract useful GPU supply, add transparent receipts and royalties, and only build a chain if it becomes load-bearing.
What we should stop doing
The first proposal tried to fuse Bittensor, Akash, Phala, Pearl, and a LoRA marketplace into a new chain. That is too much surface area before demand and supply are proven.
Stop
Do not build another generic AI cloud
Aleph Cloud already has CCNs, CRNs, VMs, confidential VMs, GPU instances, credits, and payment rails. The next layer should strengthen this ecosystem.
Stop
Do not lead with emissions
At current token prices, big rewards are either too small to attract serious operators or too dilutive if they become meaningful.
Stop
Do not overclaim verification
TEE privacy, customer-verifiable attestation, model identity, and output correctness are different claims. Keep the public story precise.
The immediate goal is not a new token system. The immediate goal is to make useful GPUs want to join Aleph because they can earn from real LibertAI and Aleph demand.
The ecosystem we already have
The proposal should tie into these existing pieces instead of replacing them.
CustomersDevelopers, agents, enterprises, model users
PaymentsCredits, API keys, x402 USDC, direct-host payments
LibertAIManaged API, routing, direct-host discovery, model serving
Aleph CloudCRNs, VMs, CVMs, GPU instances, IPFS volumes
OperatorsGPU owners earning from real usage and reputation
Managed path
Most developers use the LibertAI API. They want a clean endpoint, stable pricing, and no infra complexity.
Direct-host path
Advanced users can discover hosts and connect directly. This is the decentralization escape hatch and the right path for stronger privacy/verification.
Three paths, sequenced
These are not mutually exclusive forever. The decision is order and evidence.
Protocol layer
Make the existing ecosystem more auditable without launching a sovereign chain.
- Signed inference receipts
- Operator reputation roots
- Royalty ledger roots
- EVM anchoring if useful
- Challenge path for direct-host users
Chain/appchain
Only if demand proves it: a GPU coordination layer for Aleph + LibertAI.
- GPU registry and bonds
- Usage-backed mining
- Slashing for fraud
- Royalty settlement
- ALEPH/LTAI integration
| Criterion | Path A | Path B | Path C |
|---|---|---|---|
| Speed | High | Med | Low |
| GPU pull | Medium, demand-dependent | Medium-high, more trust | High if rewards are credible |
| Token dilution | Low | Low to medium | High risk if done too early |
| Best use | Now | After receipts matter | Only after demand gates |
GPU acquisition without emission waste
The network should pay for useful capacity, not for the mere existence of a registered GPU.
Best
Demand routing
Operators with better uptime, latency, price, attestation, and model availability get more LibertAI/Aleph traffic.
Best
Time-boxed floors
Guarantee selected GPUs revenue for 30-90 days, then require paid utilization. Treat it as supply acquisition, not permanent emission.
Strong
Future operator points
Non-transferable points based on served work, uptime, and useful capacity. Future upside without immediate liquid token sell pressure.
Strong
Hardware financing
Use partner financing, revenue share, reserved capacity, and customer prepayments to bring GPUs online without relying on emissions.
Careful
Mining narrative
If used, mining should mean useful-capacity mining: earn by serving paid workloads and passing checks, not synthetic work forever.
Avoid
Registration rewards
Airdrops for registered capacity will attract farmers, idle GPUs, fake supply, and short-term token sellers.
| Mechanism | Token cost | GPU pull | Farmability |
|---|---|---|---|
| Paid demand routing | None | High if demand exists | Low |
| USDC/credit utilization floors | None to low | High | Medium |
| Future operator points | Deferred | Medium-high | Medium |
| Hardware financing | None to low | High | Low |
| Immediate ALEPH/LTAI emissions | High | Medium | High |
| Registration airdrop | High | Low-quality | Very high |
The new product wedge
Aleph/LibertAI already cover generic private inference. The differentiated layer is a marketplace for models and adapters that creates new demand for GPUs.
Author publishesAdapter manifest, license, evals, royalty terms
Network ranksUsage, quality, safety, compatibility, price
Operators hostPre-warm popular adapters on useful GPUs
Customers callManaged API or direct-host, credits or x402
Revenue splitsOperator, author, platform/protocol
Why this helps GPU supply
Commodity GPU rental is a price war. Adapters create differentiated demand. Operators earn more when they host the models and adapters users actually want.
Why this may justify a chain later
Per-token royalties across permissionless hosts are hard to enforce off-chain. If the marketplace works, settlement and slashing become more valuable.
If there is a chain, this is what it should do
A chain should be a GPU coordination layer for Aleph + LibertAI. It should not become a second cloud or a weak TAO clone.
Own
GPU registry
Operator identity, linked CRNs/hosts, GPU commitments, region, tier, bond, reputation root.
Own
Usage-backed rewards
Epoch rewards weighted mostly by paid usage, successful jobs, uptime, and verified availability.
Own
Slashing
Fake capacity, forged/stale attestation, receipt fraud, double claims, and reserved-job refusal.
Own
Receipts
Hashes, roots, signatures, payment references, model/adaptor ids. Not raw prompts or outputs.
Own
Royalties
Adapter/base-model author splits across permissionless hosts.
Avoid
Customer friction
Customers should still use credits, API keys, x402, or direct-host payment. Do not make them bridge to call a model.
ALEPH role
Cloud substrate economics, CRN/CCN alignment, credit conversion, and infrastructure value capture.
LTAI role
Application-layer alignment, marketplace incentives, useful GPU operator upside, and possibly insurance/slashing for LibertAI jobs.
Roadmap with gates
Spend engineering and incentives only when the previous step produces evidence.
0-30 days
Trust and access cleanup
Document customer-verifiable TEE flow, direct-host discovery, managed vs direct-host trust model, GPU onboarding, and x402 examples.
Gate: avoid strong verifiable-inference marketing until customer verification is public.
1-3 months
GPU growth program
Recruit strategic GPU operators, launch useful-capacity scoring, offer strict floors, and route LibertAI traffic by reliability.
Gate: 25+ useful GPUs, 30-50% subsidized capacity paid-utilized within 90 days.
2-6 months
Adapter marketplace
Launch manifests, commission 20-50 adapters, add royalty ledger, and pre-warm top adapters on selected GPUs.
Gate: at least 5 adapters with paid usage before building royalty chain logic.
4-9 months
Receipts and reputation
Add signed inference receipts, public operator scorecards, and optional EVM anchoring for roots.
Gate: users/operators must actually use receipt data before validator overbuild.
9-18 months
Chain decision
Prototype a chain/appchain only if demand exceeds supply, serious operators want permissionless onboarding, and legal review supports token-linked rewards.
Gate: $100k+/month GPU/inference revenue and 25+ serious operators waiting.
One-slide summary
The simplest version to share internally.
Do now
- Finish public TEE verification flow.
- Make direct-host discovery first-class.
- Launch useful GPU growth program.
- Route demand to good operators.
- Add adapter marketplace and royalties.
Do later, only if gates pass
- Anchor receipts and royalty roots.
- Add operator bonds and slashing.
- Create usage-backed mining.
- Launch appchain if it increases GPU supply.
- Use ALEPH/LTAI carefully, not as blanket emissions.
Source research lives in ref/proposal-v1/ and ref/landscape/aleph-libertai.md.