A method to transfer and auction soulbound tokens on OpenSea

Original Title: 《A Method for Transferring and Auctioning Non-Transferable Soulbound Tokens on Os》

Author: Shijun

In early May, after the publication of Ethereum founder Vitalik's Soulbound Token (SBT) paper, it quickly became one of the hottest topics in the entire Web3 space. Not long ago, when Vitalik released a new book, he used this SBT, allowing anyone to donate any amount and receive a soulbound NFT. However, the new token standard not only lacks reliable applications for soulbinding in the market but also has vulnerabilities regarding forced transfers of the soulbound tokens themselves.

For veterans of contract technology, the core content can be understood with just two keywords: contract wallet / A3S protocol. But if you are interested in the implementation details, let's explore them together in this article.

1. What is a Soulbound Token?

Historically, liberalism has been the cornerstone of the thriving development of Web3 or the blockchain world. However, rampant liberalism has led to hackers being the most successful group in the transition from Web2 to Web3. So what kind of ideology does truly valuable Web3 require?

Vitalik believes that Web3 needs to be based on responsible liberalism as its new belief foundation. Therefore, SBT essentially introduces a credibility mechanism into Web3, allowing the digital world to evaluate and measure the credibility of accounts, establishing reputation, responsibility, and social capital in a decentralized world.

The way to achieve this is by issuing non-transferable tokens under the target of wallet addresses, referred to as Soulbond.

1.1. Application Scenarios of SBT

SBT, or Soulbound Token, as the name suggests, is a token bound to a user account or wallet that cannot be traded once generated. It can represent commitments, qualifications, affiliations, etc., similar to a resume as proof of corresponding social relationships.

In Vitalik's paper, accounts bound to SBT are defined as Souls.

For example, the account bound to the Ethereum Foundation (Soul) can issue corresponding SBTs to participants of its developer conference, and an account bound to a university (Soul) can issue SBTs representing degrees to its graduates, and so on.

The example target of this article is the SBT that will be given to donation addresses when Vitalik releases his new book.

1.2. Minimal Implementation of SBT

In fact, both ERC20 and ERC721 execute transfer functions through the transfer and SafeTransferFrom methods in the contract standard. Therefore, for the minimal implementation of SBT, it is sufficient to remove the transfer code, allowing the user balance table _balances to be modified only during Mint.

For further reading on standard implementations: 【Source Code Interpretation】What Exactly Is the NFT You Bought?

2. What is the Vulnerability of Transferring SBT?

2.1. Overview of Wallet Classification

It's quite simple; wallets are what can initiate transactions on-chain, and wallets can be classified as single-signature and multi-signature.

For a single-signature wallet, to send a transfer transaction to the blockchain, you need to sign the transaction with your wallet. Once you sign it and send it out, if the transaction executes successfully, the transfer is successful. This is a typical single-signature wallet, which is the most commonly used type.

A multi-signature wallet, as the name suggests, requires multiple people to sign off on executing a certain operation. When using a multi-signature wallet for transfers, it often requires at least one person to sign off before the transfer operation is truly completed. You can specify an m/n signing model, meaning that out of n people, m signatures are required to complete the operation.

Multi-signature wallets are often used by individuals with strong security needs, as well as investment institutions, exchanges, and project parties managing public assets. The core value lies in fund security and joint fund management.

2.2. How Does a Multi-Signature Wallet Mint NFT?

In Ethereum, a multi-signature wallet is often a smart contract, and to implement multi-signature management, there are two main paths:

• The Ownbit multi-signature wallet uses the signing authorization method: sign the corresponding expenditure (amount, target address, etc.) with your private key and provide the signature result.
• The Gnosis multi-signature wallet uses the transaction authorization method: send an Ethereum transaction with your private key to call a specific interface with specific parameters.

Let's take an early version of Gnosis as an example to implement version V1.

2.3. Process of Gnosis Multi-Signature Executing Any Transaction

The overall process is divided into four stages: Initialization Stage → Proposal Stage → Voting Stage → Execution Stage.

