DLT Network

In development

Menu

Architecture

How DLT Network is built

A technical reference for DLT Network as implemented today: what runs off-chain on provider nodes, what is recorded on Solana, who is trusted for what, and the limits that remain before any public deployment.

Job lifecycle

Seven steps, from discovery to settlement

Every job follows the same seven steps, and each one leaves a record you can check. Money only enters escrow when the job is funded, and only leaves it as a payout or a refund.

  1. 01Discover

    Compute

    Providers publish offers on-chain: unit price, available capacity and expiry. Anyone can read them. Hardware details are declared by the provider.

    On-chainProvider

  2. 02Reserve

    Capacity

    A buyer picks an offer and a number of units. The capacity is reserved in the same transaction that funds the escrow.

    On-chainBuyer

  3. 03Fund

    USDC escrow

    Units × unit price moves into escrow held by the program. From there it can only go to the provider or back to the buyer.

    On-chainBuyerUSDC moves

  4. 04Execute

    Provider node

    The provider's node runs the committed workload in an isolated container, then signs a receipt of what it ran and produced.

    Provider nodeProvider

  5. 05Verify

    Proof of Compute

    An independent verifier re-runs the deterministic workload, compares the result with the committed output, and records a verdict on-chain.

    VerifierVerifier

  6. 06Challenge

    If necessary

    After a verdict the buyer has a challenge window. A dispute holds the payment until a separate resolver rules.

    On-chainBuyer · Resolver

  7. 07Settle

    On-chain

    Verified work pays the provider exactly the escrowed amount. Rejected, failed or expired work is refunded to the buyer.

    On-chainAnyone can triggerUSDC moves

Layers

Off-chain execution, on-chain coordination

Workloads, data and outputs stay off-chain. Solana holds identities, offers, escrow, commitments, verdicts and payments.

  1. Buyer · AI workload

    Off-chain

    The buyer's workload, inputs and outputs. They never go on-chain; only their hashes do.

  2. Marketplace coordination

    On-chain

    Two Solana programs: identities, offers, jobs, escrow, assignments and commitments.

  3. Provider infrastructure

    Off-chain

    The provider agent accepts assignments and runs workloads in isolated containers.

  4. Execution receipt

    Off-chain work · on-chain record

    Signed off-chain by the node key. Its hash and the output digest are committed on-chain.

  5. Verification

    Off-chain work · on-chain record

    The verifier re-runs the workload off-chain and records its verdict on-chain.

  6. Challenge · resolution

    Off-chain work · on-chain record

    Challenge windows and disputes are on-chain. The resolver re-checks work off-chain.

  7. Settlement

    On-chain

    Payout or refund from escrow, exactly once, to destinations fixed in advance.

Components

Two programs and three services

DLT Network components
ComponentRuns onResponsibility
dlt_registrySolana programProviders, nodes, node keys and key versions, status, suspension and revocation.
dlt_marketplaceSolana programOffers, jobs, escrow, assignments, verification records, disputes and settlement.
Provider agentProvider infrastructureAccepts assignments, refuses unsupported work, runs containers, signs and commits receipts.
VerifierDLT-operated serviceChecks receipts and bindings, re-runs deterministic workloads, records verdicts.
ResolverDLT-operated serviceRules on disputes by independent recomputation. Separate key from the verifier.
Buyer appBrowserReads the programs directly over RPC. The buyer's wallet signs every transaction.

Workload isolation on provider nodes

  • No network access
  • Read-only root filesystem
  • Non-root user
  • All Linux capabilities dropped
  • No privilege escalation
  • Process, CPU and memory limits
  • Image pinned by digest

Execution receipt v1

A signed, binary claim, never presented as proof on its own

The node signs a fixed little-endian layout with a domain tag, so no JSON ambiguity can change what was signed. The receipt hash and output digest are committed on-chain by the same node key. Verification then checks the receipt independently.

Node keyKey version 3
5TaN rano JAEk FYVQ 8WW3 DsTC px1q nG3m RgxD yoaK ppyb
Input
sha25666e2 b03c 5d56 d02d 1284 9c4a 02da 69a5 f9fe da2c 9596 e964 032a c555 c82c 2e01
Output
sha256e8a0 9814 7e80 a6aa dbe7 b47d 77db 49e3 8066 1a3f 4f0a d361 b9ed bb8b 9572 3cd3
Workload manifest
sha25658b9 905f 74f0 9304 4af5 c780 9be8 1d85 18f5 6cc1 074c 3600 dc88 448a c111 7ac3
Container image
sha2561435 8309 a308 569c 32bd c37e 2e0e 9694 be33 a9d9 9e68 afb0 f5ff 33cc 1f69 5dce
Buyer challenge
1a65 b3ac b45e 7752 114f 2f51 c03a 4fd8 d20e 4750 bcab d093 8c73 b3ec 7a8d ad23

Example from a local-network test run: real values from one verified job, not live data.

Bound fields: program, job, assignment, provider, node, node key and version, assignment nonce, sequence, manifest, workload, image, input, output and logs digests, challenge, timing, exit code, outcome, execution mode and resource limits, agent version. Timing and resource figures are provider-reported telemetry.

Trust model

Centralized today, but bounded

A single verifier, a separate resolver and a buyer challenge window. Each party can do only what the programs allow, and nobody can choose where escrowed money goes.

What each party can and cannot do
PartyCanCannot
ProviderAccept or refuse work; declare its hardware.Get paid without a Verified verdict, or change its output after committing it.
BuyerCancel before execution; open one dispute per job within the challenge window.Take back escrow for work that was verified and not successfully disputed.
VerifierRecord Verified, Rejected or Expired for completed work.Move funds. Its Verified verdicts can be disputed before payout.
ResolverRule on open disputes, paying the provider or refunding the buyer.Take funds for itself, act outside a dispute, or choose where money goes.
Marketplace authorityRegister verifiers, set terms for future jobs, pause payouts for up to 7 days.Redirect payouts, withdraw escrow, or change terms of jobs already assigned.

Known limits

What is not done yet

  • Runs on a local network only. Nothing is deployed to devnet or mainnet.
  • One DLT-operated verifier and one resolver key. Trust is centralized, but bounded by the challenge window.
  • Only deterministic workloads can be verified. General training and most inference cannot yet.
  • Provider hardware is declared, not attested.
  • No history or reputation until the indexer (M7). Nothing here ranks providers.
  • No public API, SDK or sign-up yet.

See the development roadmap

For developers

Specified down to the byte

Receipts use a fixed binary layout, manifests are canonical JSON, and every rejection has a reason code.

Formats

  • Execution Receipt v1: 33 fields, Ed25519, domain-separated
  • Workload manifest: canonical JSON, hash committed before execution
  • Verification records: 18 append-only reason codes

Access

  • No public API or SDK yet
  • No public RPC endpoint or deployment yet
  • The buyer app reads the programs directly; there is no DLT backend in the payment path