DLT Network

In development

Menu

Verifiable compute network

Verified AI compute. Settled on-chain.

DLT Network is a protocol for verifiable AI compute: workloads run on provider infrastructure, results are checked by independent recomputation, and payment settles through USDC escrow on Solana.

See how it worksExplore the architecture

In development · runs end to end on a local network. The protocol is not on devnet or mainnet yet.

  1. Workload (on-chain): Committed · escrow funded
  2. Provider (on-chain): Assigned, with the buyer's challenge
  3. Execution (off-chain): Isolated run · signed receipt
  4. Verification (off-chain): Re-run by a verifier
  5. Settlement (on-chain): USDC payout or refund
One job’s path. Work runs off-chain. Escrow, commitments, verdicts and payment are recorded on-chain.

Finding compute is easy. Trusting the result is not.

AI teams run more and more work on machines they do not control. A marketplace can list hardware. It cannot show that the job was done, or decide whether it should be paid for.

  • Proof of what ran

    Each result is bound to a signed receipt and an on-chain commitment.

  • An independent check

    A separate verifier re-runs the work before anyone is paid.

  • Payment by rule

    USDC waits in escrow and moves only when the protocol's conditions are met.

How it works

Four steps from payment to payout

Every job follows the same path, and every step leaves a record you can check.

  1. 01

    Fund

    The buyer reserves capacity and pays into USDC escrow held by the program.

    On-chain

  2. 02

    Execute

    The provider's node runs the committed workload in isolation and signs a receipt.

    Provider node

  3. 03

    Verify

    An independent verifier re-runs it and records a verdict on-chain.

    Verifier · verdict on-chain

  4. 04

    Settle

    Verified work pays the provider. Rejected, failed or expired work is refunded.

    On-chain

See all seven protocol steps

Proof of Compute

Compute you can verify.

A result counts only when it can be reproduced. Nobody is paid on the provider's word alone.

Today
Deterministic recomputation by a single DLT verifier. Its verdicts can be challenged before payout.
Not yet
Independent verifiers, non-deterministic workloads such as most training, and hardware attestation.

How verification works

  1. Execute

    Provider node. The node runs the committed workload, with the buyer's challenge.

  2. Receipt

    Provider node. It signs a receipt of what it ran and produced.

  3. Commitment

    On-chain. The receipt hash and output digest go on-chain.

    Output digest
    sha256e8a0 9814 … 9572 3cd3

    Example from a local-network test run. It is an example, not live data.

  4. Recompute

    Verifier, verdict on-chain. A verifier re-runs the workload. The output must match.

  5. Challenge or settle

    On-chain. The buyer can challenge within a window. Then escrow pays out or refunds.

    • Settle
    • Challenge

Settlement

Money waits in escrow until the result is settled.

The program holds the payment, not DLT and not the provider. Protocol rules decide where it goes.

  1. BuyerFunds the job
  2. USDC escrowHeld by the program
  3. ExecutionProvider node
  4. VerificationVerdict + challenge window
  5. Provider payoutExactly the escrowed amount

Refund. Rejected, failed, expired or cancelled: the escrow returns to the buyer.

Challenge. A dispute holds the payment until a separate resolver rules.

Exact amount
The provider receives exactly what was escrowed.
Fixed destination
Set when the work is verified. Nobody can redirect it.
Exactly once
One settlement per job, enforced by the program.

Read every settlement rule

For AI builders

Buy compute with a result you can check

  • Find compute from offers you can read on-chain.
  • Run workloads on provider nodes.
  • Verify results through independent recomputation.
  • Your payment is released only when protocol conditions are met.

Today: deterministic CPU workloads on a local network.

A representative view of the buyer app. The digest is from a local-network test run, not live data.

For compute providers

Offer infrastructure and get paid by rule

  • Register your infrastructure and node keys.
  • Offer capacity at your own price.
  • Execute jobs in isolated containers.
  • Get paid for verified work, to the account you registered.

Public provider onboarding is not open yet.

Architecture

Work runs off-chain. Agreement and payment live on-chain.

AI workloads never execute on Solana. The chain holds hashes, escrow and verdicts, never your data or models.

Explore the architecture

  1. ApplicationOff-chainBuyer app in the browser. The buyer's wallet signs.
  2. DLT coordinationOn-chainTwo Solana programs: identities, offers, escrow, commitments.
  3. Provider computeOff-chainIsolated containers on provider infrastructure.
  4. VerificationOff-chain · on-chain recordRe-run off-chain. The verdict is recorded on-chain.
  5. SettlementOn-chainPayout or refund from escrow, exactly once.

Where it stands

Built in the order trust requires.

Implemented means built, tested and run end to end on a local Solana network. Nothing here is live on a public network.

Protocol
Built and run end to end on a local network (M0–M5)
Complete · local network
Verification
Deterministic recomputation by a single DLT verifier
Implemented · limited
Settlement
USDC escrow, payout, dispute and refund
Implemented · limited
Public network
Not launched. Devnet and mainnet are gated.
Not available

  1. Now

    • Verified vertical slice on a local network
    • Escrow, execution, verification, settlement

  2. Next

    • Production product UX
    • Provider operations
    • Indexer and observability

  3. Later

    • Security hardening
    • Devnet release candidate
    • External audit and mainnet readiness

View development status and the full roadmap

Infrastructure first.

Identity, escrow, execution, verification, then settlement. Public networks come after independent security gates. There is no sign-up, waitlist or token sale.

Explore the architectureHow verification works