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

When: Tuesday, October 2nd, 11AM EST [world time check](https://www.timeanddate.com/worldclock/fixedtime.html?msg=ETHMagicians+Community+Call+ERC1400&iso=20181002T08&p1=224&ah=1&am=30)

Call Details: Zoom

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/963516600
Or iPhone one-tap :
US: [phone],,963516600# or [phone],,963516600#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: [phone] or [phone]
Meeting ID: 963 516 600
International numbers available: https://zoom.us/u/acB6ZYvJ6

Discussion To: https://ethereum-magicians.org/t/community-call-erc1400-introductions-feedback-questions/1333

This is the second ERC 1400 community call. Notes from the previous call can be found at:
https://hackmd.io/RexWNd_4S-K6zz53dlljJQ

We will use this document to record notes from this 2nd call.

## Resources

* Intro thread on EthMagicians: https://ethereum-magicians.org/t/erc-1400-security-token-standard
* ERC 1400 GitHub Issue: https://github.com/ethereum/EIPs/issues/1411
* ERC 1410 GitHub Issue: https://github.com/ethereum/EIPs/issues/1410
* Telegram Group: https://t.me/joinchat/FVjP7kY7D6EUX6GYsCEi1w

## Agenda

* summary of main discussion points so far
* should the standard insist on backwards compatibility with ERC20 / ERC777
* which parts of the standard should be split out as separate ERC's
* initial set of ERC 1066 codes
* Stephane: Proposed decomposition of the standard.
* Stephane: Signed messages as parameters to `canSend()`.
* Stephane: Custodianship of permissioned tokens.
* EIP 1462, base security token standard, w/o dependency on 1400

## Participants

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

* Adam Dossa (Polymath @adamdossa)
* Pablo Ruiz (Polymath @pabloruiz55)
* Stephane Gosselin (@thegostep)
* Corbin Page (telegram: @corbpage)
* David Conroy (telegram: @Conroydave)
* Asha Dakshi (telegram: @ashadakshi)
* Parker Place (telegram: @pakaplace)
* Haseeb Rabbani
* James Geary (telegram: @jgeary)
* Brooklyn Zelenka (@expede, author of ERCs 1066 & 1444)
* Satyam Agrawal
* Anton Akentiev (telegram: @AntonAkentiev, [thetta.io](https://web.thetta.io))
* Jochem Gerritsen (website: [securitytoken.it](https://securitytoken.it); working on ST space in the Netherlands)
* Moritz Hoffmann, @mtzhff on tg
* Anne-Marie Jolivalt https://tokenestate.io
* 0age (telegram: @z0age, [tplprotocol.org](https://tplprotocol.org))
* BokkyPooBah

## Notes

Brooke: 1066 community calls will be setup on Fridays.

TPL: Shouldn't be a hard standard to include 1066 code on transfer because finding the reason and surfacing it could be complex. Especially if call is going to revert anyway.

Brooke: Broadly agree - status codes are arranged in a grid - anything ending with a 1 is agree or success, anything else can be treated as a revert. Also building a suite of tools including a helper library to faciliate this (i.e. automatially revert).

TPL: Likes the idea of guaranteeing a revert if transfer fails.

ERC777 quite a bit of additional overhead to being backwards compatible which may not be necessary esp. as there isn't a broad ecosystem which is using it now. Supporting ability to pass in data is important. ERC20 is a different story - agree when forging a new standard important to make long reaching design decisions, but disagree that not being backwards compat. discourages adoption. Try and make sure that default behaviour is not to use default functionality, but can still support older standards.

Stephane: Sees that lots of the 777 features are required for STs, not to say they can't be done on top of ERC20.

Should we have different names for 1400 to 777 & 20? There are a lot of external clients & wallets which are expecting a transfer function per say and not expecting others, so should be able to count on something similar for 20.

Decompostion:

1400 comes bundled with quite a lot of complexity. Split out tranches (1410) from permissioned token transfers. How much additional decomposition of the standard is required. An instance of this would be 1400 be more of a pseudo-standard or package that specifies a list of sub-standards that need to be implemented to be compliant w/ 1400 but doesn't preclude anyone implementing the individual substandards - an approach that can be taken around 20 / 777 compatibility. Preliminary analysis says (assuming we go w/ 777):
- metadata tranches
- permissioned token transfers (canSend + 1066)
- metadata (ability to attach documents to the token contract)
- various additional features that may be needed in certain jurisdictions e.g. force transfers, ending minting, trading halts, checkpoints, batch transfers

Decomposition is critical for view functions can be used for other utility tokens as well as security tokens so shoe horning everything in could hinder adoption. Extra features (tranches) may be useful from an abstraction POV but a lot of those extra features may be specific to the implementation rather than an interface.

From core coin Thomas: Real world use case major data part is super important with a 721 attaching metadata to make them legally binding, are we taking a look talking about adoptibility and usability - ESO 2022 standard is a securities dashboard. Talking to another project who want to provide this bridge to this standard. Would help with real world adoption.

canSend takes 6 inputs (token address, address of sender, tranche, address of receiver, metadata attached to it, trancheId).

Consideration to be made for the cost of adding data (esp. for batched transactions) strong case to be made for also including methods which don't include those

## Next steps

Create a new thread in EM for 1066 status codes for security tokens.

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