Summary: PADO Network is best understood not as just another AI x crypto brand, privacy SDK, or data-marketplace slogan, but as a specific outsourced confidential-computation control plane built around encrypted data upload, worker-side homomorphic computation, onchain task and fee management, and result re-encryption for the caller. The strongest current materials split the system into storage blockchains for encrypted data, contracts for worker/data/task/fee management, SDKs for upload and retrieval, and worker nodes that execute linearly homomorphic or threshold-FHE-style jobs while the long-run architecture aspires to zkFHE proof generation. That makes PADO a useful comparison point for Primus’ zkTLS stack, TACEO-style private-execution networks, FairyRing-style confidential-computing rails, and Vana-style data-rights systems: the real control surfaces are worker admission, storage dependencies, contract verification, pricing and permission policies on uploaded data, and the still-important gap between the project’s zkFHE framing and its current lower-maturity implementation.
What it does:
Lets data providers encrypt data, upload the ciphertext to decentralized storage such as Arweave or other storage chains, and register pricing plus metadata through PADO contracts
Lets callers submit paid confidential-computation tasks against uploaded encrypted data, passing their own public key so final results can be re-encrypted specifically for them
Uses worker nodes to fetch tasks, run encrypted computation, and submit results back through contract-managed task and fee flows rather than returning plaintext directly to users
Separates worker management, data management, task management, fee management, and worker incentives into onchain contract surfaces while keeping the actual confidential computation offchain
Exposes SDK flows for key generation, encrypted data upload, task submission, task-result retrieval, and optional custom permission-check contracts for who may buy or use a given dataset
Supports both directly registered workers and restaking-linked worker admission through a Primus / PADO AVS path on EigenLayer-style infrastructure, while also documenting AO worker flows
Frames the longer-run network as a zkFHE stack, but documents a current implementation that still relies on LHE or threshold-FHE-style data-sharing paths and plans to add fuller zk-LHE integrity over time
Key claims:
The most useful high-level framing comes from the current Primus docs, which say Primus (formerly PADO) is building secure, permissionless data verification and computation for blockchain and AI, with zkTLS and zkFHE as its two core technologies. That brand drift matters because PADO Network is the computation-side sub-protocol that would be analytically flattened if it stayed filed only under Primus’ broader identity-and-proof story.
The strongest mechanism description is in the network docs and repos, not the homepage copy. Those sources split the system into Workers, PADO Contracts, the PADO SDK, PADO Scan, storage blockchains, and optional restaking frameworks, which makes the actual control plane much more legible than generic confidential AI or data economy rhetoric.
The network docs are unusually explicit that PADO separates consensus from computation: workers perform confidential computation and proof generation offchain, while blockchain contracts handle worker/data/task/fee management and verify result correctness and integrity. That is the clearest reason to keep PADO as infrastructure rather than flattening it into a generic privacy app.
The worker role is more than raw compute. Workers also provide encryption public keys for data upload, may participate in result re-encryption so only the caller can decrypt the output, and sit inside incentive, fee, and registration flows. That makes worker admission and key management at least as important as raw compute throughput.
The current implementation caveat is especially important. The main repo says the initial version uses a linearly homomorphic encryption scheme for data sharing and a plain threshold-FHE version without zk-based integrity assurances, with gradual plans to build toward zk-LHE. So the project’s zkFHE framing is directionally important, but the present system should not be mistaken for a fully realized proof-carrying confidential-computation stack.
The SDK docs expose where practical power can concentrate above the cryptography. Developers choose storage backends, users deposit via EverPay when using Arseeding, data providers set prices, and custom IDataPermission contracts can gate who is permitted to buy or use uploaded data. This makes dataset access policy a first-class governance surface rather than a side detail.
The EigenLayer operator guide exposes another key centralization surface: the system currently supports only Holesky and AO in the documented worker flow, asks operators to run a project-controlled Docker image and setup repo, and explicitly tells them to contact Primus Labs to be added to a whitelist before AVS registration succeeds. That means the present worker market is not yet a cleanly permissionless compute layer.
The storage path is also a meaningful dependency. The worker and SDK docs say encrypted data lives on Arweave or Arseeding today, with EverPay used to cover costs in some flows and other storage chains planned later. So data availability and confidential compute are split across distinct operator and payment surfaces, not bundled into one neutral protocol substrate.
PADO clears the corpus bar because it exposes a reusable mechanism family: encrypted data is stored externally, task routing and fee settlement are contracted onchain, workers hold important key and result-routing roles, and proof-backed confidential computation is still evolving from a more limited LHE / threshold-FHE implementation. That makes it a strong comparison point for any system that claims verifiable private data markets, outsourced confidential compute, or AI-on-private-data infrastructure.
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.