Understanding Verification

The Phi Protocol supports three types of verification for Creds:

1. File Upload (Merkle type)

2. API (Backend-authorized by verifier signature)

Before creating a Cred, it's crucial to review the different requirements and use cases to decide on the appropriate verification type.

Please review the different requirements and use cases per cred and decide on your verification type.

(Future) EAS approach: It enables verification without a separate backend (only Phi backend is needed), and the credential creator can manage an updatable eligible list.

---

1. Merkle Type (File Upload)

Merkle type Creds use a file upload system to establish a fixed list of eligible addresses at the time of creation.

Key characteristics:

• Uses a CSV file with eligible addresses

• The first row of the CSV must include 'address' as a header

• Suitable for scenarios where the eligible list is fixed and doesn't need updates

• Efficient for large lists of addresses

Process:

1. Prepare a CSV file using data sources such as Dune or POAP

2. Upload the CSV file during Cred creation

3. A Merkle tree is generated from the address list

4. The Merkle root is stored on-chain for efficient verification

For an example CSV file, see: Beacon Chain Genesis Depositor CSV Example

Benefits:

• Gas-efficient verification

• Suitable for large-scale airdrops or fixed eligibility criteria

Limitations:

• Cannot update the eligible list after creation

• Not suitable for dynamic eligibility criteria

cred-examples/1-beacon-chain-genesis-depositor.csv at main · PHI-LABS-INC/cred-examplesGitHub

2. Signature Type (API)

Signature type Creds use an API for case-by-case verification by the verifier.

Key characteristics:

• Requires setting up an API for verification

• Allows for dynamic and flexible eligibility criteria

• Suitable for scenarios where eligibility may change or requires real-time checks

Process:

1. Set up an API that performs verification

2. Implement a handler function that checks credentials and creates signatures

3. The API should return a JSON object with 'mint_eligibility' and 'signature' properties

Example implementation: Verify Basic API Example

Benefits:

• Allows for dynamic eligibility criteria

• Can incorporate off-chain data or complex logic

• Flexibility to update verification logic without changing the Cred

Limitations:

• Requires maintaining an active API

• May have higher operational costs

3. Ethereum Attestation Service (EAS) - Future Implementation

The EAS approach will enable verification without a separate backend and allow credential creators to manage an updatable eligible list.

Key characteristics:

• Uses on-chain attestations

• Allows for updatable eligible lists

• Reduces reliance on separate backends

Process (to be implemented):

1. Register a schema using the SchemaRegistry contract

2. Create attestations on-chain using the registered schema

3. Optionally expand attestations off-chain

Benefits:

• Decentralized verification

• Updatable eligibility lists

• Reduces infrastructure requirements for verifiers

When choosing a verification type, consider the nature of your Cred, the expected changes in eligibility over time, and your capacity to maintain any required infrastructure. Each type has its strengths and is suited to different use cases within the Phi Protocol ecosystem.