Cowrie Research

pado-network-primary-sources-2026-05-14

3 min read

PADO Network primary sources

Reviewed: 2026-05-14 UTC

Parent-project framing / naming drift

  • https://docs.primuslabs.xyz/data-computation/zkfhe-network/
    • Best short source for the current brand framing that Primus was formerly PADO and that the broader project now presents zkTLS plus zkFHE as its two core technologies.
    • Useful mainly for confirming that PADO Network belongs in the corpus as a distinct computation-side sub-protocol under the wider Primus stack.

Network architecture and role split

  • https://raw.githubusercontent.com/primus-labs/zkFHE-Network-Docs/main/zkFHE-Network.md
    • Best mechanism document in this pass.
    • Used to confirm the role split between Data Providers, Workers, and Callers; the separation of consensus from computation; the existence of PADO Contracts, SDK, Scan, storage blockchains, and optional restaking frameworks; and the threshold / single-key / multi-key workflow variants.
    • Especially important for making worker key roles, result re-encryption, and contract-side fee / incentive settlement explicit.

Current implementation / maturity caveat

  • https://raw.githubusercontent.com/pado-labs/pado-network/main/README.md
    • Best concise implementation-status source in this pass.
    • Used to confirm that the current implementation relies on LHE and a plain threshold-FHE-style prototype without full zk-based integrity assurances yet, despite the broader zkFHE framing.
    • Also the clearest source for current supported environments, storage-chain use, and the high-level workflow from encrypted data upload to task execution and fee distribution.

Worker admission and AVS operations

  • https://docs.primuslabs.xyz/data-computation/build-with-primus/for-workers/eigenlayer-operator-guides/
    • Best source for the operator and worker-control surface.
    • Used to confirm current Holesky / AO support, Docker-image deployment, LHE-key handling, Arweave / Arseeding storage dependencies, EverPay funding for some flows, and the explicit Primus whitelist requirement before AVS registration succeeds.
    • This page is the clearest evidence that today’s worker market is not yet straightforwardly permissionless.

Developer SDK and dataset-policy surface

  • https://raw.githubusercontent.com/pado-labs/pado-network-sdk/main/README.md
    • Best source for the developer-facing control plane.
    • Used to confirm key generation, storage selection, user payment flows, upload / submit / result-retrieval APIs, and the optional IDataPermission contract pattern for custom dataset-access checks.
    • Important for showing that data pricing and permissioning sit above the cryptography as first-class policy layers.

Contract repo surface

Main takeaways from this pass

  • PADO Network clears the bar because it decomposes confidential data computation into reusable layers: encrypted data storage, worker admission, task routing, fee settlement, result re-encryption, and optional permission-gated dataset access.
  • The biggest analytical point is the implementation gap between the project’s zkFHE framing and its currently documented LHE / threshold-FHE-style implementation path.
  • The docs also make clear that practical power can concentrate in worker whitelists, storage dependencies, permission-check contracts, SDK defaults, and offchain funding rails like EverPay / Arseeding.
  • PADO is therefore most useful in the corpus as a comparison point for Primus’ zkTLS stack, TACEO-style private-execution networks, FairyRing-style confidential-computing rails, and Vana-style private-data marketplaces.

Graph View