Cowrie Research

pado-network

3 min read

PADO Network

  • Name: PADO Network
  • URL: https://github.com/pado-labs/pado-network
  • Category: verifiable confidential-computation network / encrypted-data compute market
  • Summary: PADO Network is outsourced confidential-compute plumbing. Encrypted data sits on external storage, contracts manage workers, tasks, fees, and permissions, and workers run homomorphic jobs offchain before re-encrypting results for the caller. Useful note, but the important part is not the AI x crypto wrapper. It is the control surface around worker admission, storage and payment dependencies, dataset pricing and access policy, and the still-material gap between the project’s fuller zkFHE pitch and its current lower-maturity implementation.
  • What it does:
    • Lets data providers encrypt datasets, store the ciphertext on external storage such as Arweave, and register metadata plus pricing through PADO contracts
    • Lets callers submit paid confidential-computation jobs against those encrypted datasets and receive results re-encrypted to their own public key
    • Uses workers to fetch tasks, run the computation, and submit results through contract-managed task and fee flows rather than returning plaintext directly
    • Separates worker management, data management, task management, fee handling, and permission checks into explicit contract surfaces while keeping the computation itself offchain
    • Supports both directly registered workers and a restaking-linked AVS path, while also documenting AO worker flows
    • Frames the long-run design as zkFHE-backed confidential compute, but documents a current implementation that still leans on linearly homomorphic or threshold-FHE-style paths
  • Key claims:
    • The most useful mechanism description comes from the docs and repos, not the homepage. Those materials split the system into workers, contracts, SDKs, storage dependencies, and optional restaking infrastructure instead of hiding everything behind confidential AI language.
    • The worker role is the real operational center. Workers provide keys for upload flows, run the computation, participate in result re-encryption, and sit inside incentive and registration policy.
    • The present system is not the full zkFHE story implied by the branding. The repo says the initial version uses more limited LHE or threshold-FHE-style approaches, with stronger zk-backed integrity still aspirational.
    • Dataset access policy is first-class. Providers set pricing, storage choices matter, and custom permission contracts can decide who is allowed to buy or use a dataset.
    • The documented EigenLayer-style operator path still shows meaningful permissioning: project-controlled images and setup flows, limited network targets, and a whitelist step via Primus Labs.
    • Storage is a separate dependency surface, with Arweave or Arseeding style paths and EverPay-funded upload flows showing that confidentiality, availability, and payment are not one unified substrate.
  • Whitepaper: No single canonical standalone PADO whitepaper surfaced in this pass. The strongest primary materials were the Primus data-computation docs, the zkFHE Network design doc, the PADO Network repo README, the SDK README, and the EigenLayer worker guide; see ../whitepapers/pado-network-primary-sources-2026-05-14.md.
  • Sources:

Internal linkages

Control surface

  • The point is not private AI branding. The point is who admits workers, where ciphertext actually lives, who pays storage and compute costs, and how dataset permissions get enforced.

  • Treat PADO as confidential-compute market infrastructure under the broader Primus umbrella, not as a neutral privacy primitive.

  • Keep the implementation caveat visible: current mechanism maturity matters more than the maximal zkFHE story.

  • Last reviewed: 2026-06-08 UTC

Graph View