Skip to main content
Verification in Prado depends on what kind of execution happened (for example, it’s not the same verifying a Python function than an HTTP request). For this, we introduce runtimes. A runtime defines:
  • how an execution is performed
  • what kind of evidence can be produced
  • how verification works
Different runtimes have different verification guarantees. Prado currently supports three runtimes:
  • HTTP (different Prado nodes make the HTTP request at the same time and results are signed)
  • JavaScript (Prado runs the JS function and creates a verifiable receipt)
  • Python (Prado runs the Python function and creates a verifiable receipt)

​
Two classes of runtimes

Prado runtimes fall into two fundamental categories:

​
1. Deterministic runtimes (JS, Python)

  • Output depends only on:
    • code
    • input
  • No external dependencies
  • Execution can be replayed exactly
➡️ Verification = recomputation

​
2. Non-deterministic runtimes (HTTP)

  • Output depends on:
    • external APIs
    • time
    • network conditions
  • Execution cannot be replayed
➡️ Verification = attestation

​
How verification works by runtime

​
JavaScript / Python (deterministic)

What happens
  1. Prado executes the code once
  2. A receipt is generated with:
    • code hash
    • input hash
    • output hash
How verification works
  1. The verifier re-runs the same code locally
  2. The output is recomputed
  3. The output hash is compared to the receipt
What this proves
  • The output must follow from the code and input
  • Prado cannot fake the result without being detected

​
HTTP (attestation-based)

What happens
  1. Multiple HTTP nodes perform the same request
  2. Each node:
    • records the full request and response
    • hashes a canonical observation
    • signs the hash
  3. Prado aggregates these attestations into a receipt
  4. Raw observations are returned as disclosures
How verification works
  1. The verifier checks the receipt’s integrity
  2. Each disclosed observation is:
    • canonicalized
    • hashed
    • matched against the receipt
  3. (Optionally) node signatures are verified
What this proves
  • Which nodes observed what
  • That the observations were not modified
  • That the receipt commits immutably to those claims
What it does NOT prove
  • That the API response is “correct”
  • That the data should be trusted
  • That nodes agree with each other
Those judgments are left to the verifier.