Using Ethereum smart contracts to leverage community service projects
The problem
Working on local projects for community and nonprofit organizations one usually tumbles in an chicken-and-egg situation. Often enough community support seems at reach and probes show that community members would back the project financially if only it was effectively happening. Despite governmental incentives is not unusual, the initial setup of an organization present costs. From registration to basic structure some projects rely on volunteers who can’t financially fund projects themselves. And raising funds in a start-up nonprofit is particularly tricky since unviable projects not only fail to deliver service but also would not be able to refund early donors. Moreover, projects that are not yet in production usually don’t have legal determination status, jeopardizing tax benefits to donors.
Part of the solution
Some structures such as Fiscal Sponsor (in case of the US under 501(c)(3)) that act as a parent organization. Since the sponsor is actively registered under nonprofit status it can accept funding and transfer it to desired project in a later moment. However, the problem still persists in the case of projects that fail to gather minimum required resources to become operational.
Such failure has bad consequences as returning funds granted tax benefits may harm sponsor and donors. Sponsors show less favorable of allowing such bridge-funding. Donors’ frustration and risk of tax issues back away from resuming donations. Not surprisingly we see a filter that bars small and local projects not only from receiving funds but from being considered at all.
Where Smart Contracts can help.
The idea of a smart contract hub for community projects aims to turn small and local projects viable. The structure would support a platform in which projects would be able to explicit step-by-step milestones that needed funding. Donors would fund a smart contract with Eth so that not only refund would be hassle free but importantly donors would be able to allocate firm intention to support projects in pre-established conditions.
Proposed Structure
The platform would allow for three categories of members: Projects, Donors, and Oracles. So that:
Projects would register their scope and milestones. These can vary greatly, encompassing very small local goals (eg buying a new water filter for the playground) or bold enterprises that require large funding. In case of greenfield or complex projects, small steps would be incentivized (eg paying for registration as non-profit; arranging for website design; renting office) so that each step would be easily financed paving the way for a more complex structure.
At each step project would not only describe what the activity and is but also required to make explicit what if any tax benefits could be granted under which condition, such as jurisprudence etc. This can even have hierarchical conditions, such as stating that office rent is not tax refundable for the first year, but can be tax refundable if steps involving registration and proof of effectiveness granted tax status, etc. As funding would be in Eth specific analysis would apply, but in all cases would be clearly determined ex-ante.
Considering the platform could serve as an open display case projects would directly gain from being very specific and make all conditions explicit. Indirectly this framework can help project founders to better organize and plan activities.
Donors would register and fund an umbrella account. From the umbrella account, platform would allow donors to conditionally pre-fund projects. Pre-funding is the cornerstone novelty from the proposed platform. Pre-funding would have automated execution granted by the ethereum smart contract so that donors efforts would end at the moment they opt for a donation. If conditions are not met, funds automatically return to donors umbrella account. From there donors can at any time withdraw and no relationship or liability remain.
Pre-funding a project obey two sets of conditions: those determined by the project itself (minimum cap, minimum time to deploy, or any other condition) and an extra layer determined by donors. Conditions such as min or max share of contribution, time for reaching viability caps, and even conditions linked to other steps or projects.
Oracles would register as well, but their account would serve two purposes: act on contract conditions, and receive payment.
The key action expected from oracles are to verify real world execution and conditions prescribed in the project, and input (using their keys from their accounts) data that triggers contract execution. Oracles can be individuals (the kindergarten assistant may bear enough authority for verify installation of the new filter) or institutions (specialized firms may be required for accountancy and legal analysis of complex projects). The important part is that oracles are predetermined, assigned and agreed upon by proposed projects and donors.
In the case of contract conditions that depend on publicly available information such as govt data, weather conditions, so on there still need to be a assigned oracle operator. Institutions may offer the service to operate such data-to-contract input but even in the case institution sets an algorithmic or automated operation the institution would be assigned as the oracle.
It is possible that an oracle be remunerated by its responsibilities. Such remuneration, if executed by the platform contract, would necessarily be described in the project information.
I am actively working on funding a few community projects. We encounter daily hurdles that prove the task troublesome. Any interested in helping in the design, web-design/hosting, and contract design and tests is most welcome.
Please contact tbt.parques@gmail.com
Thomaz B. Teixeira