LUKSOUL MEDIA: Part 1

Felix Hildebrandt
KEEZdao
Published in
8 min readAug 8, 2022

--

Many thanks to Rob G and KEEZ for assisting me in polishing this article and helping to bring it onto the radar of crypto communities.

The topic of soulbound, non-transferable tokens is getting lots of interest within the blockchain space lately as decentralized societies become more tangible with Web3 social media applications and DAOs. In this article, I want to outline how such tokens function, their problems for adoption and standardization, and how they differ from verifiable credentials in the SSI field.

As soulbound assets will likely rely on extended recovery and asset management schemes to become viable identities that safely gain reputation and trust, features like social recovery and contract-based accounting are incorporated. By combining those new technologies and the theoretical crypto-native identity construct, the paper will give an impression of the future user-centric data economy.

Current NFT Landscape

NFTs are non-fungible, tradable tokens primarily used to represent something of monetary value, but use cases for documenting attendance, skills, and accomplishments have become more prevalent. These tokens are attestations to specific individuals and hold value similar to diplomas, certificates of achievement, or even reputations gained through interpersonal interactions. This use case reveals an issue with current NFT standards: they are transferable and cannot be bound to a specific individual. As Vitalik Buterin discussed in the article Soulbound, today's NFTs are tradable items that can gain value and inevitably become a signal of wealth, even when it is not the original intent.

Soulbound Token Functionality

Unlike regular NFTs, soulbound tokens (SBTs) are a concept of non-transferable assets. Once issued, they belong to a specific identity. They cannot move to a new address (without social recovery) and cannot be traded for a different asset. However, they can represent specific values. Soulbound tokens mimic special certificates, accomplishments, accurate proof of attendance or social interaction graphs that cannot stem from another identity. As described in the Soulbound article, issuers of these tokens "are not interested in whether or not you paid someone who attended some event. They are interested in whether or not you personally attended that event."

Bound tokens could be issued by the same account, acting as a post or information about themselves, but also attested or shared by other individuals or institutions. A Web3 attestation flow described in Identity Solutions for the Internet would enable self-sovereign acting users with attesters and verify instances around them. Handing out such soulbound tokens from others to user accounts would enable bound airdrops from communities or a DAO controlled by accounts with certain SBTs instead of votes that could just be traded, building much stronger bonds within communities.

Issues with non-transferability

The decision POAP made when creating their attendance token ecosystem breaks down the problems faced with developing bound tokens.

  • Users might have good reasons to migrate their assets to a different wallet for security concerns. Externally Owned Accounts (EOAs), the most prevalent blockchain wallets currently used, are bound to one single recovery phrase that cannot be changed if compromised. That's due to their minimal key-based nature. Users would face the loss of their non-transferable tokens if these accounts became inaccessible or compromised.
  • Users could create a custom smart contract with a transfer or ownership function to hold the bound NFT. With such wrapper contracts, users could sell or trade the asset's "shell" instead of the non-transferable NFT if transfer functions are limited to one or static within an NFT's constructor.

Transferability has led to exploiting tokens that are not meant to be transferred, like secret drops or whitelist spots. One could argue that services that rely on those NFTs can verify ownership by checking if the asset has been moved, but there are further issues:

  • SBTs on EOAs could not exist without external proof and reissuing services. Imagine a user who wants to update their address. They would need to verify that they are the original identity of both the current and the new address, denying that the SBT has not been sold. It would require a dependency/process to authenticate. Such a service is provided by the Proof-of-Humanity attestation service but might get complicated against non-human identities. However, even more cumbersome, every attestation service would have to implement an interface to either burn/reissue or transfer the SBTs, which will cause a tremendous number of transactions for rich histories of interactions.
  • What if only the owner of the anonymous smart contract wrapper has changed without transferring the NFT that it holds? Depending on the management of the roles of such a smart contract, the traceability of SBTs can become unmanageable, as people may just set up a non-standardized and non-bound shell around them.

The conclusion: Soulbound tokens are not easy to implement because they must be issued to specific identities that have met a particular prerequisite, which requires customer verification (KYC) or an established social construct. Once the framework is more tangible, prototypes will likely test different attestation aspects and protocols.

Here, modular standards (LSPs), mainly developed by LUKSO for now, can solve some issues by replacing traditional EOAs with smart contract-based accounts built around the ERC725 Proxy Account standard. Such can contain metadata for storing verifiable information or claims of identities and only use EOAs as their controllers. An example would be Universal Profiles, which can have descriptions, pictures, assets, and more data attached. Through a key manager, the account can be controlled by multiple keys with individual permissions, safely allowing numerous devices and services to restrict control of the identity. Unlike key-based accounts, contract-based ones can update security without losing tokens or relying on third parties to reissue assets. Services could only hand out non-transferable tokens directly to Universal Profiles if they prove their ownership through controller keys. Especially such an interface detection for universal contract standards further limits the use of wrapping up assets.

