Quick preface: All views my own. Not a lawyer, I apologize if this is a bad suggestion or if I overlook, misunderstand, or misinterpret things, it's a bit daunting to contribute to something like this, just hoping to do so earnestly.
Independent Functionality
Summary
Network Maturity seemingly seeks to embody universal tenets for "sufficient decentralization" that, unlike any intentions set forth in the Token Offering Statement, are not targets that can be set by a potential issuer themselves. With that in mind, it may be worth diving deeper into functionality in some way. In a traditional investment contract, an issuer might become unable to fulfill their obligations for a number of reasons. While this can also happen in a number of ways here, something new is the notion of an issuer actually successfully creating an open network and withdrawing participation at a later date, no longer being held to any original investment contract while the network continues to live on. In order to prevent a situation where the issuer leaves after achieving Network Maturity and users/participants are left with a platform that can no longer be used or built into anything useful by its participants afterward, there should be an independently functional network requirement that needs to be met within Network Maturity.
Implementation
Three important elements in my mind of independent functionality would be (i) requiring any necessary resources (tokens, code, smart contracts, working software, etc.) required to "do the thing" with said tokens as set out in their Offering Statement be publicly accessible on the registered public website, (ii) if projects have any sort of ongoing efforts or responsibilities that involve permission by a central party (Terms of Service, KYC, licensing, etc.), they should be extraneous to the basic functionality of the network, not baked into the transaction validation protocol of the Open Network, and (iii) explicitly requiring fault tolerance, such that consensus of network minus the initial development team is still able to withstand 33% node failure, quantifying the minimum decentralization, beyond one party having unilateral control, necessary for this to be sufficiently feasible from a transaction platform standpoint. My thinking is that this way the initial development team themselves are not essential to fault tolerance, which allows the open network to live regardless of their participation. While it does specify that the IDT must not have control over more than 10% of consensus, it should be explicit that the network should be able to run without them to achieve Network Maturity.
This might not be well drafted, but at a glance, I believe the best implementation of this would be the addition of something like the following to (3) Network Maturity:
(d) the minimum required resource(s) to reasonably execute on the proposed purpose of the project without the involvement of the Initial Development Team is publicly accessible in a functional state on the registered public website;
(e) any required permission or secondary efforts by any central party are non-essential to the basic functionality of the Open Network as a transaction platform and exclusive from its consensus protocols; and
(f) the total consensus governing the validation of transactions in the Open Network minus the initial development team is able to withstand 33% node failure.
Considerations
There might still be some small details to consider.
-
In the case of implementing (e) I think there would need to be a distinction somehow between something that is essential to the life of the project and extraneous ongoing efforts made by central parties as a result of consensus-based decisions, for example a community might vote to send 30% of block rewards to a burn address to be destroyed forever, or to donate to a non-profit like Habitat for Humanity. That should be okay. The coin doesn't live or die depending on what address those block rewards go to. Whether or not the project can conceivably live without those ongoing efforts should be the key consideration.
-
Should independent functionality of tokens be based on the lowest common denominator of utility, in order to be independent from the intentions of the IDT and achieve Network Maturity? For example, if the IDT leaves I should be able to use the tokens and network to transact regardless of their original intent. There are a number of issues I can think of that are weird, are ERC20 tokens meant simply for transaction or a proof of work network by itself functional if there were no stated intentions? Furthermore what happens if under safe harbor I create a PoW network with a premine, sell some, and while the coins are still securities, others fork it and do not sell coins or promise other features? Are their coins still securities? Do forks have to report to the SEC? Are all tokens and their functionality under safe harbor protected IP until they become Mature, despite being forced into an open environment?
-
Are there reporting requirements of the nodes, or can they be anonymous? Can they report in confidence to the SEC? I would imagine totally anonymous nodes also opens this all up to be gamed, as one entity can pretend to be many.
--
2020: I'm creating an issue on GitHub about an improvement proposal by a cypherpunk lawyer for an SEC proposal on cryptocurrency regulation...Thank you for moving this forward, and for allowing people like us to review and add to your own contributions, this is really historic. I hope they take you up on participating in this open source culture.
I hope this all makes sense, if not ignore me. Either way, great SIP (SEC Improvement Proposal). I think the government should work this way.
Quick preface: All views my own. Not a lawyer, I apologize if this is a bad suggestion or if I overlook, misunderstand, or misinterpret things, it's a bit daunting to contribute to something like this, just hoping to do so earnestly.
Independent Functionality
Summary
Network Maturity seemingly seeks to embody universal tenets for "sufficient decentralization" that, unlike any intentions set forth in the Token Offering Statement, are not targets that can be set by a potential issuer themselves. With that in mind, it may be worth diving deeper into functionality in some way. In a traditional investment contract, an issuer might become unable to fulfill their obligations for a number of reasons. While this can also happen in a number of ways here, something new is the notion of an issuer actually successfully creating an open network and withdrawing participation at a later date, no longer being held to any original investment contract while the network continues to live on. In order to prevent a situation where the issuer leaves after achieving Network Maturity and users/participants are left with a platform that can no longer be used or built into anything useful by its participants afterward, there should be an independently functional network requirement that needs to be met within Network Maturity.
Implementation
Three important elements in my mind of independent functionality would be (i) requiring any necessary resources (tokens, code, smart contracts, working software, etc.) required to "do the thing" with said tokens as set out in their Offering Statement be publicly accessible on the registered public website, (ii) if projects have any sort of ongoing efforts or responsibilities that involve permission by a central party (Terms of Service, KYC, licensing, etc.), they should be extraneous to the basic functionality of the network, not baked into the transaction validation protocol of the Open Network, and (iii) explicitly requiring fault tolerance, such that consensus of network minus the initial development team is still able to withstand 33% node failure, quantifying the minimum decentralization, beyond one party having unilateral control, necessary for this to be sufficiently feasible from a transaction platform standpoint. My thinking is that this way the initial development team themselves are not essential to fault tolerance, which allows the open network to live regardless of their participation. While it does specify that the IDT must not have control over more than 10% of consensus, it should be explicit that the network should be able to run without them to achieve Network Maturity.
This might not be well drafted, but at a glance, I believe the best implementation of this would be the addition of something like the following to (3) Network Maturity:
Considerations
There might still be some small details to consider.
In the case of implementing (e) I think there would need to be a distinction somehow between something that is essential to the life of the project and extraneous ongoing efforts made by central parties as a result of consensus-based decisions, for example a community might vote to send 30% of block rewards to a burn address to be destroyed forever, or to donate to a non-profit like Habitat for Humanity. That should be okay. The coin doesn't live or die depending on what address those block rewards go to. Whether or not the project can conceivably live without those ongoing efforts should be the key consideration.
Should independent functionality of tokens be based on the lowest common denominator of utility, in order to be independent from the intentions of the IDT and achieve Network Maturity? For example, if the IDT leaves I should be able to use the tokens and network to transact regardless of their original intent. There are a number of issues I can think of that are weird, are ERC20 tokens meant simply for transaction or a proof of work network by itself functional if there were no stated intentions? Furthermore what happens if under safe harbor I create a PoW network with a premine, sell some, and while the coins are still securities, others fork it and do not sell coins or promise other features? Are their coins still securities? Do forks have to report to the SEC? Are all tokens and their functionality under safe harbor protected IP until they become Mature, despite being forced into an open environment?
Are there reporting requirements of the nodes, or can they be anonymous? Can they report in confidence to the SEC? I would imagine totally anonymous nodes also opens this all up to be gamed, as one entity can pretend to be many.
--
2020: I'm creating an issue on GitHub about an improvement proposal by a cypherpunk lawyer for an SEC proposal on cryptocurrency regulation...Thank you for moving this forward, and for allowing people like us to review and add to your own contributions, this is really historic. I hope they take you up on participating in this open source culture.
I hope this all makes sense, if not ignore me. Either way, great SIP (SEC Improvement Proposal). I think the government should work this way.