ETHMagicians Community Call: ERC1400
====================================

When: Mon, September 17th, 10AM EST [world time check](https://www.timeanddate.com/worldclock/fixedtime.html?msg=ETHMagicians+Community+Call%3A+ERC1400+Introductions%2C+Feedback+%26+Questions&iso=20180917T07&p1=224&ah=1&am=30)
Where: Google Meet https://meet.google.com/zpf-whhr-kfm
Discussion To: https://ethereum-magicians.org/t/community-call-erc1400-introductions-feedback-questions/1333

This is the first EIP Community Call. Introduce your new/updated/last call EIP, get feedback and figure out next steps. [Boris](https://twitter.com/bmann) and the [SPADE](https://spade.builders) plan on hosting these regularly. We'll do a call for topics and participants, and use the [Ethereum Events repo](https://github.com/spadebuilders/ethereum-events) to organize times and participants.

Permalink for this call: https://ethereumevents.global/events/eips-community-call-erc1400-intro/

## Resources

* Intro thread on EthMagicians https://ethereum-magicians.org/t/erc-1400-security-token-standard

## Agenda

* Boris: Welcome to EIPs Community Call
* Adam / Pablo / Stephane: Intro ERC1400 authors, background, plans
* Brooke: ERC1066 feedback
* Rudolfix: Discussion around coordination across interested stakeholders
* Bryant: Can we come up with a more general name for fungible token "subgroups" than tranche? It's just... tranche-y
* Boris: for regulatory purposes, might an instance of a security token advertise their "home domicile" eg Malta, Singapore, US? This feels like it could help with decentralization
* Brooke: Following on Boris' point above 👆
* ERC1400 = ERC20/777/*** + ERC902 + ERC1066 + ERC***
* As a common autonomous network (CAN) **protocol**
* Andy: One standard versus "composed". "Composed" allows us to do more technically. But, if we look at history, people don't compose. They pick one thing.
* _Add your question / comment here_

As finalization of agenda, want to hand off further organizing to 1400 authors and friends, including next steps, venues for discussion, etc.

## Participants

Add yourself if you plan on dialing in, with any company / code references!

* Stephane Gosselin
* Adam Dossa
* Pablo Ruiz
* Andy Singleton (Github: zingleton, Company: Aboveboard.ai )
* Bryant (@fubuloubu) *just some guy, you know?*
* Terence *just interested to listen to the discussion*
* Anne-Marie Jolivalt (tokenestate.io)
* Ofer Avi-neri (Github: @securitytoken, Company: New York Security Token Exchange - www.nystx.com)
* Philip Paetz / Brickblock
* Moritz Hoffmann / Brickblock
* Xavier Lavayssiere
* Brooklyn Zelenka ([@expede](https://github.com/expede), [ERC902](https://eips.ethereum.org/EIPS/eip-902), [ERC1066](https://ethereumstatus.codes), [SPADE Co.](https://spade.builders))
* Theo Freybote (Insurance linked Securities on the blockchain; Decentralised margin trading & crypto lending); www.intcc.co; telegram: @theofreybote
* Jorge Serna (Securitize.io)
* BokkyPooBah
* Joey Zhou (twitter: @josephzhou)
* Chris Smith (telegram/github/twitter: @iamchrissmith, [Meridio](https://meridio.co))
* James Zaki
* Martin Malloy & Ricardo Silva (Consensys)
* Other Meridio team-members locked out due to hangouts cap of 25 :(
* other team members interested:
* Corbin Page (telegram: @corbpage)
* David Conroy (telegram: @Conroydave)
* Asha Dakshi (telegram: @ashadakshi)
* Parker Place (telegram: @pakaplace)
* Haseeb Rabbani
* James Geary (telegram: @jgeary)
* Paul Cowgill / [Tasit Labs](https://tasit.io)
* Satyam Agrawal (Github: @satyamakgec Company: Polymath)

## Notes

[e-mail]
Adam -- one of 4 authors (Polymath)
Marie -- Tokenising real estate funds
BrickBlock -- tokenising real estate (interested in common standard, aligning)
Consensys -- interested in the standard
Meridio -- ConsenSys Spoke for fractional real estate ownership. Wrote smart contract system for asset (security) tokens and real estate MetaData.
Stephane - one of the co-authors (ex-Polymath); design space -- standard approach, represent broad tokens
James Zaki - supply chain provenance & finance of assets (AgriDigital)
DEX lab (multicurrency wallet) - learning etc.

Vojta - aboveBoard (CR)- portal for security tokens

Neufund -- tokenising assets (based in Berlin)

Theo - insurance-linked securities (risk tokens) on the blockchain (Tokyo / Berlin); www.intcc.co
BokkyPooBah - working on security token exchanges

Meeting is full! cant join

Xavier Lavayssière -- research on blockchain regulation in Paris; prototype in this topic at a hackathon in Zurich;

Johann (Berlin) - scaling, plasma research (parseclabs.org); contract audits, security tokens.
Fabian -

### Presentation

#### Adam - Polymath

Polymath has been building a protocol on the mainet over the last 12 months. Sticking to ERC20 primitives induced inefficiencies [is it?]. The implementation of Polymath is open source.

Standards first -- want rough consensus and be forward looking.

Partially fungible tokens (1410) to represent different types of ownership on a fungible asset.

Relative light treatment of documentation at the moment. Communicating documentation changes to investors is in discussion.

#### Brooklyn - : 1066 feedback

Actor model -- status codes, not just errors
Intent about calls
Translate intent up to users
If you get a "not authorized" -- can be sho
Integrating PRs Truffle, MetaMask, MyCrypto -- from a DX and a user experience layer, to enable patterns on chain
Releasing a translations architecture for anyone to register a translation
For the 1400, first off really great work
Worked previously at a security token company, similar patterns, can talk about ERC902 later
First, the column the A range for app spec, lots already in the spec, shouldn't have to do app specific magic
Translations architecture can also translate app specific codes -- suddenly you have to provide extra translations for your code, rather than a crowd sourced base of translations
Might be OK in a Canadian or US focused context, but with translations can get coverage
Clarify on second return, more complex (expressive?) error -- probably covered by translations

When we're building a fluid interface, we look at large number of use cases and extract general uses, lot of the work actually comes out of security token work -- locked tokens over time, whitelist access or not, a lot of the cases that aren't, let's get them into the standard

BokkyPookyBah: won't revert, return an error code? error codes won't come through well

BZ: 1066 compatible with revert -- will get revert with message to user; and because it's message passing, can propagate anything you need. True exception -- overflow, not authorized and you want to revert, you can do that, helper library let's you do that, with translations look up for txns.origin user

Xavier: what has been the case for identifying use cases -- futureproofing for 1066

BZ: Looking at broad use cases, interviewing companies, - interested in hearing from people with high-level use-cases

ENS team, taxonomy of errors -- Nick Johnson

In order to do this, leaving areas open around future use cases

Aside from that, large design overhead, there's intake period before we rework the grid

They are going to be fairly general, is that app specific range (A*) -- trade for implementor, will need to do

As a comparison HTTP has 62 basic, 90 total error codes (256? grid )

#### Rudolfix

Would like to discuss fundamentals

From Europe, permission transfer, Reg D exemption -- simply doesn't exist in Europe

A lot of things

Legal bindings, prospectus -- could be transferable for tokens

Let's create an alliance, like erc725alliance -- Telegram group, moderators, forums to discuss what should/shouldn't be in the standard --

Boris: leave some room for technical experts, but also talk about regulatory

Adam: shouldn't be a equity token standard, shouldn't be domicile / jurisdiction specific
Helps adoption, code re-usable across all jurisdictions -- key goal
There will be some redundancy -- zero KYC in some jurisdictions, so a bit over specified to meet cross jurisdictional

Stephane: interesting explorations -- what is the limit of what can be generalized across all jurisdictions, versus specific to a jurisdicition
Way I've come to think about it -- trustless system has two users: issuer and investors -- current state of tech requires third parties -- balance between enforcing things on chain through code, vs. off chain through legal and financial.
Regulations delegate some compliance management to issuers and investors who then delegate responsability to other parties.
Interactions between on and off chain enforcement -- each implementation has taken a different approach -- finding where a line is drawn is where a standard will emerge as it allows the Security Token ecosystem to emerge.

Xavier:
My impression, as soon as you have restrictions on transfers, have to be clear on what can be done to force or allow a transaction
It's either too broad or not precise enough to make any sense -- as soon as there is a limit, then who has that control

Adam:
Really want to shy away from being specific -- depend on offchain data, transfer agent, broker/dealer, etc.
Reason we haven't been more specific is coming back to wanting to be as general as possible -- that info will vary, different types of actors
Same reason we weren't definitive for tranches -- default, voting, etc. etc. -- left unspecified
How do you build generic logic if you don't have well-defined tranches?
Something not in original standard -- by jurisdiction tranches? etc. -- didn't include

Alexander:
governance mechanism around the topics here
lot of chatter around EIP1400/1410/1411
how to come together around what is accepted or not

Adam:
this type of governance -- kind of messy
half participants, A should happen, half B should happen -- "fork" standards, but takes away advantages
in the short term -- Adam sincere effort that this reflects the community, not be partisan
Decisions -- 50/50 how to tie break
Either how to increase transparency or anything else
Author summarizes or include changes that have broad consensus,

Alexander:
Would say a whole bunch of us are at Devcon -- get together?

Pablo:
Proposed at Council of Prague at ETHMagicians

Boris:
YEs, there is space

#### BokkyPooBah -- Complexity of 777

Adam - 777 could be removed to simplify - interested in seeing what others thoughts are here.

Boris - try not to use EIP numbers in nomenclenture! You're exposing "internal IDs" from the governance / standards;

Call it SecurityAWesome or whatever you want from a marketing perspective so people know how to refer to it

Also: don't need to REQUIRE in the standard on 777 -- the token type that has security token attributes like tranches

Brooke:

Yes, feels complex, but it is a complex topic
Yes, do it at a different layer -- rather than 777

BokkyPooBah: writing smart contracts that work with other tokens, some ideas of dangerous things, like approve vs transfer, but when you send and call, you don't know as the contract calling it that you have received the tokens

So, approve and call is much safer, then execute the function

Rudolfix: need to trust that transfer happened, but still the token can lie to you; like approve and call for different reasons, but token is the source of truth

Adam: definitely interesting, managing token transfers with smart contracts, like 223, 777, etc.
What would be nice is to separate that out -- from security tokens

#### Chris -- how do we manage complexity?

Complexity of legal requirements, or technical inheritance & cross compatability
Next big hurdle -- how do we break things down, so we have a baseline security token standard
What's the right strategy for off chain and on chain?

Adam:
Securities are complex -- worked at investment bank, 100s of people teams
Would be nice to abstract as much as possible as far as the standard goes
Defer to the individual implementation for that complexity
In terms of decompisition -- discussion on Github, should be a single standard with obligitary functions / interfaces -- some of those may be tokens which have no-ops
Right now ERC20 is the main thing, very simple
Slightly related to earlier discussion -- should or shouldn't be compatible
Look at ERC721, didn't try to be backwards compatible with ERC20
Back to compatability -- may be an argument that shouldn't be backwards compatible with ERC20, and less clear break? -- nuanced
Reasonable to pull out certain parts of the spec -- ERC1400 shouldn't have optional components

Stephane:
Processes around security tokens, not just the technology
Many many stakeholders -- explain what is their most preferred approach to compliance
In their implementations, have different interactions -- work to be done is process mapping, any common processes

Andy Singleton:
Only going to implement one thing, won't compose

Boris:
DHH / Ruby on Rails -- long tail of developers will just adopt
There is the standard, and there are implementors of solidity contract templates and open source code that the long tail will just adopt and extend

Brooke:
Not binary
Decompose and then stick them together, and then later a way to stick things together in other ways

Chris:
Yes, conceptualized it like a nested doll -- and then a layer add that brings it together
To Andy's point -- at the end of the day, if it's 1465 or whatever the number is -- then that feels like a very decentralized way of the decision, rather than this group defining it -- feels more decentralized

Adam:
For a bunch of reasons, decomposing, pull it out
At the same time, there are trade offs -- have to go understand 1410 partially fungible, if there are sub EIPs

### Questions stack
> What is the reasoning behind the issuable() function and its irreversibility?

Adam: Reasoning was that for some types of security the issuer may want to issue additional tokens over time (i.e. new funding) but for other types of securities it may not be appropriate (e.g. if you tokenise a building, you may want to guarantee that no new tokens will be issued (i.e. no further dilution)). Making issuable explicit and adding the option for the issuer to irrevsibly turn it off was our solution to this.

>Who exercises what Rights? On which Obligations? Investor protection?
>The World Bank Bonds cover over 100 jurisdictions.
>Please consider https://icsid.worldbank.org/en/Pages/process/Arbitration.aspx
>Otherwise, this aint credible.
>

Each of these are specific to the type of security and the jusrisdiction under which it is issued. It may be something which is implementation specific OR specified using a sub-standard specific the the securities legislation.

> Utilising ERC1400 as collateral. How can a lender ensure enforceability and recourse to the token?

Very interesting question! Using securities as collateral is def. a use-case that everyone wants. Wonder whether there should be a separate "collateral" standard - MakerDAO would be a good org. to discuss with (will raise it). Theo: >>> Can u pls keep me in the loop/involve in this?

If you're a Legitimate Business, what kind of Investors would you be enticing for operating unregulated activities? And why wouldn't you want to operate thru Regulation?

Ain't Standards highly-centralized? If so, then we are distributing standards. Distribution aint decentralized. So how and where is "Decentralized Exchange"?
[^boris-standards-centralization]

[^boris-standards-centralization]: it's like agreeing on music at a party, not everyone may like it and they may make new ones -- but groups of people like tog ather to listen

Analogy is that peer to peer mp3 distribution does not "decentralize" Napster involved in copyright infringements.

# Next steps

* Use a different platform for holding the next call. Google meet limited us to only 25 participants. Zoom?
* Schedule regular calls, what should be the cadence?
* Meeting in Prague before Devcon. Added the topic to the call for rings on ETHMagicians: https://hackmd.io/DaJhrasLQteUk3IwX5bQAg?view
* Setup Telegram / webpage for "alliance"

###### tags: `erc1400` `eips` `community calls` `security tokens`