In theory, the only edge case remaining is setting up an abstract identity from an anonymous profile when buying an asset that starts gaining an honest reputation after the first (and final) SBT trade. For example, a Universal Profile that stays anonymous to get some SBTs. Since it cannot secretly sell the SBTs, it sells the whole anonymous account to someone instead. The buyer could change the keys, fill his profile with correct information, and act truthfully. The only remedy would be attesters introducing precautions.

Hybrid types for extended management

SBTs could also implement a revoke function for issuers or communities, where tokens are initially revocable and transferable before transitioning into a strict non-transferability. To ensure tokens are not financialized and sold to a different party, or if keys are lost or stolen, the issuer could burn and reissue (or transfer) the token to a new wallet. Such hybrid forms could also bring lots of value when proving if the user has authentic community membership or is new to Web3 and does not have his final account set up. Tokens or memberships could be easily revoked within a probationary period or after a duration of unexplained inactivity.

The more SBTs the account has, the easier it would be to prove the identity belongs to that address, thereby confirming the legitimacy of reputation-based NFTs and SBTs held within the account. These systems serve social media purposes, similar to a resume for job applicants. Instead of proving work experience and the completion of assessments, SBTs allow for the growth of online reputation as a means for being recognized and taken seriously. If there is only one SBT and an account with few interactions, it will become difficult to distinguish between honest members and blenders. Uncertainty may lead to actual engagement counters or metrics, as an SBT is only as good as its strict hand-out process and trusted issuer.

Cutting dependencies

Even if there is no standardization for SBTs yet, the concepts are slowly becoming tangible. As stated in Identity Solutions for the Internet, Web2 was never built around sovereign identities; instead, machines with their device address connected to central servers and having their data managed and held by external services. Even if Web3 could solve such dependencies in the future, it currently still lacks primitives to represent social identities in the first place. Most blockchain projects have become fundamentally dependent on Web2 or are using Web2-like structures in the backend. Some examples of the dependencies we face:

  • Since EOAs cannot represent profiles independently, NFT artists rely on centralized platforms like OpenSea and Twitter to commit to scarcity and initial provenance and act as authenticated projects. EOAs do not have data attached; they only serve as an address to hold assets and sign data with a private key so that outsourcing appears justified.
  • DAOs that try to move beyond sellable coins for voting often rely on Web2 profiles to authenticate and ensure Sybil resistance. Faucets or quota systems face the same issue. Using the Ethereum Name Service (ENS) as a Web3 equivalent mainly depends on a paid subscription, but also just acts as a sellable NFT held by an address.
  • Many Web3 participants rely on custodial wallets managed by centralized entities like Coinbase or Binance. Decentralized key management systems are not user-friendly and lack the functionality to act on happened transfers for tokens or NFTs, making it super hard to manage assets even before building more complex data economies like social media applications.
  • Most services gathering asset information about an account rely on centralized projects like Etherscan since services cannot easily read data directly from the network or smart contracts.

The common sense of criticism directs to the conclusion that there need to be multiple standards between the token and its account to enable convenient and decentralized societies, leading to the next question.

What is a soulbound token without a Soul?

Souls as token enclosures in outlined decentralized societies could represent humans, machines, organizations, or anonymous or fictional personalities- anything that requires an identity and a reputation bound to them specifically. An identity has little value without external attestations of abilities, qualities, and character- the building blocks of reputation and trust. SBTs can represent these attestations for Web3 identities, but unlike most tokens today, they hold no value without this bond to an identity instance, e.g., "Soul."

It is crucial not to restrict what a Soul is and what it could become. Through Proof of Humanity, a human Soul might be able to expand the field of decentralized finance (DeFi) services into undercollateralized lending. SBTs could represent "digital twins" of real-world assets or other requirements from the DeFi world. But one might also gain a reputation in other communities by having a fictitious identity, as seen by the movement of Web3 communities where NFTs act as entry points to gated communities. SBTs could enable new horizons within public or private communities for both sides.

Still, Souls as regular EOAs make it hard to enable the full capability of SBTs in a decentralized society:

  • There is no standardized way of attaching data directly to the account other than by holding or owning an external contract that might be transferable.
  • There is only one backup seed for each account, and people could quickly lose their Souls and assets. This lack of security is especially problematic for individuals with valuable assets and cross-app reputations stored on one account. Users should not hold their whole identity or Souls on one single, static backup.
  • There is no structure to owning multiple social graphs or tokens with one identity. Every NFT is just thrown onto one address, which can be chaotic without Souls for every service.
  • They lack convenience. EOAs need funds before interacting with anything on-chain, cannot accept or reject transactions, cannot store data themselves, and do not store their set of owned assets in a decentralized, automated way.

In conclusion, SBTs do not directly bring more people into the blockchain ecosystem; it is the framework that surrounds them. Extended account functionalities and convenience are needed for new use cases and mass adoption. Souls must function as a user-centered identity manager, not just a simple token enclosure.

In the second part, let's discuss contract-based accounts, social media, community recovery, and SBT's difference from verifiable credentials.

LUKSOUL MEDIA: Part 2

--

--

Felix Hildebrandt
KEEZdao

Web3 Software Engineer at LUKSO, focusing on dApps, nodes, and community.