DLT Network

In development

Menu

Verification and settlement

How a result is checked and paid

DLT Network verifies a result by recomputing it: an independent verifier re-runs the workload and must get the output the provider committed to. Only then, and after a challenge window, does escrow pay out. Today this works for deterministic workloads, checked by a single DLT verifier on a local network.

Proof-of-Compute V1

A result is verified only when it can be reproduced

Four links, each binding the next. None of them is treated as proof on its own.

  1. 1 Provider node

    Execution

    The node runs the exact workload the buyer committed to: a manifest whose hash is recorded on-chain before execution, including a random challenge chosen by the buyer.

  2. 2 Provider node

    Receipt

    The node signs a binary receipt with its registered key. It binds the job, the assignment, the node key version, the challenge and the image, input and output digests.

  3. 3 On-chain

    Commitment

    The node commits the receipt hash and output digest on-chain. After this it cannot change what it claims to have produced.

  4. 4 Verifier · verdict on-chain

    Verification

    The verifier runs ordered integrity and binding checks, re-runs the workload and compares the output. It records Verified, Rejected (with a reason code) or Expired.

What gets committed

Real commitments from one verified job

Recorded in a local-network test run. They are examples, not live data. The full receipt is on the architecture page.

Workload manifest
sha25658b9 905f … c111 7ac3
Container image
sha2561435 8309 … 1f69 5dce
Buyer challenge
1a65 b3ac … 7a8d ad23
Output
sha256e8a0 9814 … 9572 3cd3

The full execution receipt

Assurance

Implemented today, and what is not

What the verifier can establish now, and the stronger approaches that do not exist yet.

  • Signed execution receiptsEd25519 over a fixed binary layout, bound to the node key recorded at assignment time.Implemented
  • Deterministic recomputationThe only method that can mark work Verified. Local network, one workload class.Implemented
  • Single DLT verifierOne DLT-operated verifier key. Its verdicts can be challenged before payout.Implemented
  • Independent verifier setNo second or independent verifier yet. A single key decides, and the buyer's challenge is the check on it.Not implemented
  • Threshold or multisig resolverA single resolver key runs locally today. A threshold resolver is required before any public deployment.Required before devnet
  • Non-deterministic workloadsWorkloads that cannot be re-run to the same output, such as most training, have no verification method yet.Not implemented
  • Hardware attestation (TEE / GPU)Reserved in the protocol and refused on-chain. No hardware attestation is claimed.Not implemented

The verifier

Eleven ordered checks

Any failed check records Rejected with a reason code, and the escrow is refunded.

  1. The node was not revoked.
  2. The committed manifest and receipt are available.
  3. The manifest is canonical JSON and hashes to the on-chain commitment.
  4. The manifest is bound to this cluster, program, job, assignment, provider, node and key version.
  5. The workload is eligible under the assignment's verification policy.
  6. The receipt hashes to its on-chain commitment and has the expected bindings.
  7. The Ed25519 signature is valid for the node key recorded when the work was assigned.
  8. The challenge in the receipt matches the challenge in the manifest.
  9. The run succeeded, and its output digest matches the one committed on-chain.
  10. Timestamps are plausible against the on-chain assignment timeline.
  11. Re-running the workload produces the same output digest.

Timestamps, durations and memory figures in a receipt are provider-reported telemetry and are only checked for plausibility.

Settlement

Money waits in escrow until the result is settled

The buyer pays into escrow held by the program, not by DLT and not by the provider. From there, protocol rules decide whether it goes to the provider or back to the buyer.

  • Provider payoutVerified, and the challenge window passes. Exactly the escrowed amount goes to the payout account the provider registered.
  • Held for a rulingThe buyer disputes within the window. A separate resolver re-checks the work and pays the provider or refunds the buyer. With no ruling in time, the verdict stands.
  • Refund to the buyerRejected, failed, expired or cancelled. The escrow returns to the buyer's own token account. No provider is paid for work that was not verified.

Settlement rules

Amount
Exactly the escrowed amount. No protocol fee is charged today.
Destination
Fixed when the work is verified: the provider's registered payout account. Nobody chooses it at payout time.
Trigger
Anyone can trigger a ready settlement. Nobody can redirect it.
Exactly once
One settlement per job, enforced by the program. Racing or repeated calls fail.
Incident pause
Payouts can be paused for at most 7 days at a time. A pause delays a payment; it never cancels one.
Currency
USDC-denominated. On the local network a test token stands in, and no real funds move.

Technical view

The on-chain model

The accounts behind the money flow in the marketplace program.

Job
Buyer, offer, units, total amount, payment mint, status.
Escrow vault
A token account owned by the program, one per job.
VerificationRecord
One per assignment: verdict, method, reason code, verifier.
SettlementRecord
One per job: amount and payout destination snapshotted at Verified, challenge deadlines, status.
DisputeRecord
At most one per job: reason, evidence hash, ruling.
ProviderPayout
The provider's payout owner, set only by the provider authority.

Instructions: fund_job, cancel_job, expire_job, record_verification, open_dispute, resolve_dispute, settle_job. Payout uses SPL Token transfers from the job’s own vault.