Today in crypto there are a number of novel technologies quickly advancing and gaining public interest. ZK technology and its applications, decentralized networks offering services such as compute, data storage and indexing, modular blockchains and many more. These technologies are exciting and often monopolize the attention of the crypto-aware public. One among these trends to briefly take hold of the prevailing narrative were soulbound tokens; developers, twitter threadoors and crypto experts have been dreaming up numerous applications for these tokens since Vitalik published a short report on them in January. Soulbound technology, however, despite sounding shiny and new, is not a novel concept. In fact, the ‘soulbondedness’ of tokens has always been possible (and used many times in the past). The main difference between then and now is the attractive marketing language that shrouds it. In fact, soulbound tokens highlight an important crypto-axiom that will be soon invalidated.

Soul-bound tokens are simply any token that cannot be transferred. A token itself is just a smart contract that contains a dictionary mapping addresses to balances. These contracts typically also contain functions that facilitate minting, burning and transfer of these balances between accounts. Today most tokens are based upon the OpenZeppelin standard implementations, and come in the three main flavors of ERC-20, ERC-721, and ERC-1155. Within all three of these standard contracts there are two functions that handle the transfer of tokens between accounts: transfer() and transferFrom(). The former is invoked when a user wishes to transfer his own tokens to an external account. The latter is invoked when an external smart contract approved by the user wishes to transfer tokens on the account owner’s behalf. A token has become a ‘soulbound’ token once these two methods are removed from the code. Although extremely simple in nature, there is a massive universe of things that could be built atop of this concept including DID, credentialing, role management, reputation/credit score, etc.

Soulbound tokens also highlight a key assumption inherent to all blockchains: that there is a strict separation between the random, outside world (user keys) and the deterministic internal world (the global state of the blockchain). The address and private key of accounts, which are the product of a pseudorandom process, are the only point of contact between these two worlds. A single account on Ethereum is always either owned by a single entity or part of a group of other accounts owned by a single entity. In other words, the account is atomic. The balances of tokens, lending positions, airdrop eligibility, etc, exist inside the blockchain as a part of the global state; they are not intrinsic properties of the account itself. This allows developers to program detailed rules about how state can be modified, in particular with respect to the eligibility of an account to transfer value at a given time. In fact tokens are ‘locked up’ all the time for the purposes of lending, investor vesting schedules, penalization, etc. The reason why these programatic rules work is dependent entirely on the separation principle defined above. The physical and digital have a small, well-defined border. Because it is impossible to interact trustlessly without digital intermediation, and the digital intermediary is where the aforementioned rules have been defined and enforced, sidestepping these rules is deemed impossible. But what if it wasn’t?

Imagine a scenario: you are a venture investor in a smart contract based project. You send n dollars to the Acme Protocol and received m tokens back subject to a vesting schedule. The vesting schedule is enforced by making tokens non-transferable until time t, after which they are ‘unlocked’ and can be freely spent. Now imagine that during this time Acme has been wildly successful, and in a moment of hubris, you decided borrow money from 4 Spears Capital to deploy to a number of other projects that eventually failed. You’re on the hook for a loan you can’t pay back, because all your remaining profitable capital is locked by Acme’s smart contract. You need to liquidate your Acme early to pay off the loan. How could you do this?

The easiest option would be to sell the wallet to someone else. They pay you USDC, you send them the private key for the wallet and your counterparty waits for the unlock and profits from taking a fee for doing so. This process at the moment cannot be done trustlessly and thus requires escrow or some other middleman to ensure both parties act agreeably. In addition, Acme would probably be made aware of this sale, and if it violates the terms of the original purchase, could create legal issues for you. This increases the cost and friction of transacting. Soon this will be as easy and trustless as invoking 'transfer()’ inside of a token contract

Key-resharing is a cryptographic process that allows one public key to be generated from multiple private key shards and for those shards to be swapped out with new ones while not effecting the outward facing public key. An early pioneer of this technology was Dfinity, who outlined their process in a 2019 paper. Dfinity is a network of compute sub-clusters that provide computation as a service similar to AWS lambda. Each sub-cluster (called containers) must be identified with the network but may have different constituents at different times. Using key-resharing the container can have participants come and go at all times without effecting its identity. What if this same technology were to be applied to wallets? Today, the only way to get a multiple owner wallet with a deterministic public key is via the use of multisignature wallets like Gnosis Safe. These wallets are not actually wallets, but smart contracts that contain a record of who the signers are. As such, they do not play nice with all dApps, typically don’t receive airdrops, and are expensive to operate. What would be best is a wallet that can have its constituent keys participate equally in signing and be swapped out at will, even if the process of swapping completely changes the underlying ownership of the wallet.

