Token Binding Working Group Meeting Berlin

Date of meeting: 2022-05-25
Time: 3pm
Location: Berlin, NFTBerlin event

Participating

RSVP

(pls add yourself)

  • TimDaub
  • Raphael Roullet
  • Chris Chung
  • Rahul Rumalla

Agenda

(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 event Transfer.
  • (Tim): For event Transfer discuss mapping of input parameter values: from, to, id.
  • (Tim): How to move forward with EIP-5107 "Name-bound tokens": https://github.com/ethereum/EIPs/pull/5107
  • (Tim): What about Micah's proposal on "NFT-bound tokens"?

Minutes

Location

NFTBerlin

Attendees:

  • Tim Daub
  • Rahul
  • Raph
  • Chris

State of the ABTs/SBTs

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.

Decision making

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.

Naming

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.

Design

Backwards compatibility for the event signatures may help integrateability: i.e.transfer .

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.

Initially from was removed from the attest and revoke fields. It should be re-introduced to 4973 but the underlying problem needs to be addressed elsewhere.

Select a repo