EIP-4973 - Account-bound Tokens

EIPs
, , ,
142

Just a quick note to every person who ever develops any sort of identity-related tech from this moment until the end of human history (a purposefully large net) – pay attention to these words.

Everything I see (excluding this, perhaps) seems almost designed on purpose to create a massive privacy nightmare in the future.

1 Like
143

I understand those general concerns about privacy as data generally isn’t deletable on blockchains, but I’d also like to stress that there are widely cited academic publications, most notably H. Nissenbaum’s “Privacy as contextual integrity,” that build an entire framework for specifically evaluating uses cases based on their privacy where pre-existing norms are considered and it is checked whether those norms are challenged.

Hence, through this lens, generally saying: “Using SBTs/cookies is a bad idea for privacy,” is arguably not reasonable as the underlying reasons for a certain flavor of privacy are culturally specific. E.g., cookies, when not being used as third-party tracking devices to spy on users for the sake of data mining their shopping preferences, are a completely fine tool for web developers, e.g. for implementing sessions.

In fact, I’ve used cookies many times in my career, and I’ve never “accidentally” data mined my users’ data and sold their data to advertisers! It’s not only a design question - it’s also about a person’s integrity and responsibility!

It’s vital when using cookies, SBTs, ABTs, or any other technology, especially when we’re dealing with PII, to understand how to evaluate the software in Nissenbaum’s contextual integrity framework.

If this is done appropriately and with a good faith, then I don’t see any problems with developers using cookies, SBTs, or ABTs.

references

  • 1: Nissenbaum, Helen. “Privacy as contextual integrity.” Wash. L. Rev. 79 (2004): 119.
1 Like
144

Original source: Soulbound Token Workshop at the DAOist - HackMD

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.

1579×921 174 KB

145

Original source: Soulbound token workshop on use cases at the DAOist in Bogota - HackMD

Soulbound token workshop on use cases at the DAOist in Bogota

  • date: 2022-10-09
  • clock-wise order of participants: (B)en, (L)ukas, (Br)ett, (V)aughn, (A)ngela,
    (T)im, (C)indy

Minutes

  • Ang: The metadata example from the last session, I found quite interesting. A guiding question to me is: If it’s something that should never change, then put it into the metadata. And don’t put it if it can evolve.
  • T: There are different ways how the tokenURI is hosted, e.g. IPFS, web2 URLs and so that affects privacy as e.g. the tokenURI access could be permissioned.
  • A: We’re discussing to issue SBTs to TE participants but we shouldn’t put the name into the metadata. The credential receiver should consent to the token being minted.
  • V: If I can always figure out where an SBT was minted towards, there’s provenance.
  • Ang: Collectible history is also tracked and that’s similar. There’s this triangle of token, holder and issuer.
  • L: SBT itself doesn’t have a value, it gets value through the context.
  • T: Kate Sills post on “SBTs should be claims” and that claims are to be subjectively interpreted and cannot be computed over.
  • Ang: When we have SBTs as subjective e.g. like credentials like passports they can be problematic.
  • Ang&L: Let’s go over use cases: Go over the privacy question. Not sure if it was in V’s paper or where I saw it. This claim that you can compute identity is something I’d like to explore. E.g. we’d want each individual to control what information should be public. We don’t want to have another social score.
  • B: How expressive are soulbound tokens, because you can’t express everything with them.
  • Tim: [explain H. Nissenbaum: Privacy as contextual integrity]
  • Ang: What’s signficiant is that you can’t role back privacy.
  • L: Community member rejected SBT issuing because of fear of being doxxed by government. But on a practical level the SBT isn’t that different from that person having a wallet of EIP20 token. Privacy is a topic that is very present. The SBT doesn’t necessarily cary information about the person.
  • C: Are there projects that implement SBTs. Polkadot can derive wallets. And then someone could aggregate different addresses.
  • Br: UTXO model for issuing SBTs.
  • Ang: You can discolose the wallets that you want to show.
  • Br: You want to have different collections of SBTs for different contexts.
  • L: Revealing SBT context has to do with stake too. E.g. imagine revealing your identity to a financial app then you want to a wallet that has many SBTs.
  • V: There can also be a problem of spam. e.g. someone DOS’ing your wallet.
  • L: Consensual minting can combat spam. Otterspace allow list is public so that may leak data. SBTs in otterspace are used for roles. There is also a question of what you want to capture with SBTs, e.g. “I gave a talk here”, vs. “team lead” badges. Optimism’s citizenhouse doesn’t know yet how their SBT will look like.
  • B: Consensual minting how it should work: You get a credential and then you mint the SBT if you want. The default of VCs is that everything is private and then you actively generate proofs and make them public. The default should be that you have the credential and then you mint it.
  • T: EIP-4973 can do private credentials and then mint them on-chain.
  • Ang&L: Everybody please think of a use case and how it’s related to privacy and then we discuss.
  • C: (1) Persistent anonymous reputation: Publish papers anonymously and not being able to tie it back e.g. to avoid NDAs or because you’re anti-thetical to the institution, whistleblowing, RSA authors, PGP thing. Use case: Against impersonation (2) DAO delegate, I want to transfer reputation across chains.
  • T: Anonymity and pseudononymity? What are the definitions?
  • L: If reputation is transferrable then you’re opening yourself to attacks. Composable Twitter blue checkmarks
  • Ang: Verification of identity is also a use case.
  • C: Anti-impersination was another one and the forth use case would be soulbound items in games. NFTs are still transferrable and for games those wouldn’t work well.
  • Achievements and credentials are the same use case. But e.g. games issue achievments for engagement and credentials for verification of completing a course.
  • Ang: Another use case is social recoverability. In crypto only the private keys can be used to recover funds and so having SBTs can help. An SBT is an identifier.
  • L&Ang: The SBT as an identifier can be a use case and then it can be used to recover tokens.
  • Th: In university a title goes to me and must say my name so the title is connected to you through KYC.
  • Ang: It’s similar to a passport and how it proves your name.
  • Th: When I’m born in this imaginary future my wallets gave me my certificate of birth and then this would be your unique inventory that identifies you.
  • T: What does KYC mean?
  • B: “Knowing your customer” is just a small part of KYC. There are different dimensions of KYC. My passport picture is shared with many people. KYC is determining the relationship wit the customer and organization.
  • Th: What I meant as KYC is a verification of a passport.
  • Br: Getting ID’d at a bar can mean KYC too, so they’re just checking your age.
  • L: And the crypto exchange: they wanna understand whether you’re financing terrorism.
  • T: SBTs could also be used for compliance. Permission, Access
  • L: Permissions, Access
  • Ang: Appreciation and recognition
  • Analytics, transparency, equality, token-gating, agreement, a personal contract like a promise, a social commitment, power influence, a public bet