Under the Shamir secret sharing scheme, a secret *s (*a private key) is distributed to n holders such that t shares can compute the secret s but any fewer shares reveal no new information. When the group wishes to redistribute the shares to a new group of n’ holders, t of the n holders must compute a sub-share n_i’ and give this sub-share to the new members of the group. The new members of the group can then use a process called Lagrange Interpolation to reconstruct their respective share of the original secret s. Thus without changing the secret s, the group of signers, of which t/n are required to reconstitute the original secret s (and thus in the context of a blockchain sign a transaction), have been changed, meaning that the ‘owner’ of the wallet may now be different from before without changing anything about the outward appearance of the wallet. This process could be achieved by making use of an additional decentralized network alongside the network for which the wallet is a participant, or it could be implemented within a smart contract on the network itself. Unlike the signers of a multisignature wallet, which are themselves wallets, the sub-shares of a key are not and therefore do not live ‘on-chain’. Thus the status of the shares is not immediately obvious in the network state (and could be further concealed using other technology) thus allowing the keys to change in a subtle manner.

This kind of setup is useful for many other things as well - in particular, for validation pools, where in order to increase inclusion, lower barriers to entry or to increase yield, capital may be aggregated from multiple users and made to represent a single entity to a consensus algorithm. Another potential usecase is social recovery and biometrics; adding additional layers of security to a user wallet such as the ability to get their private key back even after losing some number <t shares, provided they satisfy certain external requirements. These use cases are a few of many other potential benign uses of this technology, which are already being worked on. Widespread adoption of this tech would force us to change the way in which we think about what a ‘wallet’ really is, and questions the validity of mapping a real-world concept such as that of identity onto a blockchain primitive.

If a soulbound token or NFT represents one’s soul, what does it mean to be able to sell it?

Today in crypto there are a number of novel technologies quickly advancing and gaining public interest. ZK technology and its applications, decentralized networks offering services such as compute, data storage and indexing, modular blockchains and many more. These technologies are exciting and often monopolize the attention of the crypto-aware public. One among these trends to briefly take hold of the prevailing narrative were soulbound tokens; developers, twitter threadoors and crypto experts have been dreaming up numerous applications for these tokens since Vitalik published a short report on them in January. Soulbound technology, however, despite sounding shiny and new, is not a novel concept. In fact, the ‘soulbondedness’ of tokens has always been possible (and used many times in the past). The main difference between then and now is the attractive marketing language that shrouds it. In fact, soulbound tokens highlight an important crypto-axiom that will be soon invalidated.

Soul-bound tokens are simply any token that cannot be transferred. A token itself is just a smart contract that contains a dictionary mapping addresses to balances. These contracts typically also contain functions that facilitate minting, burning and transfer of these balances between accounts. Today most tokens are based upon the OpenZeppelin standard implementations, and come in the three main flavors of ERC-20, ERC-721, and ERC-1155. Within all three of these standard contracts there are two functions that handle the transfer of tokens between accounts: transfer() and transferFrom(). The former is invoked when a user wishes to transfer his own tokens to an external account. The latter is invoked when an external smart contract approved by the user wishes to transfer tokens on the account owner’s behalf. A token has become a ‘soulbound’ token once these two methods are removed from the code. Although extremely simple in nature, there is a massive universe of things that could be built atop of this concept including DID, credentialing, role management, reputation/credit score, etc.

Soulbound tokens also highlight a key assumption inherent to all blockchains: that there is a strict separation between the random, outside world (user keys) and the deterministic internal world (the global state of the blockchain). The address and private key of accounts, which are the product of a pseudorandom process, are the only point of contact between these two worlds. A single account on Ethereum is always either owned by a single entity or part of a group of other accounts owned by a single entity. In other words, the account is atomic. The balances of tokens, lending positions, airdrop eligibility, etc, exist inside the blockchain as a part of the global state; they are not intrinsic properties of the account itself. This allows developers to program detailed rules about how state can be modified, in particular with respect to the eligibility of an account to transfer value at a given time. In fact tokens are ‘locked up’ all the time for the purposes of lending, investor vesting schedules, penalization, etc. The reason why these programatic rules work is dependent entirely on the separation principle defined above. The physical and digital have a small, well-defined border. Because it is impossible to interact trustlessly without digital intermediation, and the digital intermediary is where the aforementioned rules have been defined and enforced, sidestepping these rules is deemed impossible. But what if it wasn’t?

