v1.0 · Early accessThe TDCC App is rolling out with the pilot network

Verified compute,in one app.

The TDCC App is the console, CLI, and API for the compute network. Submit a job, watch it run on matched hardware, verify the result, and pay only for work that is accepted.

Console + CLI + SDKOne product surface
Train · Tune · Infer · EvalFull model lifecycle
Accepted work onlyVerification before billing

Built to route across mixed capacity

Data-center clusters Certified micro-clusters Independent GPU hosts 80GB-class accelerators 48GB-class accelerators 24GB consumer GPUs CPU-side pre/post processing

What the app is

One interface over a network of
machines you never have to manage.

Underneath the app there are schedulers, secure runtimes, model compatibility checks, verification policies, reputation signals, and settlement. In the app there is a job, a state, and a receipt.

01 · DescribeWorkload type, model, data, deadline, budget, acceptance rules.
02 · MatchThe router picks capacity that fits memory, speed, price, and reliability.
03 · RunExecution happens in an approved, isolated runtime with live telemetry.
04 · VerifyOutput is checked against acceptance criteria before it is billed or paid.
A

For AI teams

Run training, fine-tuning, inference, and evaluation without operating a fleet. One key, one project, one bill.

B

For data centers

Turn idle capacity into recurring, screened demand. Publish hardware, availability, and price; earn on accepted work.

C

For agents and tools

A machine-callable API so autonomous workflows can buy compute the same way a developer does.

The console

Every job, every host, one screen.

The network view shows where work is running right now: which region, which hardware class, how far along, and what still needs to be verified.

inference.batch 1,240 items finetune.lora qwen2.5-7b eval.suite 18 checks TDCC router match · isolate · verify eu-central · DC 8× 80GB · verified us-east · cluster 4× 48GB · running ap-south · hosts 22× 24GB · queued
Verified & settled Running Queued / matching Illustrative view of the console network map.

Submit

Describe the job. Not the machine.

You never browse a list of instances. You state what the workload needs and what you are willing to pay, and the router does the rest — including failover when a host drops mid-run.

  • Workload templates for inference, embeddings, transcription, image generation, LoRA/QLoRA fine-tuning, evaluations, and synthetic data
  • Constraints for VRAM, hardware class, region, deadline, and maximum spend
  • Automatic requeue to another host if execution fails or stalls
  • Dry-run estimates before a job is committed Planned

Observe

Watch work as it happens.

Every job streams state. You see the stage it is in, the host class running it, throughput, retries, and logs — without SSH, without a bastion, without a separate monitoring stack.

  • Live stages: matching, provisioning, running, verifying, settled
  • Streaming logs and progress events over SSE, plus webhooks per project
  • Per-job cost accrual against the budget you set
  • Alerts on stall, requeue, and verification failure Planned

Verify & settle

A receipt for every accepted job.

Verification is the product. Each completed job carries an acceptance record: what ran, where, against which criteria, and what was paid out. Work that fails the check is not billed to you and is not paid to the host.

  • Acceptance criteria attached to the job, not negotiated after the fact
  • Redundant or sampled verification passes depending on workload type
  • Host reputation updated from verified outcomes, not from self-reporting
  • Optional on-chain settlement records via Avalanche or Solana integrations Planned

Why an app, not a marketplace

Pay for accepted work.
Not for idle hours.

Renting a machine transfers every risk to you: wrong hardware, a stalled run, a silent failure at hour six. The TDCC App moves that risk to the network. The unit you buy is a verified result.

$50KRaised through star.fun in roughly 10 minutes, at an $8M campaign valuation, July 2026
4Workload families in the v1.0 scope: training, fine-tuning, inference, evaluation
0Machines you provision, patch, or babysit yourself
Accepted = billable unit

Rejected and requeued work sits outside the billing ring by design.

Workload catalogue

What you can run on day one.

Each workload type carries its own acceptance rules, so verification means something different for a transcription batch than it does for a fine-tune.

WorkloadAPI typeTypical hardwareAcceptance basisStatus
Batch inferenceinference.batch24–80GBSchema validity + redundant samplingv1.0
Open-model hostinginference.endpoint48–80GBHealth checks + latency SLOv1.0
Embeddingsembeddings24GB+Deterministic re-computation on a samplev1.0
Audio transcriptiontranscribe24GB+Sampled re-run + agreement thresholdv1.0
Image generationimage.generate24–48GBOutput integrity + policy checksv1.0
LoRA / QLoRA fine-tuningfinetune.lora48–80GBEval delta on a held-out setv1.0
Evaluationseval.suite24GB+Reproducible scoring runv1.0
Synthetic datasynth.generate24GB+Schema + duplication checksv1.0
Agent workloadsagent.runMixedStep traces + budget ceilingsPlanned
Full pre-trainingtrain.fullMulti-node clustersCheckpoint continuity + eval gatesPlanned

Bring your own environment

Your runtime, our routing.

Jobs execute inside approved, isolated runtimes. Supply a container, pick a maintained base image, or point at an open-weight model and let the app assemble the environment.

ContainersOCI images with pinned digests
Orchestrated clustersData-center capacity pools
Bare metalCertified micro-clusters
Independent hostsScreened consumer GPUs

