ERC-1400 and ERC-1410 - Security Token and Partially Fungible Token

finance
erc-1400
security-token

#1

Important update: after feedback, ERC-1400 (Security Token Standard) was split, so that now there is a related proposal ERC-1410 (Partially Fungible Token Standard).


From Adam Dossa, Pablo Ruiz @pabloruiz55, Fabian Vogelsteller @frozeman, Stephane Gosselin @thegostep:

Motivation

Accelerate the issuance and management of securities on the Ethereum blockchain by specifying a standard interface through which security tokens can be operated on and interrogated by all relevant parties.

Security tokens differ materially from other token use-cases, with more complex interactions between off-chain and on-chain actors, and considerable regulatory scrutiny.

Security tokens should be able to represent any asset class, be issued and managed across any jurisdiction, and comply with the associated regulatory restrictions.


2nd Community Call: ERC1400 Feedback, Discussion & Questions
Update on ERC-1066 Status Codes project
Community Call: ERC1400 Introductions, Feedback, & Questions
#2

Very well written, I see no technical (read: software) problems with the proposal.

However, this is definitely a case of a proposal with the need for strong legal technicalities. I am sure the proposer has done due diligence as the proposal is well written, but I am curious from which jurisdictions this has been evaluated from a legal standpoint. SEC is a big one, ESMA for Europe, Hong Kong SFC, etc.

I think adoption of this proposal is likely to hinge on the answers to various legal questions, so I think this should be determined first.


Also, another nitpicky thing: I think semi-fungible tokens (the denomination of a user’s balance by tranches, and the possibility of restriction of transferrability by tranches) should be a separate standard. There is a lot being proposed here, and I think the separation of this functionality from security- and custodian-specific functionality would make this proposal better off.

It’s funny, because I was making a similar suggestion for reputation tokens (to be semi-fungible) just the other day.


#3

I agree this standard should be separated into a partially fungible token and security token. I think the partially fungible standard can be very useful in a lot of cases.


#4

I’ve reached out to the team to schedule a community call.

They’re requiring #erc-1066 as a dependency – which is great! @expede came up with it because we were trying to solve issues around security tokens and messages around whitelisting.

Looks like one of the authors @thegostep joined us here. Welcome!

Legal should be considered a SEPARATE layer. I know everyone is freaked out about this, but we need technical interoperability as a foundation to tweak the legal bits. So far, lawyers have tweaked implementation of security tokens on a one off basis (no joke), which is not the way to make for interoperability.

Yes the work needs to be done to review, but I have found that I’m the one suggesting technically how things can be done to meet legal needs, not the other way around.


#5

Thanks for the feedback (this is Adam, one of the EIP authors from Polymath).

re. splitting the proposal into a partially fungible token standard (e.g. tranches) & security token standard (checkSecurityTokenSend etc.) - this is something we debated internally and in fact was the original way we structured the EIP (as two separate related standards). In the end we decided we didn’t want to fracture the conversation across two EIPs so combined.

The PFT standard has some interesting non-securities applications (e.g. token provenance, in-game bonus mechanics) which we are putting together as a fun medium article right now.

A community call would be great - very interested in more discussion around #1066 which we’ve discussed a lot internally (and which led to the return argument specification for checkSecurityTokenSend).

One question I have for more experienced forum members - currently we see the conversation being split between Ethereum Magicians and the GitHub Issue - is there prior art on the best way to manage this to keep the conversation in one place?


#6

Hey @Boris, Pablo here, one of the authors as well.
I have been lurking this forum for long now and joined the Token Ring a while ago. I know there will be some action going on prior to Devcon, at the Council of Prague and I was wondering how we could bring up this EIP over there to get even more discussion around it. What would be the process for organizing this up?


#7

No, sorry, people will use both :wink: There is the discussion-to in the head of the EIP so you can create a forum thread here if you like.

You can request technical points in GitHub and choose eg this thread for broader points.

Re: community call. Great — it’s something I’ve been thinking of for a while so can help schedule / get the word out. Basically a live call, get people to share questions in advance, and then authors answer questions.

Just like Core Dev calls, I think this can be a useful pattern to follow.


#8

Add it to the agenda! There is some discussion here, I think this is a broad topic of interest so you can have space set aside to gather people.

Also: EIPs & Interoperability track at the Status Hackathon the days before council.

I submitted a talk to Devcon around the broad security token topic but didn’t get approved. We’ll have to see if there is anything in the schedule when it goes live, and encourage people to come earlier if they really want to dig in.


#9

Thanks @boris I added the topic under the Token Ring on @ChainSafe 's doc. Is that the right place, though? Pre Council Call For Rings

We submitted a bunch of Security Token related talks for Devcon. Sadly none of them were approved. No love for STs over there :frowning:


#10

Huh. OK, good to know on Devcon. But, that’s why we have EthMagicians. I’ll dig a bit more.

Yeah, that pre-council call is a good start. Need to find out who the Token Ring organizers are. Gathering signaling that there are groups that want to talk about this is a good start – we can point people there for now and mention it in the community call.


#11

Based on feedback here and on GitHub, we’ve split the EIP into two separate standards - the Partially Fungible Token Standard and Security Token Standard.

There was a further discussion as to whether other parts (forced transfers, document management, verified transfers) should be further split out, but this seems to have more trade-offs in terms of adoption and consistency for security tokens, so leaving this as a possible future change rather than including it in this change.


#12

@ jpitts if you’re able to update the reference in the title post to reference the new link above that would be very useful (and hopefully stop the conversation from forking). We are going to close the original issue shortly to move the conversation over to this new one https://github.com/ethereum/EIPs/issues/1411 and of course we hope it will continue here as well!


#13

@AdamDossa, thanks for the heads-up. I have updated the title and my topic intro.


#14

We have a second community call scheduled for this Tuesday (4th October).

Details at:

When: Tuesday, October 2nd, 11AM EST world time check

Call Details: Zoom

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/963516600
Or iPhone one-tap :
US: +16465588656,963516600# or +16699006833,963516600#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 963 516 600
International numbers available: https://zoom.us/u/acB6ZYvJ6