Imagine a scenario: you are a venture investor in a smart contract based project. You send n dollars to the Acme Protocol and received m tokens back subject to a vesting schedule. The vesting schedule is enforced by making tokens non-transferable until time t, after which they are ‘unlocked’ and can be freely spent. Now imagine that during this time Acme has been wildly successful, and in a moment of hubris, you decided borrow money from 4 Spears Capital to deploy to a number of other projects that eventually failed. You’re on the hook for a loan you can’t pay back, because all your remaining profitable capital is locked by Acme’s smart contract. You need to liquidate your Acme early to pay off the loan. How could you do this?

The easiest option would be to sell the wallet to someone else. They pay you USDC, you send them the private key for the wallet and your counterparty waits for the unlock and profits from taking a fee for doing so. This process at the moment cannot be done trustlessly and thus requires escrow or some other middleman to ensure both parties act agreeably. In addition, Acme would probably be made aware of this sale, and if it violates the terms of the original purchase, could create legal issues for you. This increases the cost and friction of transacting. Soon this will be as easy and trustless as invoking 'transfer()’ inside of a token contract

Key-resharing is a cryptographic process that allows one public key to be generated from multiple private key shards and for those shards to be swapped out with new ones while not effecting the outward facing public key. An early pioneer of this technology was Dfinity, who outlined their process in a 2019 paper. Dfinity is a network of compute sub-clusters that provide computation as a service similar to AWS lambda. Each sub-cluster (called containers) must be identified with the network but may have different constituents at different times. Using key-resharing the container can have participants come and go at all times without effecting its identity. What if this same technology were to be applied to wallets? Today, the only way to get a multiple owner wallet with a deterministic public key is via the use of multisignature wallets like Gnosis Safe. These wallets are not actually wallets, but smart contracts that contain a record of who the signers are. As such, they do not play nice with all dApps, typically don’t receive airdrops, and are expensive to operate. What would be best is a wallet that can have its constituent keys participate equally in signing and be swapped out at will, even if the process of swapping completely changes the underlying ownership of the wallet.

Under the Shamir secret sharing scheme, a secret *s (*a private key) is distributed to n holders such that t shares can compute the secret s but any fewer shares reveal no new information. When the group wishes to redistribute the shares to a new group of n’ holders, t of the n holders must compute a sub-share n_i’ and give this sub-share to the new members of the group. The new members of the group can then use a process called Lagrange Interpolation to reconstruct their respective share of the original secret s. Thus without changing the secret s, the group of signers, of which t/n are required to reconstitute the original secret s (and thus in the context of a blockchain sign a transaction), have been changed, meaning that the ‘owner’ of the wallet may now be different from before without changing anything about the outward appearance of the wallet. This process could be achieved by making use of an additional decentralized network alongside the network for which the wallet is a participant, or it could be implemented within a smart contract on the network itself. Unlike the signers of a multisignature wallet, which are themselves wallets, the sub-shares of a key are not and therefore do not live ‘on-chain’. Thus the status of the shares is not immediately obvious in the network state (and could be further concealed using other technology) thus allowing the keys to change in a subtle manner.

This kind of setup is useful for many other things as well - in particular, for validation pools, where in order to increase inclusion, lower barriers to entry or to increase yield, capital may be aggregated from multiple users and made to represent a single entity to a consensus algorithm. Another potential usecase is social recovery and biometrics; adding additional layers of security to a user wallet such as the ability to get their private key back even after losing some number <t shares, provided they satisfy certain external requirements. These use cases are a few of many other potential benign uses of this technology, which are already being worked on. Widespread adoption of this tech would force us to change the way in which we think about what a ‘wallet’ really is, and questions the validity of mapping a real-world concept such as that of identity onto a blockchain primitive.

If a soulbound token or NFT represents one’s soul, what does it mean to be able to sell it?