EIP-2980: Swiss Compliant Asset Token

[alanscarpellini]

A place to discuss PR EIP-2980.

[github-actions]

Since this is your first issue, we kindly remind you to check out EIP-1 for guidance.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.

[thedavidmeister]

hi, i've been working on similar things in and around europe recently so i'm glad to see the potential for some kind of standard

most of the logic around whitelist vs. frozen i believe i can incorporate fairly easily as it is very similar to what i have already done

i do have some feedback:

having a single "issuer" role seems unnecessarily broad and centralizing in nature, although i appreciate that the singular issuer address could be handed to a smart contract that implements its own fine grained access control.

would it make sense to separate the ability to manage the white/frozen lists from the ability to directly handle funds?

similarly, a whitelist may be a simple process of KYC review before a distribution, whereas a frozenlist is somewhat more extreme as it implies some kind of serious wrongdoing on behalf of the frozen account. I'd expect potentially different people/departments handling basic onboarding vs. chasing something like sanctions. Could managing the two lists be two different roles?

in this scenario i would expect that ONLY funds on the frozenlist can be revoked/reassigned, which could hamper an attacker as they would need to compromise BOTH a freezer and a revoker account in order to arbitrarily move funds to themselves.

in this scenario i would also expect that funds that were delisted from the whitelist but still held are NOT able to be revoked/reassigned. To me this intuitively seems more true to the stated intention of having frozen and whitelisted funds as separate concepts, where the latter still allows assets to be owned by the holding address until they dispose of them.

i also see the monolithic "issuer" role as a potential misnomer as nowhere in the spec (if i read correctly) is it required that the "issuer" issues (mints and/or distributes) anything. The only privileges that an "issuer" has are the rights to remove access to assets.

lastly i am concerned that the methods that write to the whitelist and frozenlist are specified at the interface level.

for example, i have implemented contracts that are compatible with the concept of being a white/frozen list externally to the token itself, which allows for:

• combining several lists AND/OR style into a single list to support e.g. multiple parallel KYC backends each with their own admins
• additional bytes of data to be submitted alongside adding/banning/removing users from the list that are emitted in event logs for offchain audit history
• several layers of access control around admins/executors of various KYC style operations beyond a single add/remove function (e.g. i distinguish between being a known-bad agent flagged as "banned" onchain and being completely removed from contract storage)
• batch modifications which can be important for gas efficiency given the potential for very large lists (thousands or tens of thousands) to be managed, perhaps the main list is managed offchain oracle-style and only synced periodically onchain, or even synced from another network occasionally

there's probably a lot of other things implementations might want to do with complex approval workflows that a single address -> bool function on the token itself can't represent efficiently

given that the existence of some way to write to the white/frozen list is implied by the read functions in the interface, i'm personally not sure that writes need to be specified

if there's a strong desire to keep and specify the write interface, then could the read and write interfaces be split with the write interface being an optional extension of the read interface?

[gavbrennan]

Hi, this seems to be closed for a while but still appears as in review on the page https://eips.ethereum.org/EIPS/eip-2980. Can anyone point to the legislated requirement that the tokens must be indivisible / have zero decimals? Seems a big miss on the financial inclusion front, many brokers offering fractional investment these days.