# Soulbound Token Workshop at the DAOist

- Date: 2022-10-09
- Location: TheDAOIst, Bogota, Colombia

## Minutes

- L: Topic is soulbound tokens and their role in governance. Let's start with intros.
- Initials in clock-wise order: (A)ngela, (L)ukas, (I)ra, (Ed)uardo, (T)homas, (B)en*, (V)aughn, (Al)ex, (La)uren*, (To)m, (T)im, (K)hai*, (J)ack, (N)ick, (S)helby, (Be)n*

*left earlier

- L: Who saw the talk I just gave? Maybe we start summarizing the SBT concept. Jack, what got you started on using SBTs?
- J: We wanted to have a 1p1v system. We wanted sybil resistant and confidence that people that voted were stakeholders in the project. Many projects don't consider stakeholder ship. We also wanted to build a quest system and can we repurpose quests to a stakeholdership signal? When we started there was nothing available. The closest we had was Discord roles. We wanted to have level-ups and we worked with Collab.land. We're manually airdropping. Collab.land's airdrop wasn't designed for SBTs. People were attacking Collab.land's issuance process.
- L: Originally, the term SBTs was coined by Vitalik et al.'s DeSoc paper. One important topic is permanence, whether I want my SBT or not anymore. How we address this at Otterspace is through Consent. Another important topic was consent: In EIP-4973 it's addressed with consensual minting. Another topic is key-rotation and how we can recover a SBT when the owner lost their keys. What are the challenges for these topics? And how can we improve this concept? At Otterspace, we call SBTs "Badges." Main usecases: (1) Governance e.g. 1p1v or impact-based voting, (2) Credentials e.g. education, (3) Rewards e.g. reputation, (4) Access management e.g. using it as a key.
- K: Would love how to start from the minting perspective. Can multisigs mint? How do we do access control.
- L: Every DAO is represented by a RAFT token. A RAFT token is a regular NFT. With this RAFT token you can access the badges, add people to the allow list. And that's how you control permissions. Depending on community structure: Different kind of members can create different kind of badges. E.g. there can be a hierarchical issuing of badges within an organization, tickle-down style.
- K: What about revocation and social recovery? Can these rights be delegated?
- L: The RAFT is the point of control for the revocation. But how should revocations be permissioned?
- K: E.g. if we only have one admin member, we have to share share the key.
- L: We can hold the RAFT token in a multi signature wallet.
- J: One RAFT token per organization and it could be helt by a multisig.
- L: We suggest a 1/n for a RAFT token. We're seeing that DAO's are structured differently. And how do badges emerge? Top-down, buttom-up? Probably the later is closer to the nature of DAOs. But there could also be several RAFT tokens.
- K: One challenge we're facing. We're running an accelerator. We want to incentivize contributors. What we're debating: Time-based contribution badge. Maybe there's a tiering system, but for us we see that we'll have a lot of badges. There is a trade-off between granularity of how finely-grained we should issue badges.
- L: It depends on the organization. Can there be a badge hyperinflation?
- A: I could share examples. We're dealing with this for the cerificates. If you're designing the badge system to identify contributors then the detailed approach is promising because it matters at what time and on what you contributed to. We image that we could identify a person without leaking the name. The most relevant part of SBTs is privacy. Many aspects can be adapted and evolve. You could even replace badges. Upgradability is a important topic but privacy can't be rolled back. E.g. when PII is revealed, then it cannot be rolled back.
- E: The tokens are specific to the social layer. So the data doesn't necessarily have to be on-chain. If you're using tokens to create organizational hierarchy then this also affects owners e.g. "I feel less than you." When we are designing tokens, we should consider who we are affecting.
- A: I'd like to explore the topic of SBTs and what they actually mean. What are open questions? Should we start with work-shopping.
- A: We should collect the design aspects for SBTs. There are standards, discussions and then what do SBTs mean for you? Take a sheet of paper and write down what comes to your mind.
- Sh: Composability
- A: What makes Composability special? Composability means programming other rights permissionlessly ontop of it. Composability and evolvability are related. Essentially it means the utility is decoupled from the primitive.
- A: Another one is "adaptability."
- V: Question: The more adaptable, the less utility the token has? At some point the token becomes useless.
- A: A smart phone is like that but the material is pretty useless, but through the composability of software then it's very useful.
- N: Non-transferrable, KYC aspect, how they could be used within a DAO/permissions.
- A: Non-transferrability is baked into the token.
- Sh: A note on the non-transferrability. It's important that non-transferability is a feature. MICA Defi regulation in Europe the NTT take it out of the scope.
- A: Non-fungible is interchangability e.g. like a piece of art, not like a dollar bill. Non-fungibility is about being specific, non-fractualizable and so it can only be helt as a whole. We can bind it to persons that participate in a workshop, or even representing different metadata (e.g. speaking time in a workshop).
- J: Minting permissions
- L: Should that be baked into the token logic?
- A: Can you give us an example Lukas how users are permissioned to claim tokens?
- L: Most business logic for how to retrieve the token is built on-top of the token logic. But you could built-in on-chain logic
- X: Conditions to loose a token are also important
- J: If you want the token to be modular, you don't want to bake too much functionality into the design.
- L: Consensual minting is a permission. Consent needs to be present from both parties for the token to be minted.
- Sh: What if you mint a token to a bad actor. Or you could define an expiry.
- A: SBTs are tied much more to the soul than to the organization that granted it. We want to use SBTs for identity. Identity should be emerge from inventory. The conditions to receive and loose it are very important. How can we capture these conditions, e.g. at the application layer.
- T: How can we encode top to bottom or bottom to top emergence of social graphs?
- J: Maturity, expiration, relevance. Maybe you want an SBT become more relevant over time, e.g. bound to an SBTs role. You may also want to devalue the SBT over time (e.g. if the SBT represents decaying expertise). An extension is expiry.
- A: Today we can define an expiration date (it's a fundamental property). Maturity means, can the value change over time e.g. in terms of utility. Should maturity be a core part of the technical spec?
- Jo: SBTs want to decouple financial value from holding the token. E.g. Proof of Humanity can be used as representation.
- A: Maturity means the meaning changes over time.
- J: Maturity can mean the longer you hold the token, the more reputation you have. E.g. in academia, a 10 year professor.
- T: There can be different types of values. E.g. social value or financial value.
- A: Is utility similar to signficiance.
- J: Significance is personal and utility may be general.
- Minut taker comment: We're trying to find synonyms for utility, significance, maturity, weight. They seem to be subjective to owner or issuer.
- Sh: External perspective is important and is connected to conditions to receive and loose. Significance can change based on perspective.
- J: Maturity needs to be linked back to the conditions. We could encode specific maturity conditions with e.g. a trial period. A token can be configured to become inalienble.
- A: Can a token that is non-transferrable be valuable?
- Ang: When tokens are non-transferrable, they can't be valuable.
- X2: But I could sell my private key.
- T: Private keys can't be sold because how can you prove to delete the private key?
- X2: But many people have said that with SBTs you can sell the private key.
- L: You can't sell a private key. Because how can you prove to delete a private key.
- X2: So it can be that many people can have access to an SBT
- J&A: so multi sig could also hold an SBT
- J: SBTs can have value through significance. When you use SBTs for access or identification or reputation. E.g. if you only get into a club with an SBT.
- A: Is Maturity/Significance built into the token design?
- J: I'm interested in encoding maturity into an SBT. There is a trade off between building that into the app layer or standard based on the decentralization.
- Al: You can do go both ways. You can interpret the SBT on-top or build it into the token.
- A: What the token means over time is decoupled from the token itself. It's great! I means you have a lot of flexibility as the token can change its meaning and have subjective meaning for different organizations. SBT is a symbol representation for rights, permissions, identity.
- V: If we wanted to store some information about a person (e.g. their gender) into an SBT, but should we be doing this?
- L: For the token metadata, the less we define as metadata, the more flexible they are. We wouldn't want to bake in e.g. "height" of a person into the SBT. We want to encode it on top of the token.
- Al: If you send an SBT to a wallet, it's more efficient to have a dumb SBT globally. If you make SBTs more vertical, then another token may just replicate.
- L: The benefit of the standard is that you build one integration and that it fits into the standard.
- B: Fashion.
- Ang: Is fashion a property of SBTs?
- L: Metadata is an important property.
- Be: Metadata isn't realy what I meant
- I: If a token is issued by a government it's not a brand, it's more an issue.
- L: Association of issuer.
- Ang&L: Association is stored within the token.
- V: I wrote "scope". What are you binding the SBT's namespace on. So a SBT is subjective. An SBT needs to have a scope because it needs to have a reference for users. If you implemented context lower level then it's be difficult how the interpretation would be built? Granulatity of expression and scalability are connected.
- A: At what level is metadata?
- X2: Metadata has to be always in the token because it defines the utility. E.g. you can see the expiration. So e.g. the expiration is in the token.
- Ang: Clearly from a standard pov, the metadata is in the token.
- T: Social scalability and metadata are related. If all metadata is in the token it stops being socially scalable.
- J: Group ownership. Can that be done on the token layer.
- L&A: What shouldn't be changable over time? Would you add a price to a metadata?
- X: It depends. We approach metadata as evolutionarily. If you have bio signals that come from your loved one. We're looking into that. This is how sentiment changes over time.
- J: Tie a thread on some of what is said. E.g. relationships change over time, this changes over time so we don't want to encode that into the metadata.
- L: To counter that: Issuer is not the Association. e.g. there is an issuer and a DAO and a receiver.
- V: We tried to build a data network for music ownership. We wanted to define relationships on-chain. JSON-LD, Schema, we were backing into those concepts. What do you store on chain is fundamental. You have to find the right amount of metadata to store. You want social scalability and usefulness. Semantic web isn't popular because it was impossible to do
- Al&Ang: You would never produce an SBT with your age inside. You'd produce one with your birthdate. E.g. a professorship could be revoked. At some point you don't want to go too abstact.
- V: Abstraction for metadata is a key point.
- T: Issuer and Receiver are encoded on-chain
- V: Some properties are from nature e.g. some properties aren't arising from another person.