AEIP-10.md

AEIP	Title	Author	Status	Type	Category	Require	Created
10	Soul Bounded Token	Samuel Manzanera <samuelmanzanera@protonmail.com>	Review	Standard Track	AERC	AEIP-02, AEIP-08, AEIP-05	2023-04-03

Abstract

Web3 technology brought the usage of digital assets as a way to express our needs of transfers and associations into shared goals. Social, financials decentralized economics activities are now possible and express a way of freedom by building transferable relationships.

Decentralized Society describe the concepts of Soul Bounded Tokens (SBT). These are non-transferable tokens and are the keys to bring trust in networks to ensure origin and reputation of digital entities. Parties("souls" & communities) in DeSoc (Decentralized Society) allow creating goods and intelligence.

By "soul" we mean any wallet/account holding a non-transferable (but possibly revocable by the issuer) token.

Therefore, SBT can be seen as affiliation, membership, or credentials. They can be self-certified, but the power comes when they become attested or issued by third-parties (companies, individuals, institutions).

For example, Archethic Foundation could create a SBT to certify pre-investments of the first miners or signer of the digital human rights.

Furthermore, Blockchains technologies are great to trace the time a particular asset was created, for example a time when a work from a particular NFT was made. But SBT enables to trace the social provenance of this work.

DAO & OnChain governance could rely on SBTs to give more power to Souls holding more reputable SBTs (Archethic On-Chain Code Proposal Voting), or issuing proof of personhood, etc. Indeed, proof of personhood (PoP) could rely on SBT & Biometric to deliver uniqueness tokens.

On the other hand, revocable SBT can be useful in the case of representation of SBT as un-collateralized lending because the loans and credit are based on the reputation of the soul and could be revocable, like a non-seizable reputation collateral until they repay or give proof of payment.

While being nice, SBT still needs to solve some challenges, particularly privacy. For this reason, there are multiple solutions:

• Storing hash on-chain, with plain data stored off-chain
• Usage of Zero-Knowledge proof protocols
• Leverage W3C Verifiable Credentials

This document is targeting the usage of SBT and its implementation on the Archethic's blockchain. This is based on the token standard AEIP and also on the UTXO's hooks AEIP.

Specification

To be able to create a new SBT, the token transaction should be changed to support a new type of token: "soul-bounded"

{
   "type": "soul-bounded",
   "AEIP": [2, 10]
}

Because SBT are tokens which are non-transferable, we can then define conditions as UTXO to prevent its spending if we are not the issuer. The token will leverage the UTXO's hooks/condition to prevent any further usage of the asset.

//Example of unspent output generated by the token transaction
{
   from: "0faa.....abC", // address of the token (in this case the genesis address)
   amount: 100_000_000, // 1 in 10e8
   condition: "genesis_address(transaction.address) == '0faa.....abC'" // This will prevent any transfer except from the issuer
}

However, the SBT should get the possibility to be burnt if the receiver doesn't want to hold the asset anymore.

Revocability

While revocability is optional, few strategies can be implemented according to the usage and the complexity involved. Indeed, using a UTXO model, an issuer/smart contract cannot get back directly the token because it's not centralized in one place but transferred to the receiver.

1. Expiration date

A simple solution for the issuer would be to create an SBT in which the assets and its properties could have an expiration date. Hence, applications can rely on this attestation to check the validity of the SBT.

{
  "type": "soul-bounded",
  "AEIP": [2, 10],
  "properties": {
    "expirationDate": "2024-01-01"  
  }
}

After some time, the issuer might decide to renew the SBT based on the claims of the receiver(i.e. financial statements, administrative information updates, etc.).

2. Smart Contract / TransactionChain

A smart contract or a transaction chain can manage the lifecycle of an SBT, allowing or disallowing the usage of an SBT. The SBT should reference a pointer to the smart contract's address.

Application can check the eligibility of the SBT by calling the smart contract, or the SBT can be self-revocable using UTXO's hook. The latter can be leveraged to send back the SBT to the issuer if the eligibility is not matched for any receiver's transaction or to the burning address.

{
  "type": "soul-bounded",
  "AEIP": [2, 10],
  "properties": {
    "eligibilityContract": "0fa....2b0" // Address of the smart contract chain attesting the eligibility
  },
  "hooks": encodedHooks
}

the encoded hook could represented in that form

if getTransaction("0fa....2b0").content != "eligible" do
  add_token_transfer(to: "000....000", amount: 100_000_000, token_address: "0faa....2b0") # The token is then burnt as not valid anymore
end