📜Profile & Reputation

Profile NFT

Each Profile is an ERC-721 NFT referring to an individual's identity within the Protocol. It binds a wallet address to a unique username, which makes it easy for others to find them. Profile NFTs are non-transferable to ensure individuals are recognized for their abilities. By preventing the transfer of aliases, we expect to see an organic working environment.

Account Abstraction / MPC

Non-transferrable profile NFTs might raise questions regarding access control, key rotation, and wallet recovery in case of incidents. We are working on Account Abstraction (ERC-4337) adoption using ZeroDev for a better experience.

Claims & Verifiable Credential: Privacy-Preservation with ZKP

Profile claims are essential aspects that contain verifiable information related to work, such as KYC details, previous work experiences, education, skills, references, etc. This information can also be represented as Soulbound tokens.

TaskFi Profile ensures privacy on the blockchain using Zero-knowledge proof (ZKP). Facts about users are verifiable credentials (VCs) consisting of a claim and proof. Users can prove the correctness of their claims without revealing the original content.

Following the W3C Data Model, TaskFi takes advantages of the Iden3 Protocol with the Triangle of Trust consisting of 3 entities:

  • Issuer: Who makes credentials subject to Holders.

  • Holders: Users of TaskFi Protocol who receive attestations from the Issuer and present them to Verifiers.

  • Verifiers: Applications that request Holders for claims and proofs and verify the proof's correctness and criteria.

Our service enables institutes, companies, and firms to utilize zero-knowledge proof for issuing certificates. This feature helps to eliminate the issue of fake endorsements and false claims in résumés.

Claim Issuing

Claims are issued using iden3 generic claim v2. Depending on each claim, there will be different schemas. Schemas are described via JSON-LD documents. Each schema is a soul-bound token.

The subject of the claim, at i1, will be the wallet address for which the claim will be issued. Index slots i_2, i_3, and value slots v_2, v_3 are the data slots for user data. In the process of issuing, the claim will then be signed using the Issuer's key pair with the Baby Jubjub elliptic curve. This curve is designed to work efficiently with zkSNARKs. After signing, we return the Keccak256 Hash of the claim signature (R8 & S) to users for minting SBT. Users can only mint one token (one claim) for each schema. In case of updating, they can revoke by burning and re-issue the SBT.

So, by the end of the minting process, the original claim and the signature could be stored in the TaskFi backend or even on the user's devices (self-sovereign). TaskFi Protocol ensures that personal privacy is preserved while enabling accessibility for the Profile and Reputation with these SBTs.

Query, Proof & Verification

People can have different claims for different traits. It could be a certificate of education, a badge of completion, an endorsement, a proof of membership, or a proof of any verifiable state. These claims build up an identity and a reputation, but they are much more. Applications can use the Profile SBTs as a token-gating service by querying for particular attributes and verifying proofs.

Given a requirement that consists of an operator and a value, users can generate proof if they pass the requirement without revealing the data. TaskFi currently supports the Groth16 zk-SNARK Protocol. Users then send this proof to the verifier with the SBT's token ID to proceed.

Polygon ID also uses the Iden3 stack. While they are trying to build a fully self-sovereign identity solution, we use it with different roles and applications.

Last updated