# Digital Social Assets

## Overview

Social elements like profile pictures and profile frames play a crucial role in users' online identities and their interactions on social platforms. As the emergence of Web3 technology has allowed us a new understanding of tokenized digital assets and is changing our perception of digital asset engagement, there has been a push to turn social elements into digital social assets. However, despite their potential, social assets face numerous challenges within the current digital ecosystem:

* **Interoperability Issues**: Siloed platforms hinder the seamless transfer and integration of social assets across different digital environments. This fragmentation restricts users' ability to leverage their assets effectively.
* **Unclear Capabilities**: The functionalities or properties of a digital asset are embedded within that asset, which may hold significant value but may not be immediately apparent.
* **Trust and Verification**: Authenticity and trustworthiness are crucial in the digital realm. However, centralized platforms struggle to combat issues such as fake news, fraudulent accounts, and manipulated content, undermining the credibility of social assets and social elements.

To tackle these challenges, we introduce a standardized protocol to represent a social asset.

## The Social Asset

In our protocols, a [social asset](../key-concepts/digital-social-asset) consists of three parts:

1. The tangible resource files that implement the asset, i.e., JPEG image files, MP4 video files, GLTF 3D model files, etc.
2. A piece of information that describes what the asset is, how it can be used, and who the owner is. We call this information **metadata.**
3. Information that guides the blockchain transaction flow. This information must be stored on the blockchain and is called **token data**. On an EVM, a smart contract may read token data to decide who can operate or how to operate on a social asset. This same rule applies to protocol executors on BTC.

A social asset is associated with a blockchain token as depicted in the diagram below. The token can either be an inscription on BTC or an NFT on an EVM-compatible smart contract.

<figure><img src="https://3069188829-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3nDAq4lacfCiEG8HjrGh%2Fuploads%2FENX01A5Vup3PBl6WqozM%2FToken%20Data.png?alt=media&#x26;token=7943f5f1-f9ee-4d55-ad59-1c9ae97968e1" alt="" width="563"><figcaption></figcaption></figure>

Metadata and resource files can either be on-chain or off-chain. The protocol is blockchain-agnostic and does not stipulate for this matter. If they are stored off-chain, a proper hash function (like SHA256) needs to exist to ensure the immutability of off-chain data.

<figure><picture><source srcset="https://3069188829-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3nDAq4lacfCiEG8HjrGh%2Fuploads%2FYw5soJRRpLmOiK584nqk%2Fstorage%20-%20dark%20mode.png?alt=media&#x26;token=34026552-ccb3-4a74-99dd-e39029c9a885" media="(prefers-color-scheme: dark)"><img src="https://3069188829-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3nDAq4lacfCiEG8HjrGh%2Fuploads%2FafASxzgtxeEq4UAyQXII%2FOn%20chain%20or%20off%20chain.png?alt=media&#x26;token=c5d686fb-54c8-4289-8072-b33d8abe3481" alt="" width="563"></picture><figcaption></figcaption></figure>

## Structure

