> For the complete documentation index, see [llms.txt](https://chainedx.gitbook.io/chainedx-protocol/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://chainedx.gitbook.io/chainedx-protocol/3.-identity.md). # 3. Identity In any social network, users must be consistently identified to engage in most use cases. The protocol defines a concept of identity to represent users in social graph relationships called a Social Identity. Social Identities are pseudonymous, user owned, and default private. These properties are essential to the user’s overall control of their identity. Each Social Identity is an instance of a smart contract that defines the interface for interaction with the user’s data, standardizing both how users can share their data with others and how they can delegate certain rights to others to act on their behalf. **3.1 Pseudonymity** **The Protocol** requires Social Identities to be pseudonymous. These identities provide a consistent record of an online actor not directly tied to an offline identity. To implement pseudonymity, the smart contract instance that represents a Social Identity is owned by an anonymous blockchain wallet address, which allows a user to provide cryptographic proof of ownership. A person may share one Social Identity across multiple contexts, such as family, business, and gaming, or create multiple identities to keep different facets of life separate. Each Social Identity is tied to a separate uncorrelated wallet address and stored in a user’s blockchain wallet. **3.2 User Ownership and Delegation** With most existing social networks, a user’s access to their account can be suspended or revoked unilaterally by the site owner, based on any number of actual or perceived behaviors, resulting in the user’s loss of access to their personal data and social graph. Even though the user populated their account with data and social connections, the site usually owns the account that the user created. A key goal of the protocol is for users to

Figure 1: Social Identity Ownership Structure

own their data. Three techniques are used to ensure that people own their Social Identity: direct contract instances, rights delegation, and identity verification. **3.2.1 Direct Contract Ownership** Many blockchain-based projects that employ smart contracts use a single contract instance to store multiple user ownership rights. While this approach works for simple use cases, such as non-upgradable smart contracts associating ERC-20 token values with unique addresses, storing multiple users’ data in a single smart contract can suffer from brittleness when upgrading contract logic (if upgrades are even supported). In the case of a common contract tracking multiple users’ data, either all or none of the users must be upgraded at the same time, whether the upgrade is a logic change or a bug fix. This also means someone other than each user has the right to upgrade the common contract. Whoever has upgrade rights ultimately controls the contract, and therefore the functionality of the contract and the data it stores. The protocol uses a separate contract instance for each user’s Social Identity, and guarantees that each user’s wallet address retains sole ownership of their respective contract instance. One major ramification of direct contract ownership is that the user is the one who must choose if and when to change the functionality of their smart contract. If upgraded contract logic becomes available, the user chooses whether to update their contract. This avoids the case of an outside party having unilateral rights to change the behavior of the contract without the user’s consent. By empowering users to control what contract logic is used, the protocol ensures that a user always has the ability to revert to any previous or alternate version of the contract logic if there is any question of contract integrity. An outside party in possession of unilateral upgrade rights would be equivalent to the status quo, meaning that existing social network providers have the power to revoke user account access. For a Social Identity, no third party has this capability. Our “design by contract” approach provides another extension to ownership: complete implementation change. Although we expect most users to use the same implementation, other implementations may arise to cover unique use cases since the protocol is designed to be interface first. We imagine that businesses and marketing groups, for example, may

Figure 2: Cost Shifting

desire to control a Social Identity using a different set of rules than the default implementation. **3.2.2 Rights Delegation** A Social Identity allows users to delegate certain rights to third parties to act on their behalf. This ability is accomplished by creating a system to delegate trust using the user’s wallet address as owner and sole authority to grant new permissions. All granted permissions can be revoked in the same fashion. Both actions are simply operations on the smart contract. The delegation of rights never removes the user’s ownership of their Social Identity. When delegating rights, it is also possible to limit third-party access to specific actions. Though third-party “bad actors” who receive rights may be able to take actions on the user’s behalf until access is revoked, they cannot escalate their actions to ownership rights. Rights delegation also allows for cost shifting. Most blockchains have transaction processing costs associated with smart contract invocations. By allowing a third party to invoke actions on behalf of a user via that user’s smart contract, the user—without 7 sacrificing ownership—can benefit from the third party’s payment of the transaction fee associated with the invocation. A simple example would be an ad-supported social networking client that pays the transaction fee for a user when posting a new image or video. This concept can also be extended to Social Identity creation by having the user sign a request with their blockchain wallet address private key, authorizing a Social Identity to be created on their behalf. This signed request would be passed off chain to a third party, who would then pay the fee to create a Social Identity, but with the user’s address as the owner. Such cost shifting is a key element to initial adoption, since it does not require users to own any cryptocurrency to create or use a Social Identity. [**3.2.3 Identity Verification**](#user-content-fn-1)[^1] Through rights delegation, some invocations of the smart contract that represent the user’s Social Identity may be made by third parties. To ensure that only authorized delegates make such calls, all smart contract functions that allow third-party delegate invocations require the third party to be in the user’s authorized list of delegates and to have the sufficient permissions to invoke the intended action. Blockchain transactions track the wallet address associated with each transaction. Thus, each action taken by an authorized third party can be traced back to the delegate, verifying the identity of the invoker. Delegates who engage in unauthorized activity can be identified and their permissions revoked. Actions previously taken by the abusing party can be refuted by the owner. **3.3 Attributes** People using social media often choose to expose parts of their identity, or at least the identity that they inhabit on social media. Users can attach claims and metadata to their Social Identity. The most common metadata used on social media are display name and avatar, but can extend to claims about the user’s real-world identity, such as name, age, or professional certifications. By using this mechanism, services may be created that verify a user’s real identity, similar to Twitter’s verified accounts, except open for all to use rather than only those who Twitter has “determined to be an account of public interest.”\[4] "Identity in the ChainedX social graph is represented as individually owned smart contracts on a public blockchain, ensuring user control, security, and transparency in digital interactions." When users own their data and it is stored on the blockchain, portability manifests differently than the traditional export/import paradigm. Data is shared with services instead of stored in services. People can use more than one service at a time while continuing to synchronize data between services. While public data is readable by anyone, private data is controlled through providing a plaintext copy of the data or providing decryption keys to the service. As a paradigm for portability, sharing requires the ability of a user to revoke access to a service that the user no longer desires to use. Two types of data fall outside the protocol’s protections: plaintext copies and public data. When a user shares data with a service, technical controls in the protocol can no longer protect the user’s data. Instead, control of that copy of the data is governed by the terms of service and the applicable laws governing the service. Depending on jurisdiction or other factors, the European Union General Data Protection Regulation,\[5] California Consumer Privacy Act,\[6] Lei Geral de Prote¸ca˜o de Dados,\[7] and similar regulations may provide coverage, but they are outside the scope of the protocol. By definition, public data is accessible to all and is also governed by local law. Unlike previously shared data, user control of the creation and sharing of new data is absolute. The user can stop any undesired plaintext sharing and public data publishing. If the user has shared a decryption key with a service, the user must change their encryption key to disable a service’s access to new private data. [^1]: --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://chainedx.gitbook.io/chainedx-protocol/3.-identity.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.