The inherent characteristics of blockchain technology impose restrictions on its capacity to authenticate data from external sources, thereby greatly limiting the scope of potential applications and the exploration of value within Web3. Hence, the necessity arises for a universal protocol to create attestations, which are essential for confirming the credibility of information. Attestations serve a crucial function whenever there's a need to substantiate or authenticate something.

PADO is a decentralized zk-attestation and computation protocol, with the vision to bridge Web2 and Web3 through authenticated data flow and a network for privacy-preserving computations.

The main functionalities provided by this project are creating attestations from the PADO extension, and recording attestations on the IC network. In addition, the basic attestation framework created in this project supports developers in creating their attestation-based dApps.

To create various data attestations and recorded attestations on the IC network, users can follow the bellowing procedures.

1. Visit the PADO-ICP website to manually download the PADO client (the IC-specific version). Uncompress the downloaded PADO extension, and open it with Chrome browser from chrome:https://extensions/

2. PADO extension is simple and easy to use. The IC-specific version supports the Plug wallet for end users to create their local account. Users can also check this video, or follow the tutorials to freely create any attestations from connected data sources.

3. To submit any attestations to the IC network, simply click the up-arrow button on the attestation card, and straightforwardly follow the process to submit the attestation to the IC network.

4. Users can view the attestation page from PADO-ICP website to see the recorded attestations on the IC network.

The attestation framework can be simply used by developers. The architecture of this project is pre-defined, and this doc gives more explanation on leveraging the framework canisters.

The current framework supports the off-chain signature verification on ERC712, which is a typed structured hashing and signature algorithm commonly used within Ethereum ecosystem. The core advantage of this signature algorithm is to improve the readability and transparency of the off-chain message hash-then-sign operation.

Developers can use ethers.utils.signTypedData and ethers.utils.verifyTypedData to sign and verify EIP712 signatures, as documented here and you can find an example here.

There are some specific definitions and structures within the scope of the basic attestation framework.

Domain The domain parameter is pre-defined here with its value as:

 const domain = {
      name: "PermissionedEIP712Proxy",
      version: "0.1",
      chainId: 80001,
      verifyingContract: "0x0028D4d3E077287e38a674FCBFe092B216809e1D",
    };

And the unchangable parameter domain is a specific configuration for the ICP network. Developers should use the same value in their attestation payload.

Types The types parameter is pre-defined here with its value as:

const types = {
      Attest: [
        {
          name: "schema",
          type: "string",
        },
        {
          name: "recipient",
          type: "string",
        },
        {
          name: "expirationTime",
          type: "uint64",
        },
        {
          name: "revocable",
          type: "bool",
        },
        {
          name: "refUID",
          type: "bytes32",
        },
        {
          name: "data",
          type: "bytes",
        },
        {
          name: "deadline",
          type: "uint64",
        },
      ],
    };

And the unchangable parameter types is a pre-defined meta-data about the attestation structure. Developers should use the same definitions in their attestation payload. you can find the definitions of the related fields in this doc.

You can freely create any attestation schema via the provided backend canister A.

Once the schema is created, the local attestations shall be generated strictly by the created schema, with the specified structures in the EIP712 signature payload.

And in your dApp, you can use canister B to submit attestations (by single one) to the IC, and read the submitted attestations with relevant APIs.

We also provide a simple attestation page to manually view the attestations created with all schemas.

The milestones for this project are documented here.