Developer surface

Four ways in. One job model.

The console, the CLI, the SDKs, and the REST API all speak the same object: a job with constraints, a state machine, and a receipt. Whatever you automate in one, you can inspect in another.

  • REST API — create, inspect, cancel, and stream jobs
  • CLI — submit from a YAML file, tail logs, verify receipts
  • SDKs — Python 3.10+ and TypeScript / Node 18+
  • Events — SSE streams and per-project webhooks
# submit a batch inference job
curl https://api.decentralizedcompute.company/v1/jobs \
  -H "Authorization: Bearer $TDCC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "inference.batch",
    "model": "llama-3.1-8b-instruct",
    "input_uri": "s3://acme-eval/prompts.jsonl",
    "accept": { "min_verifications": 2 },
    "budget": { "max_usd": 40 }
  }'

Preview interfaces from the early-access build. Request shapes may change before the API is declared stable.

App specifications

The details, in full.

Everything below describes the version 1.0 early-access scope. Items marked Planned are on the release path and are not available yet.

Product nameTDCC App — console, CLI, SDKs, and job API for The Decentralized Compute Company network
Version1.0, staged early access alongside the pilot network
ConsoleResponsive web app; current Chromium, Firefox, and Safari; desktop-first layout with a mobile job view
CLItdcc for macOS (Intel/Apple silicon), Linux x86-64 and arm64, and Windows via WSL2
SDKsPython 3.10+ and TypeScript / Node 18+; both wrap the same REST surface
APIREST over HTTPS, JSON payloads, cursor pagination, idempotency keys on job creation
EventsServer-sent events per job; per-project webhooks with signed payloads
AuthenticationProject-scoped API keys with rotation; console sign-in per organization. SSO and SCIM Planned
RolesOwner, admin, developer, read-only; keys inherit project scope, never organization scope
IsolationJobs run in approved, isolated runtimes on screened hosts; images are pinned by digest
Data handlingEncrypted transport; artifacts scoped to the submitting project; customer job data is not used to train TDCC models
VerificationPer-workload acceptance criteria, redundant or sampled passes, reputation updated from verified outcomes
Failure policyStalled or failed executions are requeued to another host; unaccepted work is neither billed nor paid out
Billing unitAccepted job. Usage metering, budget ceilings per job, and per-project spend reports
SettlementOff-chain payouts at launch; optional on-chain settlement records via Avalanche and Solana integrations Planned
RegionsRouting across connected data centers and host regions; explicit region pinning Planned
QuotasPer-cohort concurrency and spend limits during early access; raised on request
ObservabilityLive stage timeline, streaming logs, per-job cost accrual, exportable receipts
SupportDirect founder contact during early access; documented escalation path at general availability

Release plan

How the app reaches you.

The app ships in cohorts so that routing, verification, and settlement are proven on real workloads before the network widens.

Cohort 0Now · closed

Design partners

A small set of AI teams and host operators run real jobs against the console and API. Workload schemas, acceptance criteria, and host requirements are hardened against their feedback.

Cohort 1Early access

Pilot network

Console, CLI, Python and TypeScript SDKs, and the job API become available to accepted early-access teams. Inference, embeddings, transcription, image generation, evaluations, and LoRA fine-tuning are in scope with measured service levels.

Cohort 2Capacity expansion

Wider capacity, richer routing

Additional data centers and qualified GPU operators are onboarded. Region pinning, reputation-weighted routing, alerting, and dry-run cost estimates land in the app.

General availabilityProduction

Open sign-up

Stable API versioning, organization SSO, automated settlement, agent workloads, multi-node training, and enterprise controls for sustained production use.

App FAQ

Straight answers.

Is the TDCC App available today?

Not to everyone. It is rolling out in staged early-access cohorts alongside the pilot network. Request access below and you will be placed in the next opening.

Do I have to choose a GPU?

No. You describe the workload, its constraints, and your budget. The router picks capacity that fits. If you do need specific hardware, you can constrain the class, memory, or region and the router will only match hosts that satisfy it.

What happens if a host fails mid-job?

The job is requeued to another eligible host. You are not billed for the failed attempt, and the failed host is not paid for it.

How is verification different per workload?

Deterministic workloads such as embeddings can be re-computed on a sample and compared exactly. Generative workloads rely on schema checks, redundant passes, and agreement thresholds. Fine-tunes are judged on evaluation deltas against a held-out set. The criteria travel with the job.

Is my data used to train anything?

No. Job inputs and artifacts are scoped to the submitting project and are not used to train TDCC models.

Do I need crypto to use the app?

No. The compute layer is chain-agnostic and the app works with ordinary accounts and billing. On-chain settlement records through Avalanche and Solana are an optional integration path, not a requirement.

Can I provide capacity instead of consuming it?

Yes. Data centers, micro-cluster operators, and independent GPU owners can register hardware, availability, and pricing, then earn on accepted work. Host onboarding is reviewed manually during early access.

Early access

Start running everything.

Tell us what you want to run — inference volume, a fine-tune, an evaluation suite — or what capacity you can contribute. Early-access cohorts are reviewed by hand.