@ra-phael @rsquare Chris Chung and I had an account-bound tokens get-together at NFTBerlin to talk about the standard’s future and what other plans we have. Below I’m copying the full notes to the Ethereum Magicians forum. Alternatively you can also read them here on hackmd.
Date of meeting: 2022-05-25
Location: Berlin, NFTBerlin event
- Let’s coordinate via the ABT TG channel: Telegram: Contact @eip4973
- Meeting is FFA
(pls add yourself)
- Raphael Roullet
- Chris Chung
- Rahul Rumalla
(please add agenda items if you have any)
- (Tim): mini update state of ABTs/SBTs
- (Tim): Gather feedback about transitioning standard from using “non-transferrable” to “non-separable.”
- (Tim): Present Otterspace’s effort to make an informed decision about using
- (Tim): For
event Transferdiscuss mapping of input parameter values:
from, to, id.
- (Tim): How to move forward with EIP-5107 “Name-bound tokens”: Add initial draft for Name-bound tokens by TimDaub · Pull Request #5107 · ethereum/EIPs · GitHub
- (Tim): What about Micah’s proposal on “NFT-bound tokens”?
- Tim Daub
Heightened engagement of 4973 on twitter.
Account-bound tokens are starting to emerge as a term.
Name-bound tokens proposal created as a spin-off for ENS-bound token standard to help focus the discussions.
Let’s aim to keep discussions focussed around the specifics of Account-bound tokens on EIP thread of 4973.
Decisions that are made on design and implementation must be done through the EIP thread on ethereum magicians forum.
How do we make decisions on certain contentious features in terms of placing something in the spec versus suggestions that users have the choice to implement or not.
Making sure we have discussions that are tracked and traceable so we can be efficient in being productive and be knowledgeable about the rationale and motivations behind any of the decisions being made.
Account-bound might be more specific than soulbound.
Non-separability seems to be less loaded than non-transferability where the baggage of ownership is a contentious point.
Token may not even be the appropriate term for the structure of what we might want to be “soulbound”. Maybe we should be more technically descriptive about the function that we are trying to capture or even revisit the intended macro-goal of bindingness.
Backwards compatibility for the event signatures may help integrateability: i.e.
Potentially any “breaking changes” to compatibility can be supported by a clear design intent for the new approach which differentiates it from other tokens. Narrowing down and being very specific can help with adoption.
from was removed from the
revoke fields. It should be re-introduced to 4973 but the underlying problem needs to be addressed elsewhere.