Title: Proposal_for_an_on_chain_Smart_Profiles_Standard
Category: Web

Author: hurricane247
Date: 2025-02-20T10:01:14.154Z

Summary
We propose a new on-chain standard for Smart Profiles, enabling user-centric identity management on Ethereum. This standard allows for decentralized profile schemas, profile minting, IPFS storage of profile data, and cryptographic attestation mechanisms.
Motivation
Current Web3 identity solutions lack composability and flexibility. By introducing a standardized approach to creating and managing user profiles on-chain, we can enable:

Decentralized, permissionless profile schema publication
User-owned profile minting with cryptographic attestations of verified data and claims
Interoperability across dApps while maintaining user privacy

Specification


On-chain Profile Schemas

Profile schemas can be defined and deployed as smart contracts.
The schema registration mechanism is inspired by Ethereum Attestation Service (EAS).
Anyone can publish a profile schema, allowing flexibility for different applications.



Profile Minting

Users can mint profiles adhering to any of the published schemas.
Minted profiles exist as SBTs on user wallets which contain on-chain references to IPFS-hosted profile documents.
The on-chain profile includes an IPFS CID, similar to how NFTs store metadata.



IPFS-Based Profile Storage

Profile documents stored on IPFS consist of two parts:

Public Data: Readable by anyone, useful for public credentials or reputation systems.
Private Data: Encrypted using client-controlled keys.


Clients can use MetaMask Snaps or Lit Protocol for encryption and access control.



Attestation Mechanism

Profile data can be attested by the profile issuing party using EAS, allowing:

On-chain attestations for key profile attributes.
Off-chain attestations for private or large datasets.


This enables verifiable claims and proofs for both public and private data.



Benefits

Decentralization: No central authority controls the schema or profiles.
Interoperability: Profiles can be used across different dApps and ecosystems.
Privacy-Preserving: Users control access to their private data with encryption.
Verifiable Identity: Attestations allow for provable identity claims (on-chain and off-chain).

Current State of the art
We have already created the whole profiles framework in ceramic network. You can find the schemas and various profiles built with it here:



docs.plurality.network



Structure of a Smart Profile | Plurality Network





We have also recently launched an MVP of a smart profiles wallet where we are using these ceramic network based smart profiles in production:


x.com


Plurality Network (@PluralityWeb3) on X
@PluralityWeb3

MVP is leveling up, and we’ve captured it all in this video. 📹

Watch how Smart Profiles are making Web3 onboarding seamless, customizable, and AI-powered.

📹 Full tour inside—don’t miss it!

#SmartProfiles #Web3 #CryptoWallet #Blockchain #dApps #WalletSDK #ProfileSDK #AI









We have an open-source repo that acts as SDK to manage smart profiles.

github.com




GitHub - Web3-Plurality/plurality-smart-profile-utils: A package for managing Smart Profile entities,...
A package for managing Smart Profile entities, including their data model, utilities, and core functionality






Next Steps
We invite feedback from the Ethereum community on:

Enhancements to the schema publication mechanism.
Best practices for encryption and key management.
Integration with existing identity and reputation systems.

Smart profiles are meant to be a public good like ENS/EAS. We imagine infinite use cases which will open up the Ethereum ecosystem to endless possibilities not limited to mostly finance.
Would love to hear thoughts from the community! Let’s collaborate on refining this idea into a robust standard for on-chain user profiles.
Team:

Hira Siddiqui (x.com)
Mujtaba Idrees (x.com)

Author: bumblefudge
Date: 2025-02-20T12:33:16.094Z

hurricane247:

Profile documents stored on IPFS


Who’s pinning? How fetched?

Author: hurricane247
Date: 2025-02-20T12:49:31.852Z

IPFS nodes are pinning. There should be an incentivization model built around it for pinning.
They are fetched through Smart Profiles SDK (linked in the post).

Author: mujtaba.idrees
Date: 2025-02-20T13:06:09.767Z

Actually even if we consider simple ipfs we still need to pin the docs, you’re right. In the end, we need an incentivization model to pin those documents or the user can pin it themselves to keep the profiles available.