• Initialization Stage: Define several administrators _owners; only these addresses can call subsequent transactions.
• Proposal Stage: Any one of the administrators submits a transaction via the submitTransaction method, obtaining a transaction ID transactionId. The submitted transaction must carry the parameters destination, value, and data.
• Voting Stage: The other administrators vote by submitting ETH transactions, calling the contract's confirmTransaction method.
• Execution Stage: When the number of confirmations reaches the minimum requirement, the internal logic of executeTransaction will be triggered.

Ultimately, the contract will call to execute any operation.

2.4. Why Can Any Operation Be Executed?

Because the destination is the target address, value is the amount, and data is the parameters attached to the transaction.

In an Ethereum transaction, the Data field contains the transaction's accompanying information, controlled by specific rules. For example, the following is the most common ERC20 transfer transaction, and its display logic after being parsed by Etherscan is as follows, while the original text before parsing is:

0xa9059cbb0000000000000000000000003baf10686c60680d491f49ea3f720a1831c3391e00000000000000000000000000000000000000000000f92e1b81422bfc3a0000

The parsing principle is that the first 8 bits correspond to the ABI file of the contract, revealing the corresponding function name and parameter list. The subsequent 64 bits are parsed according to different parameter types.

Thus, for proposals, it is sufficient to clearly specify the target address, amount, and transaction parameters to execute any operation.

2.5. Summary - Comparison of Contract Wallet Modes

This section outlines the core implementation logic of Gnosis V1. In fact, it has gradually evolved into a form similar to Ownbit, adopting a signing verification method. The main reason is that using transaction sending to represent proposals and voting simplifies the process, avoiding complex signature calculations, and provides traceability at any time online. However, the disadvantages are also significant:

• A single proposal requires multiple transaction costs, which can be high.
• The gas fees for the final voters are higher, leading to cost imbalances.
• The actual logic of the transaction is in the data field, making it difficult to read and understand.

Therefore, users weighed the pros and cons and ultimately abandoned the transaction confirmation method, moving towards a signing verification model.

3. How to Sell SBT on OpenSea?

At this point, it is quite evident that using a contract wallet, whether Gnosis or Ownbit, one can initiate donations and then claim the NFT. Since the token itself cannot be transferred, why not sell the wallet itself along with it?

Of course, obtaining it is not the end goal; our aim is to find a suitable method to auction it! Thus, we need to implement pricing for SBT.

This requires using a special protocol called A3S.

A3S Protocol Architecture Diagram

It is a multi-chain protocol that constructs the next-generation address standard, providing liquidity and integrability for addresses. A3S enables addresses to be traded, leased, and hosted securely. Therefore, it allows addresses to become transferable and priceable on-chain infrastructure.

Users mint a Commander NFT from the smart contract address factory, which will automatically deploy the corresponding smart contract. The owner of the smart contract points to the corresponding NFT holder. The contract can receive any type of on-chain asset and only allows the owner to send assets, making this smart contract a medium for users to interact with any blockchain dApp.

Whoever holds this NFT has the remote control of this smart contract. If the NFT is transferred, the management rights of the smart contract are also transferred.

Through this principle, we can see listings based on this protocol appearing on OpenSea, although they may not have significant prices, as trading wallet addresses do not yet have a large-scale social consensus.

4. Conclusion

This article outlines the foundational concept of SBT, highly recognizing that Web3 needs to be based on responsible liberalism as its new belief foundation. However, new concepts require thorough consideration of the sniper rifles fired in the dark forest of smart contracts. By summarizing the implementation principles of on-chain contract wallets Gnosis and Ownbit, and combining the cutting-edge A3S wallet address transfer protocol, it systematically explains that even if the token itself is non-transferable, it will still accompany the transfer of its address rights, thereby undermining the meaning of soulbinding.

Finally, while collecting materials for this article, I discovered that there are already researchers with similar ideas, such as 5660.eth, who transferred this type of SBT contract wallet to Vitalik's wallet address. Perhaps this can remind Vitalik and the Ethereum Foundation to optimize future EIP proposals surrounding SBT more periodically, such as checking whether the granted object is a contract address, etc.