Published

owned this note owned this note

Linked with GitHub Any changes Be notified of any changes

Mention me Be notified of mention me

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 Andrew.Koay@sgx.com 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`