This EIP proposes a standard for decentralised, interoperable user profiles known as Decentralised Profiles. Profiles are implemented as Soul Bound Tokens (SBTs) that are immutable, non-transferable, and tied to unique identifiers across multiple blockchain networks. The standard provides a unified structure for user metadata, including dApp-specific customisation, default profiles, and seamless cross-chain compatibility. Profiles can be leveraged for identity management, reputation systems, and personalised dApp experiences.
Existing solutions for decentralised identity and user profiles lack cross-chain compatibility, dApp-specific customisation, and standardisation. A unified approach is essential to:
Each profile is identified by:
username: User-defined, chain-unique string.network_slug: Short identifier for the chain (e.g., eth, polygon, xion).soul: Fixed suffix indicating soul bound token.Example:
john@eth.soul
alice@polygon.soul
Each profile is tied to a DID:
Example:
did:ethereum:0x123...
did:xion:xion1abc...
The profile metadata structure is designed to balance extensibility, usability, and compatibility with decentralized storage systems like IPFS. Metadata will adhere to the following schema:
Here's an example using the structure above:
Visibility Logic:
The design of the Decentralised Profile Standard was guided by the need for a unified, interoperable user profile system that can operate seamlessly across all blockchain networks. Current solutions, such as ENS profiles or Gravatar, either lack cross-chain functionality, are centralised, or do not allow users to customise profiles for specific dApps. This standard addresses these shortcomings while ensuring simplicity, security, and scalability.
Decentralised Identifiers (DIDs)
did:<chain>:<address> format provides a globally unique identifier for profiles. This aligns with the decentralised identity movement and ensures compatibility with broader DID frameworks.Decentralised Profile
username@networkslug.soul) makes profiles human-readable and chain-specific while maintaining a universal structure. The .soul suffix clearly identifies profiles compliant with this standard.dApp-Specific Avatars
Soul Bound Tokens (SBTs)
Registry and Resolver Architecture
Compatibility with Existing Standards
Default and dApp-Specific Metadata
On-Chain Data Minimisation
Access Control
dApp Identification
Pure On-Chain Metadata
Direct Integration with ENS
Fully Centralised System
Non-SBT-Based Implementation
The Registry and Resolver architecture, combined with off-chain metadata storage, ensures that profile can scale with the growth of the blockchain ecosystem. New chains, metadata types, and customisations can be added without disrupting the core functionality or introducing breaking changes.
The design balances simplicity, extensibility, and user control, making it well-suited for adoption across a wide range of dApps, wallets, and blockchains.
The standard includes the following interface:
ISoulProfileSoulProfileOf course, this can be extended to prepare a full registry and resolver according to ENS or similar standards. Refer to Rationale above for more information about the same.
The Decentralised Profile system is designed to ensure smooth integration with existing decentralized applications (dApps) and platforms, while offering an upgrade path for future enhancements. Below are key considerations for backwards compatibility:
ENS Compatibility: The system adheres to the naming conventions and standards specified in ERC-137 (Ethereum Name Service). This ensures that any dApps or tools already using ENS-compatible names can easily integrate profiles without additional changes.
Flexible dApp Identification: By using wallet addresses to identify dApps, the system avoids the need for centralized registration of dApps. Any existing or new dApp that interacts with Ethereum or compatible chains can use the standard by simply passing its address as a parameter.
Default Avatar Fallback: If no specific avatar is set for a dApp, the system gracefully falls back to the default avatar. This ensures that even older dApps that do not implement the latest features can continue to work seamlessly.
Upgradeable Contracts: By implementing a proxy-based architecture for all major contracts (resolver, registry, profile), the system ensures that future upgrades or changes in functionality can be deployed without disrupting existing data or workflows. Upgrades are conducted through secure proxy mechanisms like TransparentUpgradeableProxy.
Chain Agnosticism: The use of decentralized identifiers (DIDs) and chain-specific network slugs ensures interoperability across chains. This allows profiles to maintain consistency regardless of which chain they originate from, ensuring compatibility with multi-chain ecosystems.
Profile system should prioritise robust security to protect user data and prevent unauthorized access.
Access Control: Users can set visibility for their avatars (public or private). This is enforced at both the resolver and registry levels to ensure unauthorized entities cannot access private avatars. Functions that modify state (e.g., setDefaultAvatar, setDappAvatar) are protected with access controls, ensuring only the profile owner can make changes.
Data Privacy: Sensitive metadata is encrypted before storage on decentralized storage systems like IPFS or Arweave. Visibility flags ensure users can control who can view specific profile elements.
Reentrancy Protection: Functions modifying state implement the checks-effects-interactions pattern or leverage ReentrancyGuard to prevent reentrancy attacks. For example, setDappAvatar ensures that all validations are performed before updating the state.
Input Validation: All user inputs (e.g., username, visibility, dApp) are validated to ensure they meet specified criteria. Invalid or malicious inputs are rejected to prevent injection attacks or other exploits. Visibility is restricted to predefined values ("public" or "private").
Immutable DIDs: Decentralized identifiers (DIDs) for users are immutable once created. This prevents spoofing or unauthorized changes to user identities.
Fallback Mechanisms: The system provides fallback mechanisms for fetching avatars. If a dApp-specific avatar is not found, the default avatar is returned, ensuring smooth operation without errors.
Upgradeable Contracts: Proxy contracts are used to allow for upgrades while preserving state. Upgrades are performed securely via a multi-signature governance process to minimize risks.
Rate Limiting: Rate-limiting mechanisms can be implemented to prevent spam or abuse of profile creation and update functions.
Audits and Best Practices: The contracts are designed following best practices and are to be audited regularly by independent security firms. Dependencies (e.g., OpenZeppelin contracts) are reviewed and kept up to date to mitigate vulnerabilities.
dApp Address Verification: All dApps interacting with the system must be identified by a valid address. This ensures that unauthorized or spoofed entities cannot manipulate profiles or fetch restricted data.
Phishing Mitigation: User-facing dApps are encouraged to clearly display information about interactions on-chain. Users should be warned about potential phishing attacks and advised to interact only with verified dApps.
Gas Optimization: Operations are optimized to prevent gas exhaustion during execution, which could lead to incomplete transactions. This ensures that even on congested networks, the system remains functional.
Secure Fallback Functions: Fallback functions are implemented securely to prevent accidental Ether transfers or denial-of-service attacks.
Copyright and related rights waived via CC0.