1280×720 526 KB

146

There may be an incompatibility between our use of EIP-1271 and EIP-2098: EIP-2612: 712-signed token approvals · Issue #2613 · ethereum/EIPs · GitHub via @frangio

1 Like
147

I come from this thread, then I found this EIP very valuable.

We are thinking of using this EIP to build a dapp comment sys for decentralized due diligence. VCs (or web3 users) need to do due diligence on dapps. They will send invitations to professionals in related fields. The adoption of reviews can be confirmed through an asymmetric method like give/take.

Previously, the comment system of the Internet was permissionless: your review of something does not require the relevant parties’ aggreement. This leads to spam and fake reviews. The reason may be that the previous Internet pursued the maximization of information efficiency, not the maximization of trust.

This EIP can be used in scenarios like “trusted reviews” and “recommendation letters”. The form needs to be directed, but it requires the consensus of both parties. This traceable review sys unlocks a lot of new possibilities.

Any suggestions or further reading links? Hope to hear from you :smiley:

1 Like
148

Hey, glad you’re finding it helpful. The probably most extensive links on the topic can be found in the most top post of this thread.

149

Forgive if this was discussed before, I haven’t read the whole discussion yet, but one comment I have about this EIP is that because give and take have the URI as a parameter the EIP is not compatible with generating the URI in the contract. This may make minting unnecessarily gas inefficient, and it may limit some use cases as well. What do you think about changing string uri to bytes metadata where the metadata is application-specific, it may be a URI string or it may be ABI encoded parameters and so on. With this design, it would probably also be useful to add a getter that can convert application specific metadata to a URI so that the URI can be known prior to minting.

2 Likes
150

I think this is a useful suggestion that I’m personally in favor of implementing. For the stakeholders lurking here: Does anyone have strong objections?

Mhh I’m not sure what you mean exactly. Would you mind elaborating?

Thanks for your feedback @frangio!

151

I’m thinking of a scenario where a user has an Agreement signature in their wallet that is ready to be redeemed via take. With my proposal, the value that is agreed upon and that the wallet will be aware of is not a string uri but an abstract bytes metadata value. But the wallet will likely need the URI for display purposes, so it needs a way to obtain a URI given some metadata. What I’m proposing for that purpose is a function makeURI(bytes metadata) view returns (string) in the ABT contract.

3 Likes
152

OK. I think we may want to prototype this in the reference implementation over at GitHub - rugpullindex/ERC4973: Reference Implementation of EIP-4973 "Account-bound tokens". Would you be interested in giving this a shot? And then we can also make changes to the specification. I had informally talked about your suggestion with some of the specification’s stakeholders and they all seemed welcoming of the change.

