Digital Social Assets
Last updated
Last updated
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.
In our protocols, a consists of three parts:
The tangible resource files that implement the asset, i.e., JPEG image files, MP4 video files, GLTF 3D model files, etc.
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.
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.
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.
These capabilities may include:
AI Characters / AI Chatbot;
AI Assistants;
Profile Pictures;
Profile Frames;
Badges;
Chat Bubbles;
Readable Content like Storyboards, Books, etc.
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.
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):
name | title*
string
type*
integer
description
string
Description of the asset
image | preview*
file
youtube
string
Promotional YouTube URL
set
string
background
string
Background color for the preview
attributes | properties
array
id*
integer
The blockchain ID. If the asset is an NFT, then id is the NFT id. If the asset is an inscription, then id is the inscription id.
entity*
file
rarity
integer
contract | p
string
localization
dictionary
How to localize any text field.
capabilities
array
credits
array
The data type file is a special kind of dictionary that represents an embedded file or a referenced file:
mimetype*
string
File type
bytes
string
base64 encoded string of the file buffer
url
string
The file reference. An off-chain http/ftp url or an on-chain content/{inscription_id} uri
hash
string
Hex string of the file's SHA256 hash
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:
price
string
The royalty fee to be paid to the minter in BTC
max
string
Maximum allowed mint number
op
string
Operation: Type of event (Deploy)
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.
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.
The description provides more information about the asset. It is a markdown-compatible string in which rich format is supported.
The type field indicates a social asset's intrinsic type or use, which could be:
1
Collectibles
2
Artwork
3
Event Tickets
4
Memberships
5
Music and Media
6
Gaming
7
Real-world Assets
8
Domain Names
9
Miscellaneous
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.
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.
Given by the field named attributes or properties, traits allow users to define custom properties for an asset.
The rarity field provides an opportunity for users to specify how rare the asset is.
Common
Level One
Uncommon
Level Two
Rare
Level Three
Epic
Level Four
Legendary
Level Five
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.
When an asset is assigned to a specific set, set is used to specify the unique set ID.
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:
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:
type*
integer
Type ID of the capability
id
string
The identity of the capability
name*
string
preview*
file
resource
file
The file that implements the capability
The type field can have the following values:
1
AI Character
2
Profile Picture
3
Profile Frame
4
Chat Bubble
5
Sticker Pack
6
Background
7
Readable
8
Charm Points Booster
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.
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:
greeting
string
The initial message your character uses when starting a dialogue.
avatar*
file
An avatar image that enhances the visual appeal and individuality of your character.
categories*
string
Some descriptors or tags relevant to this Character
imageGen
boolean
Would you like this Character to produce images alongside text in conversation?
personality
string
The file that implements the capability, an expansive, unrestricted field capable of accommodating structured sample dialogues or any textual material.
The credits field covers all stakeholders and the roles they play. It is an array where each element has these fields:
certificate
file
A digital certificate
commonname
string
Common name (CN) of the certificate
address
string
Wallet address of the stakeholder
price
string
Royalty for the stakeholder when the asset is recursively re-created.
role*
string
The role that the stakeholder plays
seis
array
An SEI list that represents the web2 accounts of the stakeholders across multiple social platforms.
sigcert
string
Metadata signature using the corresponding private key of the certificate
sigaddr
string
Metadata signature using the corresponding private key of the address
A stakeholder can be either:
An actual human whose identity is verified by certificate and commonname.
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.
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.
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 encompass the various ways it can be utilized and leveraged in real-world social scenarios.
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 . A single asset can have multiple capabilities.
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 "" block is added to an asset's metadata in order to represent these roles and ensure their authenticity.
The name of the asset can be up to 50 characters. See subsection .
ID of the asset type. See subsection .
Image preview. See subsection .
An ID for the asset set that the asset belongs to. See subsection .
Asset traits. See subsection .
Main entity of the asset. See subsection .
How rare it is. See subsection .
Contract address for ETH or protocol for inscriptions. See subsection .
Follows standard.
What the asset can do. See section .
Asset stakeholders. See section .
In , this data is stored in the smart contract's instance database:
A social asset should always have a name. The field may be either name or title, so as to be compatible with various and .
A stakeholder on any application can be associated with a web2 social account, where the associated web2 account is represented by an 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.