A digital social asset by itself holds value in that it can be traded on the public market. This value is derived from an asset's intrinsic qualities, particularly its scarcity and uniqueness, which contribute to its perceived value and significance. This underscores an asset's value as a status symbol or collectible, while its [**capabilities**](#capabilities) encompass the various ways it can be utilized and leveraged in real-world social scenarios.

These capabilities may include:

1. AI Characters / AI Chatbot;
2. AI Assistants;
3. Profile Pictures;
4. Profile Frames;
5. Badges;
6. Chat Bubbles;
7. Readable Content like Storyboards, Books, etc.

They are either visible to users or merely functional. In this standard, we explicitly differentiate the capabilities of a digital social asset from the asset's [**essential information**](#essential-information). A single asset can have multiple capabilities.

<figure><img src="https://3069188829-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3nDAq4lacfCiEG8HjrGh%2Fuploads%2F9Alr4QbfFiQp3GGiosZa%2FStructure.png?alt=media&#x26;token=ee81b129-97fc-4114-ba22-1c5de0b34a07" alt="" width="563"><figcaption></figcaption></figure>

Each capability can have multiple additional properties that describe its capability. These additional properties are given by the capability provider. Take an AI Character, for example. The name and description are essential fields that must be included, but an editable field with structured dialogue examples or other text content may also be provided. This field then helps to shape the personality of the character.

Various stakeholders may also be associated with a social asset and share the profits of that asset. These stakeholders may hold different roles (e.g., author, publisher) that are also important to the value of an asset. A "[**credits**](#credits)" block is added to an asset's metadata in order to represent these roles and ensure their authenticity.

All the above data blocks are integrated into the digital description of a digital asset, while the asset's resource files may be integrated separately. This description of information is called **metadata** and is written in a JSON format we define in this protocol. The table below lists all possible values (fields with an asterisk are required):

<table data-full-width="false"><thead><tr><th>Field</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>name | title*</td><td>string</td><td>The name of the asset can be up to 50 characters.<br>See subsection <a href="#name-and-description">Name and Description</a>.</td></tr><tr><td>type*</td><td>integer</td><td>ID of the asset type.<br>See subsection <a href="#type">Type</a>.</td></tr><tr><td>description</td><td>string</td><td>Description of the asset</td></tr><tr><td>image | preview*</td><td><strong>file</strong></td><td>Image preview.<br>See subsection <a href="#preview-image">Preview Image</a>.</td></tr><tr><td>youtube</td><td>string</td><td>Promotional YouTube URL</td></tr><tr><td>set</td><td>string</td><td>An ID for the asset set that the asset belongs to.<br>See subsection <a href="#asset-set">Asset Set</a>.</td></tr><tr><td>background</td><td>string</td><td>Background color for the preview</td></tr><tr><td>attributes | properties</td><td>array</td><td>Asset traits.<br>See subsection <a href="#traits">Traits</a>.</td></tr><tr><td>id*</td><td>integer</td><td>The blockchain ID. If the asset is an NFT, then <code>id</code> is the NFT id. If the asset is an inscription, then <code>id</code> is the inscription id.</td></tr><tr><td>entity*</td><td><strong>file</strong></td><td>Main entity of the asset.<br>See subsection <a href="#entity">Entity</a>.</td></tr><tr><td>rarity</td><td>integer</td><td>How rare it is.<br>See subsection <a href="#rarity">Rarity</a>.</td></tr><tr><td>contract | p</td><td>string</td><td>Contract address for ETH or protocol for inscriptions.<br>See subsection <a href="#source">Source</a>.</td></tr><tr><td>localization</td><td>dictionary</td><td><p>How to localize any text field. </p><p>Follows <a href="https://github.com/ethereum/ercs/blob/master/ERCS/erc-1155.md#localization">ERC</a> standard.</p></td></tr><tr><td>capabilities</td><td>array</td><td>What the asset can do.<br>See section <a href="#capabilities">Capabilities</a>.</td></tr><tr><td>credits</td><td>array</td><td>Asset stakeholders.<br>See section <a href="#credits">Credits</a>.</td></tr></tbody></table>

The data type `file` is a special kind of dictionary that represents an embedded file or a referenced file:

<table data-full-width="false"><thead><tr><th>Field</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>mimetype*</td><td>string</td><td>File type</td></tr><tr><td>bytes</td><td>string</td><td>base64 encoded string of the file buffer</td></tr><tr><td>url</td><td>string</td><td>The file reference. An off-chain http/ftp url or an on-chain <code>content/{inscription_id}</code> uri</td></tr><tr><td>hash</td><td>string</td><td>Hex string of the file's SHA256 hash</td></tr></tbody></table>

`bytes` and `url` are mutually exclusive, but one is required. They respectively represent an embedded file or a referenced file. When `url` references an off-chain file, a `hash` must also be provided.

**Token data** is specific to the protocol or contract specified by the `contract` or `p` field. The Token data is formatted and interpreted by the protocol or contract that deployed the social asset. The token data consists of these fields:

<table data-full-width="false"><thead><tr><th>Field</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>price</td><td>string</td><td>The royalty fee to be paid to the minter in BTC</td></tr><tr><td>max</td><td>string</td><td>Maximum allowed mint number</td></tr><tr><td>op</td><td>string</td><td>Operation: Type of event (Deploy)</td></tr></tbody></table>

In [ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol), this data is stored in the smart contract's instance database:

```solidity
mapping(uint256 tokenId => address) private _tokenApprovals;
mapping(address owner => mapping(address operator => bool)) private _operatorApprovals;
```

The difference between token data and metadata lies in the difference between its on-chain or off-chain storage and in its mutability or immutability. Token data is mutable when needed.

## Essential Information

The essential information of an asset includes its name, comprehensive description, preview that is able to be showcased across different platforms, traits, and most importantly, an entity file that represents the asset.

### Name and Description

A social asset should always have a name. The field may be either `name` or `title`, so as to be compatible with various [platforms](https://github.com/ethereum/ercs/blob/master/ERCS/erc-1155.md#erc-1155-metadata-uri-json-schema) and [marketplaces](https://docs.opensea.io/docs/metadata-standards).

The description provides more information about the asset. It is a markdown-compatible string in which rich format is supported.

### Type

The `type` field indicates a social asset's intrinsic type or use, which could be:

<table data-full-width="false"><thead><tr><th>ID</th><th>Type</th></tr></thead><tbody><tr><td>1</td><td>Collectibles</td></tr><tr><td>2</td><td>Artwork</td></tr><tr><td>3</td><td>Event Tickets</td></tr><tr><td>4</td><td>Memberships</td></tr><tr><td>5</td><td>Music and Media</td></tr><tr><td>6</td><td>Gaming</td></tr><tr><td>7</td><td>Real-world Assets</td></tr><tr><td>8</td><td>Domain Names</td></tr><tr><td>9</td><td>Miscellaneous</td></tr></tbody></table>

### Preview Image

A preview image ensures an eye-catching display of the social asset. Different platforms or applications can retrieve this field to display the asset in their catalog.

### Entity

The entity is the core element of any social asset and is meant to be displayed. It provides a visible representation of the asset and should be displayed in high definition.

### Traits

Given by the field named `attributes` or `properties`, traits allow users to define custom properties for an asset.

### Rarity

The rarity field provides an opportunity for users to specify how rare the asset is.

<table data-full-width="false"><thead><tr><th>Rarity</th><th>Description</th></tr></thead><tbody><tr><td>Common</td><td>Level One</td></tr><tr><td>Uncommon</td><td>Level Two</td></tr><tr><td>Rare</td><td>Level Three</td></tr><tr><td>Epic</td><td>Level Four</td></tr><tr><td>Legendary</td><td>Level Five</td></tr></tbody></table>

### Source

The source, given by `contract` or `p`, indicates the origin of this asset. For an NFT, `contract` must be specified as it is the address of the smart contract. For general inscriptions, `p` is optional and is used to indicate the protocol to which it conforms.

### Asset Set

When an asset is assigned to a specific set, `set` is used to specify the unique set ID.

## Token Data

The flexibility of token data enables unlimited blockchain applications, whether on BTC or EVM. For example, a social organization may grant a badge to a member to represent his or her contribution to the organization but not permit the badge owner to transfer that badge to someone else or sell it unless permitted by an administrator. This badge is a social asset now owned by the recipient but unable to be transferred. To implement this constraint, we use token data to represent any limitations of the specific token:

```solidity
mapping(uint256 tokenId => bool) private _tokenNeedsPermission;
```

## Capabilities

By drawing a distinction between the essential information and the capabilities of digital social assets, stakeholders can better understand their value proposition, design innovative applications, and harness their potential to create meaningful experiences and interactions in the digital realm.

We use an `array` field in an asset's metadata to explicitly list out all capabilities the asset supports. Each element of the array is a dictionary containing, at minimum, the following fields:

<table data-full-width="false"><thead><tr><th>Field</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>type*</td><td>integer</td><td>Type ID of the capability</td></tr><tr><td>id</td><td>string</td><td>The identity of the capability</td></tr><tr><td>name*</td><td>string</td><td></td></tr><tr><td>preview*</td><td>file</td><td></td></tr><tr><td>resource</td><td>file</td><td>The file that implements the capability</td></tr></tbody></table>

The `type` field can have the following values:

<table data-full-width="false"><thead><tr><th>ID</th><th>Type</th></tr></thead><tbody><tr><td>1</td><td>AI Character</td></tr><tr><td>2</td><td>Profile Picture</td></tr><tr><td>3</td><td>Profile Frame</td></tr><tr><td>4</td><td>Chat Bubble</td></tr><tr><td>5</td><td>Sticker Pack</td></tr><tr><td>6</td><td>Background</td></tr><tr><td>7</td><td>Readable</td></tr><tr><td>8</td><td>Charm Points Booster</td></tr></tbody></table>

A social asset can have zero, one, or multiple capabilities. Certain capabilities may have an allowance for extra fields than the essential fields provide in order to provide more information about the capability.

### Case Study: AI Character

An AI Character that is able to chat with or assist its owner is one of the most important capabilities that a social asset can have. The AI Character capability consists of additional fields as follows:

<table data-full-width="false"><thead><tr><th>Field</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>greeting</td><td>string</td><td>The initial message your character uses when starting a dialogue.</td></tr><tr><td>avatar*</td><td>file</td><td>An avatar image that enhances the visual appeal and individuality of your character.</td></tr><tr><td>categories*</td><td>string</td><td>Some descriptors or tags relevant to this Character</td></tr><tr><td>imageGen</td><td>boolean</td><td>Would you like this Character to produce images alongside text in conversation?</td></tr><tr><td>personality</td><td>string</td><td>The file that implements the capability, an expansive, unrestricted field capable of accommodating structured sample dialogues or any textual material.</td></tr></tbody></table>

## Credits

The `credits` field covers all stakeholders and the roles they play. It is an array where each element has these fields:

<table data-full-width="false"><thead><tr><th>Field</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>certificate</td><td>file</td><td>A digital certificate</td></tr><tr><td>commonname</td><td>string</td><td>Common name (CN) of the certificate</td></tr><tr><td>address</td><td>string</td><td>Wallet address of the stakeholder</td></tr><tr><td>price</td><td>string</td><td>Royalty for the stakeholder when the asset is recursively re-created.</td></tr><tr><td>role*</td><td>string</td><td>The role that the stakeholder plays</td></tr><tr><td>seis<br></td><td>array</td><td>An SEI list that represents the web2 accounts of the stakeholders across multiple social platforms.</td></tr><tr><td>sigcert</td><td>string</td><td>Metadata signature using the corresponding private key of the <code>certificate</code></td></tr><tr><td>sigaddr<br></td><td>string</td><td>Metadata signature using the corresponding private key of the <code>address</code></td></tr></tbody></table>

A stakeholder can be either:

1. An actual human whose identity is verified by `certificate` and `commonname`.
2. A blockchain wallet address indicated by `address`.

Although they are both optional fields, one of the two must exist. All stakeholders should use their corresponding private key to sign the entire metadata (excluding the signature itself) and store it in the `sigcert` or `sigaddr` fields.

This standard does not specify what values the `role` field could take; the role name or value may be determined by each application.

A stakeholder on any application can be associated with a web2 social account, where the associated web2 account is represented by an [SEI](../key-concepts/sei-social-element-identifier) and is stored in the `seis` field. If an SEI exists in the `seis` field, the respective social platform should act as one of the `credits` that signs the metadata, so that the authenticity of the SEI can be ensured.

The `price` field specifies how much royalty the stakeholder receives when an asset is recursively minted. This protocol supports any single asset having multiple royalty receivers, who can each receive different royalties.

## Example

```json
{
    "name": "Champion #456",
    "type": "1",
    "description": "Prime Eternals are a special tier of Champions that are only issued at a Prime Drop. There are only 7,622 of them, and this special tier of Champions will never be issued again.",
    "attributes": [
        {
            "display_type": "ranking",
            "max_value": 5,
            "trait_type": "Divine Parts",
            "value": 2
        },
        {
            "display_type": "number",
            "max_value": 5,
            "trait_type": "Purity",
            "value": "1"
        }
    ],
    "rarity": "Epic",
    "background": "ffffff",
    "image": {"url": "https://um.clover.space/nft/asset/456.gif", "mimetype": "image/gif"},
    "entity": {"url": "https://um.clover.space/nft/asset/abc.gltf", "mimetype": "imodel/gltf-binary"},
    "capabilities": [
        {
            "type": 2,
            "id": 1234,
            "name": "Unicorn",
            "preview": {"url": "https://um.clover.space/pf/1234.gif", "image/gif"},
            "resource": {"url": "https://um.clover.space/pf/1234", "image/webp"}
        }
    ],
    "credits": [
        {
            "role": "Author",
            "certificate": {"url": "https://clover.space/cert/leonardo.cert", "mimetype": "application/x-pem-file"},
            "commonname": "Leonardo",
            "sigcert": "AA386B69A99E9EAFEE..."
        },
        {
            "role": "Publisher",
            "certificate": {"url": "https://clover.space/cert/medici.cert", "mimetype": "application/x-pem-file"},
            "commonname": "Medici",
            "sigcert": "BB386B69A99E9EAFEE..."
        },
    ]
}
```