153

@rsquare’s lightning talk at devcon on EIP-4973 and how they use it in Otterspace: ERC Lighting Talks - YouTube

1 Like
154

Hey all - I believe the Interface Id should be 0x8d7bac72 instead of 0x5164cf47 in the spec. If makeURI is added tho it’d change again - just wanted to leave the note here for anyone else looking at it before updates.

I might have some time next week to prototype the bytes metadata change, ERC-4973 is pretty awesome :rocket:

2 Likes
155

I’ve opened a PR with bytes metadata: Use opaque metadata by frangio · Pull Request #52 · rugpullindex/ERC4973 · GitHub

2 Likes
156

This is the point I’m making. I’m not saying any particular single developer’s actions (all of which, I agree, are done appropriately and in good faith) are bad (or even can be). I’m saying, in the aggregate, over time, these things morph into something none of us want. To the extent that the today’s conversation focuses on individual use cases and does not give equal mention to the (I would argue obvious) long-term negative second-order effects, I think we’re making a mistake.

157

Thanks for pointing this out, I’ll fix it.

Edit:

1 Like
158

Some internal discussions in the EIP-4973 Telegram group have reasoned that it doesn’t really make sense to replicate the now-final logic of EIP-5192 Minimal Soulbound tokens here in EIP-4973 and that the specification’s differentiating quality is consensual minting. So some have said that we should, e.g., pull out consensual minting into its own specification as it’s arguably useful for transferable NFTs and potentially even scalar tokens.

But then @glu pointed out that we could do the inverse of it, which is removing all the account-binding nonsense that has caused so much controversy and essentially keeping the consensual minting and I don’t know why but it’s making tons of sense and is something that we can also reasonably standardize as “final,” whereas all the account-binding and soul-binding related concepts are still too early to opinionatedly finalize.

Over the long term, I think we’ll need account abstraction for that, and the Ethereum space isn’t ready for it yet, sadly. Besides, we have addressed account-binding in an un-opinionated way in EIP-5192, and so I’d see EIP-4973 and EIP-5192 being usable in combination too.

What do stakeholders here think?

1 Like
159

While “removing all the account-binding nonsense” may appear more accessible, that would no longer be the same EIP, idea, or surrounding considerations.

Consensual minting is functionally just a nuanced implementation of any token standard, 20, 721, 1155. It is not something that needs to be solved with an EIP that removes all ability to use the existing and properly standardized tokens. The ability to standardize the process without significant feature loss is possible.

To that, the idea of genuinely consensual minting is only possible through account abstraction (using contracts to block unexpected mints) or having the minter opt-in. Today, the EIPs of 20, 721, and 1155 are already designed for consensual minting. It is just opt-in, which the proposed EIP would also be.

If the situation is entirely reliant on the minters opting in, I would expect it to be a token-type extension rather than an entirely new one. Further, extensions have not historically been designed for use cases but rather essential functionality that individuals can build on, given their own opinion and use cases. This EIP and proposed actions carry a large amount of opinion and use-case specification. I would appreciate an EIP that provides new functionality (an extension) without being so limited as the current and future (consensual minting) currently stand.

As referenced in your previous comment here,
EIP-4494 which is serving a similar vertical, is an Extension, which at most, this EIP would and should become given the complete removal of “account-bound” functionality.

With this, though, I would not favor EIP-5484 either as no above-mentioned proposal solves the problem without massive and broad-reaching implications and assumptions.

To the relevant conversation here, EIP-5192 is much better defined however still riddled with issues and misalignment in the way standards are written. Prefer to see further clarity before supporting anything or seeing another half-built EIP that drowns in nuance.

160

I think the main idea behind removing the “account-binding nonsense”, is in semantics and wording. I’d argue that consensual minting is the crux of what has been discussed/developed here ad nausium and the update I was referring to brings the spec up to date with that design.

I think we risk running around in circles further trying to argue/define the canonical Soulbound/Account-Bound/Consensual/Non-transferable EIP when I feel like those terms only recently came into the zeitgeist and don’t even have fully agreeable definitions. The most conversation I’ve seen are links to Glen’s paper, Vitalik’s articles, and some Twitter threads. Semantically, one could argue specs referencing non-transferable NFT is a misnomer since it involves an initial minting, but I digress. So definitely in agreement that we can take out some of the opinions.

I think with some of those nuanced phrasings removed/updated, which I will take a stab at, we could take a step back and really see what this EIP is all about. Going forward I think we (me) can provide some more examples on top of what @TimDaub has already given to convince myself and others that this EIP is warranted and will be beneficial over other specs.

1 Like
161

How do wallets/explorers/marketplaces etc. coordinate on implementing consensual minting without a standard/protocol?