Notes on Potential Approaches to Developing a NC Crowdfunding Open Source Civic Hacking Project
A short statement of the purpose and goals for this hackathon is under development.
A short overview with links to more information about key legal requirements and constraints under applicable federal and state law, regulation and rules is under development
Unique Legal Hackathon Innovation: Projects Must Include Initial Draft "No Action" Request of Regulators
Draft content re use of No Action letter format to realistically and responsibly address legal compliance of hackathon team projects: The goal of this Hackathon is to create open-source software that complies with and effectively implements the North Carolina PACES Act permitting intrastate crowdfunding & Washington, DC crowdfunding. Judges and organizers of this hackathon can provide high level feedback and guidance but are not in a position to conclusively declare whether a team project would be deemed to comply with or violate applicable law, regulation and other rules.
So-called "No Action" letters are a common method for establishing whether a given technology, product or service does or does not comply with securities and other regulation. Such letters are requested by parties with a live question arising out of a specific activity they reasonably seek to pursue. These letters are requested from the state and/or federal regulators responsible for enforcing the legal rules giving rise to the question. Examples of No Action letters can be found at: [https://www.sec.gov/fast-answers/answersnoactionhtm.html]. State level regulators increasingly use No Action letters as a standard (including a multistate coordinated standard) method for communicating if a technology, process or other prospective conduct would or would not violate law. For more background and context on how No Action letters work in this context, check out the blog post at: https://crowdfundattny.com/category/no-action-letters.
Accordingly, the ideal composition of a Hackathon team would include, at minimum, a named prospective issuer (seeking crowdfunding for a specific new venture), a named technology provider (seeking to enable the issuer to raise money for her new venture using specific crowdfunding technology they can provide) and a named attorney or legal services provider (seeking to lead the drafting of an initial version of a No Action letter). For purposes of this Hackathon, the draft No Action letter is an important part of the technical project and the team presentations and is expected to state a specific and salient request of the state regulator and to adequately define relevant business, legal and technical dimensions including a description of the planned funding raise and the planned use of technology in the context of applicable law and regulation. The process of drafting and iterating an initial version of a No Action letter is expected to catalyze and promote communication, collaboration among business, legal and technical members of each team and to serve as a cross-disciplinary nexus for generating idea flow between and among Hackathon teams, organizers, judges and invited government, technology and subject matter experts in attendance.
A Hackathon team is under no obligation to move forward with attempting a formal crowdfunding raise of capital and under no obligation to finalize or submit their draft No Action letter to the state or federal or other governmental authorities. However, each team must include the draft No Action letter as a file in their hackathon project repository and must and discuss an initial version of a No Action letter as part of the project presentation. As many Hackathon teams as possible are encouraged to submit a final version of their No Action letter to the relevant regulator and to to continue moving forward toward a successful use of the Hackathon project technology for a successful crowdfunding raise of capital in support of the issuer (entrepreneurs) on the team.
A short overview with links to more information about high priority technical priorities to achieve and technical challenges to solve in context of the goals for this hackathon is under development.
Draft content: Projects will compete based upon success at achieving technology priorities and/or solving technology challenges identified in advance of the event by Hackathon organizers as most relevant and highest priority for purposes of generating practically and legally suitable open source solutions capable to enable crowdfunding under local and federal law. Criteria for evaluating whether or how well a project succeeds at meeting the identified technology priorities or challenges will be based on defined, measurable and verifiable data and objectively observable activity or results.
Draft content: Technology solutions may consist of any software code, scripts and other assets necessary to install, run, configure, deploy, operate, log, monitor, test, simulate, integrate, replicate store or archive any software components such as applications, services and data.
Projects and presentations presented by Hackathon teams will be reviewed, rated and ranked by judged based upon the following criteria:
Judges will evaluate the substance and effectiveness of the overall project by each team based upon the files contained within the repository provided by event organizers as of the Hackathon deadline for submission of projects.
To be accepted for judging and eligible to win a prize or award, the root level of the project repository must include at least the following four folders and three files:
1 One folder named "technology" containing all code, scripts and other technical files or data;
2 Another folder named"business" containing all business related content, including files named "business-model" "tax-and-accounting" and "marketing-and-communications";
3 Another folder named folder named "legal" containing a file named "Draft-No-Action-Request.md" and files named "terms-and-conditions" and "participation-agreements" and "inquiries-and-complaints" and "regulatory-reporting" and any other legal content related to the project.
4 Another folder named "presentation" containing a file named "slides" whether or not the team shows slides as part of their presentation. The "slides" file must be saved in .md, .ppt or .pdf file format and follow the template content layout provided by the event organizers, including the team name, project name and GitHub project URL at the top of the first slide page. The "presentation" folder must also contain any other project related files, including video, documents, data or other content that is part of any presentation shown by the team to Hackathon judges about the project.
5 Three files should also be included at the root level of the project repository, named: README (containing an overview of the project and practical instructions needed to run or use the technology or other project tools or processes), LICENSE (containing the MIT open source license) and MANIFEST (containing an inventory of all files in the repository and a brief description of the contents).
The draft No Action request is expected to be an initial but significantly complete version that contains accurate and adeauate content and is in a format suitable to the task of receiving a No Action letter from the responsible regulator in reply. In addition, for purposes of the goals of this Hackathon, Judges will evaluate the substance and effectiveness of the "Draft No Action Request" based upon the extent to which it completely, coherently, correctly and concisely communicates the business, legal and technical dimensions of the proposed approach, including the following criteria:
1 Communicate the Business Dimension of the Proposed Approach
Describe what the product or service will accomplish and how business operations will work to achieve successful offering and operation of the issuance in compliance with regulation resulting in new venture funding within a fair and well functioning market under the law.
2 Communicate the Legal Dimension of the Proposed Approach
Detail what the contracts and legal procedures will accomplish and how legal operations will work to achieve successful offering and operation of the issuance in compliance with regulation resulting in all parties acting within the scope of proper and authorized roles and in adherence with rules, rights, responsibilities appropriate to each corresponding legal relationship and other relevant activity under the law;
3 Communicate the Technical Dimension of the Proposed Approach
Define what the tools and technology will accomplish and how technical processes will work to achieve successful offering and operation of the issuance in compliance with regulation resulting in deployment of secure, efficient and effective applications and services for electronic transactions and that provides reliable, secure, well performing applications and services for other relevant activities under the law.
1 What You Actually Said, Showed and Submitted
2 What You Actually Built, Demonstrated and Proved
3 What Others Understood, Verified and Rated
In general, the README file should provide a simple, high level overview of the project and practical information on how to run or use the technology. For this event, it is recommended that the README file also include any information a judge or other reviewer would need in order to quickly understand and evaluate the contents of your project.
For relevant background and context about the purpose and use of a README file, check out random repositories on GitHub for a general sense of various ways teams use a README file to provide an overview of a project and key information needed to understand, copy, use, amend or otherwise leverage the capabilities of a project.
The README file customarily includes any relevant documentation or links to the documentation files of you split them out into other files. It is common to include a link to documentation about the technology in a wiki that is built into every GitHub repository. Using the built in wiki means documentation and other reference materials exist and are maintained in exactly the same file repository where the technical code, media and other relevant information about the project exists. The resulting easy visibility across all aspects of any given project helps literally keep everybody "on the same page" and working together on the same things, even when some aspects of a project are changing fast. When non-technical team members are drafting and updating documentation or other business and legal for the projects in the project wiki it's easier for everybody to stay in sync and benefit from being familiar with how the project is coming togehter, what has changed and to have access to information about the project (because if it is part of the project, ideally it therefore must exist somewhere in the repository and with some quick detective work (search/filter/sort/browse/etc) anything can be found and known.
Ideally, the README content should also include a manifest of the files in the project repository with a brief blurb about what everything is, at least in a general way if not file-by-file (eg "The 'technology/media' directory contains all the images and video displayed on our presentation slides and on our proof of concept portal page but note that the videos on our proof of concept mobile app pages are not in the project repository because we are using embedded media YouTube as a placeholder all 'Meet the Entreprenuer' and 'Meet the Investor' videos featured in our 'people' galleries and sample user profile pages").
Potential "Focus Challenge" Prizes (ie money or stuff) or Awards (ie public recognition or badge/medal/certificate/etc) could be developed as a way of signaling and spurring special efforts on especially important or high priority items that would not otherwise be considered "critical path" or of an essential nature to demonstrate successful achievement of the basic business, legal and technical functional goals for a good, working project.
How about a prize for the best "Automated Legal Framework" for a tightly integrated process with the project technology but for the legal agreements and other instruments (eg using the project names and other data in software to auto populate custom information and events or other clear conditions to trigger automated processes for Document Assembly, Workflows, Approval Chains, Publishing Integrations, etc.
How about a prize or award for best "Integrated Operating Rules and Participation Agreements" more or less focused on the "automated" processes but specifically focused on legal automation of the processes specifically needed to correctly scope, cover and connect all the needed pieces for multiple different parties regularly conducting transactions or other commercial activities across business/operating domains, legal entity/jurisdictional domains and network/security domains but under an effective and well functioning umbrella domain that mitigates or avoids much of the the business legal and technical barriers to interoperation and cross-boundary integration of transactions and other activity.
This so-called "Extended Enterprise" scenario are coming on strong again (eg see Microsoft's new Coco framework, the various "Trust Frameworks of Hyperledger, etc, etc) and as luck would have it, I've got many many years worth of well honed examples and hacks for this scenario. Something out-of-the-box would be helpful to spin up a crowdfunding system quickly.
How about a prize or award for "Best Records/Data Management Solution" specifically for the best rated estimated prediction of what a total inventory of all documents, records and other data would be included in a"Final Archive" of all records needed to perform a future audit for compliance with applicable state rules and laws or other audit. This is not the same as a future litigation oriented legal document management policy but rather is focused primarily on standard but infrequent "deep audits" as part of support for best-in-kind records and "data" management from a financial/business/legal information practices perspective.
How about a prize or award for "Best Data Science and Applied Analytics Solution" specifically for a team that provides a project that not only achieves the basic business, legal and technical objectives for hacking together a credible crowdfunding solution under state law, but do so in a way that generates, collects, stores and transports the right sorts of data to form a statistically valid and descriptively accurate model of the crowdfunding entity or it's environment (ie the business/legal/technical/cultural/etc environment in which social physics rule and real-time data-driven models represent the guts of future high-speed, adaptive organizations). Given there is a little relevant data today from which to work, an applied analytics type award would probably need to go to a team that intelligently postulated effectively anticipated the right sorts of lifecycle events, parties/roles, transactions/events, systems/components, etc to focus on for showing which data needs to be collected and what insights could be derived such as recognizing the pattern of subtle but strategic trends or important signaling behaviors or identifying sudden tactically crucial events or other real-time sensors for material opportunities and threats or for predictive modeling and forecasting the future.
For purposes of describing code that coders can achievably develop and that judges can objectively evaluate, some description of the roles, relationships, key transactions or other actions and the flow of data, sequences of events and other basic functional definitions will be needed.
The following is a potential structure and approach for outlining key business, legal and technical requirements and constraints applicable to the functional definitions, expected scope of actions and known interactions between "roles" in accordance with example applicable legal rules.
- An issuer may not utilize a Funding Portal or broker-dealer when issuing a Local Public Offering.
- Therefore, the tools used by the issuer of a Local Public Offering must be offered by a company that is not a Funding Portal or broker-dealer in order to be compliant with our rules and laws.
- Further, the provider of such tools must be careful so as not to act as an unregistered Funding Portal or broker-dealer or unlicensed attorney.
- Exceeding the permissible scope or causing an issuer to be out of compliance with our rules could cost the issuer the exemption and could subject you, your business, and the issuer to regulatory action.
The above logical rules provide requirements and restrictions that can be definitively stated as technical requirements in a way that can can enable a compliant system to be built, tested and verified to some degree of certainty and under some postulated set of assumption.
- Brief description and and summary of the key rules applicable to this role
- Key functions, actions, events and expectations applicable to this role
- Key relationships and corresponding rights & responsibilities applicable to this role
- Brief description and and summary of the key rules applicable to this role
- Key functions, actions, events and expectations applicable to this role
- Key relationships and corresponding rights & responsibilities applicable to this role
- Brief description and and summary of the key rules applicable to this role
- Key functions, actions, events and expectations applicable to this role
- Key relationships and corresponding rights & responsibilities applicable to this role
- Brief description and and summary of the key rules applicable to this role
- Key functions, actions, events and expectations applicable to this role
- Key relationships and corresponding rights & responsibilities applicable to this role
The above statements are just example formulations of potential ways content - once it is confirmed as accurate - could be presented to developers in an open forum as "buildable design specification" however these statements are not legal advice and are probably not especially legally accurate.