TD TrustDrop Docs

Protocol

How TrustDrop Makes Delivery Provable

TrustDrop turns delivery into a protocol-visible condition for settlement. The seller is paid after the delivery path is backed by commitments, data availability evidence, proof verification, and buyer-recoverable key material.

Protocol Components and Evidence

TrustDrop makes payment and delivery atomic and verifiable. The same original-file commitment also anchors extensible evidence adapters for different asset types. 

flowchart TB
  subgraph Delivery["TRUSTDROP · VERIFIABLE DELIVERY"]
    direction LR
    Seller["SELLER
Publishes encrypted package"]
    Walrus["WALRUS + ORACLE
Encrypted data is available"]
    VSS["VSS · VERIFIABLE KEY DELIVERY
The buyer's key package contains
the asset's real data key"]
    VDD["VDD · VERIFIABLE ENCRYPTION
That key decrypts the stored ciphertext
into the committed original"]
    Contract["SMART CONTRACT
Valid delivery and payment
are atomic"]
    Buyer["BUYER
Recovers the data key
and decrypts the asset"]

    Seller --> Walrus --> Contract
    Seller --> VSS --> Contract
    Seller --> VDD --> Contract
    Contract --> Buyer
  end

  Original["ORIGINAL BLOB ID
Identifies the exact asset"]
  Original --> VDD

  subgraph Evidence["EXTENSIBLE ASSET EVIDENCE"]
    direction LR
    Adapters["ASSET EVIDENCE ADAPTERS
Different asset types use
different evidence methods"]
    Video["VIDEO ASSETS
Verifiable Preview"]
    Structured["STRUCTURED DATA
Verifiable Sampling
Other Evidence"]
    Other["OTHER ASSETS
Asset-specific Evidence"]
    Result["VERIFIABLE EVIDENCE
Proof-backed claims and outputs
bound to the original asset"]

    Adapters --> Video --> Result
    Adapters --> Structured --> Result
    Adapters --> Other --> Result
  end

  Original --> Adapters
  Result -.-> Buyer

  classDef storage fill:#e7f5ee,stroke:#27745a,color:#16211d
  classDef proof fill:#edf1fb,stroke:#4263a8,color:#182033
  classDef contract fill:#f1ebfa,stroke:#7651a8,color:#20182c
  classDef evidence fill:#fff4d8,stroke:#a87619,color:#2c2415
  classDef future fill:#f2f2ee,stroke:#767b75,color:#262826
  class Walrus storage
  class VSS,VDD proof
  class Contract contract
  class Original,Adapters,Video,Structured,Result evidence
  class Other future

Walrus + Oracle prove that the encrypted package is actually available for the buyer to download.

Smart Contract releases payment only after the required delivery and availability checks pass.

VSS · Verifiable Key Delivery proves that the key package created for this buyer contains the asset's real data key.

VDD · Verifiable Encryption proves that this data key decrypts the stored ciphertext into the exact original committed by the seller.

Asset Evidence Adapters let each asset type define appropriate proof-backed evidence: video uses Verifiable Preview, while structured data can use Verifiable Sampling or other evidence.

Other Assets can add their own evidence adapters without changing the verifiable-delivery protocol.

The Problem

Many digital transactions depend on an off-chain promise: the seller says delivery happened, the buyer has to check later, and payment settlement may not be bound to whether the delivered material is recoverable. TrustDrop makes the relevant delivery conditions visible to the protocol before the seller can settle.

The Basic Structure

The buyer's payment is first locked in a channel. The seller then has to complete a delivery path that the contract can verify. The contract does not inspect a large payload directly; instead, it verifies two zk proofs generated by two separate SP1 guest programs.

VSS: Valid Key Material

VSS handles the key-sharing side of the exchange. During purchase, the buyer submits a commitment related to the buyer's purchase secret. During fulfillment, the seller submits encrypted key material that should let this buyer recover the asset key.

The VSS zk program checks that the seller's encrypted key material is consistent with the buyer's commitment and the sale's data key commitment. This prevents a seller from submitting random bytes that look like a key package on-chain but do not actually help the buyer decrypt the file.

VDD: Recoverable Delivery

VDD handles the data-delivery side. It checks the seller's claim that the encrypted payload stored for delivery is tied to the committed asset. This prevents settlement with unrelated encrypted bytes or a corrupted delivery.

The current VDD design uses the structure of erasure-coded data together with ChaCha20-style stream encryption. Erasure coding is linear over byte data, and ChaCha20 encryption is an XOR with a keystream, so the encoded plaintext, encoded keystream, and encoded ciphertext preserve the same XOR relation. This is the homomorphism VDD uses for efficient checking.

With erasure coding, the buyer does not need every original storage piece to recover the file; enough valid encoded pieces are sufficient. The proof samples a small part of the encoded/encrypted structure. If the seller has damaged or replaced enough data to stop recovery, the chance of escaping these checks drops quickly.

In this document, availability means recoverability: the buyer can recover the complete payload from the delivered encrypted data and the key material. It does not merely mean that a storage server returned some bytes.

Settlement

Settlement is only the final step after the protocol has the required evidence: the buyer has valid key material, and the delivered encrypted data is tied to the committed asset with high recoverability confidence. The seller does not get paid just for claiming delivery.