Author: bumblefudge
Date: 2025-02-20T13:24:44.353Z

mujtaba.idrees:

In the end, we need an incentivization model to pin those documents or the user can pin it themselves to keep the profiles available.


I’m not sure you’re responsible for business models or tokenomics, per se, but it might be nice to keep going since you’ve got this much momentum specifying all the interfaces and data models.  In other words, if the goal here is to have an e2e standard for all the moving parts, I would suggest also including some concrete details (if not full interfaces and data models) for what happens at that “aggregation layer” of “Identity Providers” that enroll and pin the profiles of end-users, and ideally some kind of migration standard for how one moves to another if the pinner/host/hub that enrolled you goes broke or winds down. Even if, in what you’ve built so far, there is only one provider (or you are the only provider), this would at least enable a theoretical “second implementation” (perhaps Ceramic-free and classic-IPFS-based, or swapping out other core elements) to come along more easily and deliver “credible exit” for anyone who sets up these profiles and wants them to outlive the registrar that original pinned them.

Author: bumblefudge
Date: 2025-02-20T13:31:58.449Z

hurricane247:

They are fetched through Smart Profiles SDK (linked in the post).


I meant are they being pulled from a public gateway or one from a service-provider like Pinata or one provided by Plurality, but it seems like the answer is the first, if this how smart profiles get pulled out of the IPFS DHT:


github.com


Web3-Plurality/plurality-eth-online/blob/d5ebb2b303e49a6a8bd83df316b33de26d2ea3b4/packages/api/src/controllers/PermawebUploadController.ts#L99

      
                  },
                  {
                    headers: {
                      pinata_api_key: process.env.PINATA_API_KEY,
                      pinata_secret_api_key: process.env.PINATA_API_SECRET,
                    },
                  }
                );
                console.log(resp.data.IpfsHash);
                //const pinataobj = resp.data.IpfsHash;
                res.status(200).send({ url: `https://ipfs.io/ipfs/${resp.data.IpfsHash}` }).json();
          
          } catch (e) {
            //console.log(e);
                res.status(500).send(e);
          }
          });*/

Author: mujtaba.idrees
Date: 2025-02-21T07:44:28.237Z

You are correct in pointing out that we might need

A Ceramic-free, classic-IPFS-based second implementation to provide a “credible exit” and ensure profiles outlive the registrar.

Since this post focuses on profile standards as a data format, we deliberately omitted protocol-level details.
The concern about outliving the registrar is entirely valid. If we develop a smart contract-based profile system, we will need a reliable pinning or indexing service backed by a decentralized protocol.
Possible Approach:

Indexing nodes could pin and index IPFS documents, helping maintain data availability.
A decentralized indexing protocol could allow efficient retrieval of profile data.
Reward mechanisms might be needed to incentivize node operators, but any model that introduces fees for simple profile queries would need careful evaluation.

Author: mujtaba.idrees
Date: 2025-02-21T07:53:53.969Z

(post deleted by author)

Author: mujtaba.idrees
Date: 2025-02-21T08:12:55.776Z

(post deleted by author)

Author: hurricane247
Date: 2025-02-21T09:53:55.538Z

You raise an important point about the need for a:

Ceramic-free, classic-IPFS-based alternative to ensure profiles remain accessible beyond the lifespan of any single registrar.

Since this discussion is centered on profile standards as a data format, protocol-level implementation details were intentionally left out.
One reason we initially adopted a system like Ceramic was its ability to link IPFS documents with blockchain addresses without requiring an on-chain registry. This approach simplified key management but also introduced limitations when considering long-term persistence beyond any single protocol. A key challenge is ensuring profiles remain available in a decentralized and verifiable manner.
To address this, a more generic and flexible protocol could be designed—one that provides reliable pinning and indexing of profiles without relying on a single provider.
Possible Approach:

Indexing nodes could pin and index IPFS documents, helping maintain data availability.
A decentralized indexing protocol could allow efficient retrieval of profile data.
Reward mechanisms might be needed to incentivize node operators, but any model that introduces fees for simple profile queries would need careful evaluation.