Crowd Found Hub (In Detail)

[TL;DR Summary --This post lays out in fair detail the current state of ideation on a very big concept: A community platform/protocol-set/ecosystem riding on the SAFE Network, which will provide the tools for developers and other creative types to “labor in freedom” while being compensated for working to create value for all, as judged by the open source community. It is an attempt to design a system whereby anyone who has value to contribute can participate in the creation of fabulous things in free coordination with others. With the SAFE Network, we feel that the key tools are in hand to accomplish this. Just some more details to work out.]

What exists below is our best attempt at unravelling the vast tangle of ideas that have been gathered over the years of ideation and turn the strongest threads into a paradigm changing tapestry. I want to start out by thanking @fergish for his help in this process. Without him, I fear people would have a vastly harder time recognizing anything resembling the vision that is the fabric of this proposed ecosystem.

That being said, expectations still need to be set. There are a few ideas near the end of the document that are “works in progress”. We are asking for much-needed specific ideas and feedback, though I’m excited to hear any and all critiques the community might have.

#First, What is it?

Once completed The Crowd Found Hub will be a community resource that provides the necessary tools to allow distributed groups, made up of individuals who are operating voluntarily, to collaborate in a transparent and sustainable way on inspiring projects, while being free from hierarchical control structures. It will allow for each person to be rewarded for their contributions while protecting the individual from ruinous losses in time, energy and finances due to the high degree of risk often associated with investing in new endeavors. Success of projects developed using the Hub will be dependent on many factors, not least of which will be the understanding and appropriate use of the tools it makes available to participants.

##The Mission
The mission of the Hub is to Empower the Individual to Labor in Freedom, freedom being one of three key tenets of the SAFE Network. This quote emphasises the Hub’s mission:

“Everything that is really great and inspiring is created by the individual who can labor in freedom.” ~ Albert Einstein

##Projects, Proposals and Work Items
To understand how it accomplishes its mission, we must understand the ecosystem that the Hub will create for the project creators, collaborators and Makers who will be incentivized to work on projects developed on the Hub.

Anyone can start a project using the Hub. With a simple seed of an idea a new community is born. As the idea matures it will gain collaborators who continue to develop the concept into a more focused vision (business plan, requirements, what a minimum viable product might look like, etc.). Along the way these initial collaborators can be recognized by individuals of the community for their positive contributions. (see “Recognition Work Items” details below).

###Feature Proposals
As the project vision takes shape, individuals will start to have embryonic ideas for features that might be included in the end product. Support towards these features is provided by contributing Hub Fuel (i.e., Hub Tokens), thus giving the collaborators a means of reaching consensus of the desirability of the feature.

###Work Items
When the project community agrees that a feature is ready to start development, an iterative work item is created. The work items should include a description of the feature as best the community can articulate it at that specific time, along with the expected results of any acceptance testing. Upon creation these work items are listed with the pledged incentives for the Makers who will complete them. A Hub algorithm will gradually release new Hub Tokens into the ecosystem through work items (more details near the end of the document).

When work items are completed, the assigned Hub Token pledges (along with newly released Hub Tokens) are transferred to the Maker(s) who completed the work item. Project Utility Tokens are also created at this same time in the same number of Hub Tokens the maker receives. These Utility Tokens are split between the project contributors and the Maker(s) who complete the work item (see “Project Utility Tokens” below).

###Iterative Development (Handling Scope-Creep)
Because completion of work items will almost always lead to further discovery and ideation about features, the work items should be seen as steps along the way towards a moving target. This is the essence of Agile Software Development. Makers should not be forced to go around and around handling scope-creep the community will inevitably introduce, in order for them to receive their originally agreed-upon reward. When the new ideas about a feature are discovered, those should be turned into new work items with their own descriptions and expected results. It is recommend that project community members (agile term: stakeholders) read up on agile development practices to ensure their community and maker relationships remain healthy.

###Recognition Work Items
As mentioned above, contributors who have been recognized for their positive contributions during the initial ideation phases are preassigned as Makers on special Recognition Work Items which are immediately awarded bonus Hub Tokens and proportional Project Utility Tokens (which can be held, used or sold), thus allowing those Makers to be compensated for efforts individuals deem worthy.

#Autonomous Projects

Each project is an autonomous community within the broader Hub community. The Hub will not seek to control project placement by some kind of curation. The Hub community will determine interest in projects by the members’ contributions and each user will be able to filter and sort projects the way they see fit (popularity, activity level, category, work items, no. of workers, creation dates, percent complete, etc.).

##Project Utility Tokens
The Hub will create Project Utility Tokens in the same number of Hub Tokens that are earned by the makers when they complete work items. Ninety percent* of these Hub created Project Utility Tokens will be assigned back to the original backers and ten percent* will be assigned to the Maker who completed the work items. These utility tokens can be used for anything the project community deems worthy. They are simply smart assets that can be used in any smart contract structure. Some example uses might be that these tokens could be the fuel for the project’s own ecosystem, or perhaps dividend producing “proof of contract” shares. Each project has the freedom to innovate to suit its own requirements, and to find new and more effective ways of doing things.

Just because the Hub automatically creates these project specific utility tokens for every work item completed on every project, this doesn’t mean these utility tokens have to be the final assets of value for that specific project. An example might be a project that only exists to get everything ready for a larger crowd sale of its “Public Tokens”. The community might decide they need a “Proof of Concept” or an MVP. The Hub would create the Project Utility Tokens and when the “Proof of Concept” or MVP is done to satisfaction they can run their crowd sale. Hub created Project Utility Token holders could receive a set sum of the crowd sale “Public Tokens” based on their percentage of project utility tokens held. All others who were not involved in that first phase would have to buy tokens through the normal crowd sale channels. This example might make an added use of the project utility tokens. During the “Proof of Concept” or MVP development, Makers could be being watched by the contributors to potentially become full-time project developers. The larger crowd sale funds might be controlled by the original project utility holders and passed to the full time devs after the sale. Again these are just two examples of how these Hub created Project Utility Tokens could be used. People will come up with many other uses and the Hub will make it easy to implement these different uses.

##Instant Incentive Conversion
Because of the SafeX protocol, instant conversion of work item incentives (project tokens/alt-coins, whatever used) to the Maker’s currency of choice is possible. This would allow the Maker maximum flexibility to participate according to his or her own personal needs/preferences/goals.

#Fueling the Ecosystem (i.e., Hub Tokens or, collectively, Hub Fuel)

Hub Tokens are designed to form the economic foundation which supports the decentralized Crowd Founding Model. The economic ecosystem made possible by this model will allow many ongoing advancements to progress in a co-supportive way, rather than requiring each project do all the heavy lifting individually. In essence the design is intended to be a decentralized Maker Space for software development. Additionally, it should incentivize and reward outside investment, rewarding it well and stably with minimal risk.

##A Volunteer/Donation Based Model
Some actions will require Hub Fuel, such as promoting through pledges on feature proposals (as covered above), while some actions and community developed add-on features will be donation-based. Each project will have to collectively decide amongst its participants whether or not to donate for using the features. They will be required to give a reason why they chose the way they did. Those decisions will be known to the network of Makers who will one day decide to contribute or not contribute to the project. We think this is incentive enough to help people help the ecosystem along the way, as well as allow for those projects that really can’t afford the donation to use them as they see fit.

The flow of Hub Tokens through the ecosystem can be visualized in the following diagram.

###A Note on Pledges and Support
When pledging support for features, the Hub Tokens are not officially assigned until actual work items are created. If a work item is cancelled, the Hub Tokens are released back to the address that pledged them originally and can be used to support other features or even other projects. The Hub Tokens do not officially change ownership until the acceptance testing is complete on the work item.


If Hub Tokens are the ecosystem’s fuel, Makers are the “autonomous as you want to be” engines that bring the desired products to the rest of the SAFE Network.

##Building Your Resume of Trust
While reputation and credentials outside the Hub community will be important to have and maintain, Makers of all types will be incentivized to build their reputation as competent and trustworthy participants in Hub-related activity. It is envisioned that even a pseudonymous Maker will be able to fetch excellent exchange for contributions, based solely upon a track record built within the Hub ecosystem. This will open the doors for contribution from a tremendous pool of talent who, while laboring in freedom, can start from nowhere and build their portfolio based upon trustworthiness and value-added contributions. It is likely that being able to demonstrate a good resume of contribution and trust through Hub activity will be valuable elsewhere, as well.

##Investing in Makers
Makers, as part of their compensation for tasks done, will receive Hub Tokens as well as other project-specific exchange, such as project tokens for specific projects worked on. In the long run, we hope this will be quite an adequate exchange so as to allow eventual “full-time” making. That being said, timing of that compensation may be a barrier to pursuing Hub project work full time at the beginning. This provides an opportunity for those who lack the time, talent or inclination to work as Makers within the Hub environment to potentially invest in and receive a return by supporting the Makers themselves. Remember that aside from those Hub Tokens distributed during the initial crowd sale, all further Hub Fuel will be generated only as compensation directly to Makers (and Recognized Contributors) in exchange for valuable tasks accomplished. The value of the tokens will be established by the open market (e.g., by way of the SAFE Exchange). Makers who earn through project production will be able to contract with investors for ongoing or episodic support, in exchange for an agreed-upon percentage or quantity of token earnings by the Maker. With Maker reputations on the line and smart contracts, we believe mutual agreements between parties can be customized to meet everyone’s expectations fairly.

##A Note on Junior Developers and PtP/PtD
If PtP (see SAFE Network feature “Pay the Producer/Developer) is implemented and the Hub receives safecoin rewards as a result, those rewards will be invested into junior developers who show promise. The contracts made with them will require that they work on Hub projects for a specific time period, or to a defined result, in exchange for the pay they would receive. The contracts with these junior developers will NOT require that a portion of their earning are passed back to the Hub. This might allow them to use those Hub Tokens, and project incentives they receive, to pay for education or pairing partners who are more experienced so they can get up to speed as fast as possible. Whatever they decide to do, the goal of this will be to help them become independent. Even if PtP isn’t implemented, we think others will see this model or a model similar to this or similar models as an example to invest in as well.

#Core Features of the Hub

  • the ability to create proposals for new community projects in a language that connects the expert engineers with the community as a whole
  • filterable list of project ideas (popularity, activity level, category, work items, no. of workers, creation dates, percent complete, etc.)
  • project community hub (a dashboard of sorts with links to project details and communication pages)
  • project ideation (defining the initial idea - including the business plan, resource estimation planning, mvp definition, etc)
  • the ability to create new proposals for new features on existing projects (controlled by the existing community or open to everyone)
  • voting on ideas and features
  • filterable Maker resume listing
  • the ability to crowdfund community project MVPs (might include, but not limited to templates and commonly used crowd funding patterns)
  • the ability to crowdfund Maker tokens (might include, but not limited to templates and commonly used crowd funding patterns)
  • hub project Maker payment algorithm for creating and paying hub tokens for work item completion
  • the ability for projects to create work items and associating worker payments to them (bounties, contracts, etc.)
  • a library of customizable smart contracts to enable projects to accomplish the above goals
  • a community marketplace where developers can offer their own add-ons for projects to use within the hub
  • other things we have yet to think about

#Expanding the Ecosystem with Community Developed Features

We want to support other projects that are working towards making the SAFE Network great. I have every intention to include these protocols and projects (@Seneca‘s Decorum protocol and @dallyshalla‘s SafeX) as well as any yet to be revealed projects, when and where they make sense. Along with using these, we will allow the community to incorporate their own feature add-ons for projects to use. These features could have their own suggested donation of hub tokens and the add-on developers would receive those donations for a period of time the developers determine. After that time has expired, the features would work like any other feature within the hub and the donations would be included in the hub project worker payment algorithm.

#Open Issues for Deeper Discussion

The number of Hub Tokens and the upper limit release algorithm is the least finished idea we are currently struggling with, though other seemingly insuperable obstacles have already been dealt with. It doesn’t need to be figured out right away, but it will need to be figured out and tested thoroughly and then the algorithm would be set in stone from that time onward.

##The Hub Token Release Algorithm
Because the hub is an ecosystem, pieces of data are known and can help us develop a powerful algorithm for the release of new hub tokens. Maker/Work Item Ratio (MWIR) would be known, so using supply/demand laws is possible. If more workers are needed, then higher hub token creation. If less workers are needed, then lower the hub token creation. We also know the total number of tokens that exist out in the wild and the average number of token throughput for any time period. With past history we can develop ongoing future forecasts and create new tokens accordingly. The number of tokens created would become less and less over time. (We need ideas and input to flesh this out. I.e., should there be a burn/recycle aspect? Should the supply be unlimited/limited?, etc. See below.)

###Things to Consider
There needs to be enough tokens to allow people to easily use them for projects. There can’t be too many tokens or the incentive value for workers will vanish. The release of tokens has to be in line with the number of new projects, features and actions (how many tokens people are using and a forecast of how many will be used in the near future). The tokens should increase in value over time. If token value increases over time they should be divisible so people can always afford to do actions with them.

####What is the problem with creating hub tokens?

  • Increasing the number of tokens beyond their use will cause inflation and the incentives they are meant to produce will vanish.

####Is there a theoretical sweet spot for the number of tokens that should be in existence at any given time?

  • Won’t know until we see how easily and often people use them.
  • Perhaps this is the key to the algorithm?

####Should the total supply that will ever exist be time targeted?

  • If the total supply is time based then the algorithm can make sure to limit the number created every day/week/month or whatever time interval we set.
  • We could also set it up like bitcoin in that the number of them increases or decreases based on where we are in time.

##Why not safecoin in place of the Hub Tokens?

  • Pro (perhaps): Less Friction
  • Pro: Much simpler to implement (possibly)
  • Con: Requiring peeps to use their “precious” safecoins might suck for some. Safecoins already have a utility function and that is to pay for data “PUTS”. Now if they want to invest in a project they have to give up safecoins.
  • Con: No algorithm levers to govern the number of Project Utility Tokens (not a real issue unless the value of safe goes significantly higher/lower in a short time, which it probably will)
  • Con: No EASY way to do a crowd sale to bring this project into existence in a “quick” full time way.
  • Con: Kills the idea of supporting a maker to receive hub tokens.
  • Con: Narrows the value channel into Hub Tokens, forcing everything through safecoin, rather than other, more direct swaps. This is actually a big minus. Via SafeX most cross value swaps will be possible.

##Bad Actor Protection
In Bitcoin, the miners are incentivised to be good actors because it just takes more resources to try to break the system than it would be to use those same resources to be rewarded to mine the way the system is intended. We need a way to incentivize all collaborators to be good actors or at the very least protect against bad actors.

If I wanted to be a bad actor in this ecosystem I could create a pseudo project and false makers. I could then support fake features and build fake work items and complete them with my fake makers. The Hub would create the extra (bonus) tokens and pass them onto the fake makers. It would be obvious to almost anyone looking at the project to know this is going on (source code, project collaborators, ideation, etc.) but it wouldn’t be obvious to the Hub. Now add the fact that a programmer could build a bot to create fake projects and makers and do this without any kind of human interaction.

We believe the Hub Creation/Release algorithm could be setup to only work if a large portion of its collaborators are known as good actors on existing projects. It’s still possible, though harder for a bad actor to play nice for a while and then start a scheme. More likely a group of real actors could work together to make this possible - perhaps running a scam on a larger population of Hub members. This good/bad actor decision could be done through connectivity characteristics of the existing hub social graph which would limit the extent of damage that could be caused by a given Sybil attacker while preserving anonymity, though these techniques could not prevent Sybil attacks entirely, and may be vulnerable to widespread small-scale Sybil attacks, we believe this would build a solid web of trust for the Hub ecosystem to be safe (for more information please see Sybilguard).


I will follow up later with much more inclusive response. Well congrats to @chadrickm on a very thorough write up. Reading the above is an example of why I love this community. Seeing this swell of talent rise is magnificent.

The Founders Hub sounds like a perfect combination of Kickstarter, Github, and this forum. I have already started the process of finding a way for me to live in this space full time…thank you for just making it that much easier. I cannot state it enough how excited I am about this.


@chadrickm whenever you guys are ready I’m supporting this financially, it would be fun if other community members could support this on other levels (marketing, logo’s etc). Maybe it might help to give a listen to this:

Bad actors, can be stopped if a software development works with milestones.

I love the Consensys approach:

These guys are just making stuff and pushing it out there, ideally this is what we all want for the SAFE Network (people working on code and getting the finance to get it done).

Wow @chadrickm you really took the time to dig into this and I dig it :stuck_out_tongue:


Super interesting. Don’t have time to read all now. But the 40% I got through was super through and excites me a lot for this/SAFE/the future!


It would be awesome! If the hub existed today there are already folks who I would recognize for the help they have already provided. I’m making a list of these folks and when the feature is ready they will be rewarded for that help. I will do the same for anyone else who brings true value to the ecosystem. That could include marketing, logos, and pretty much anything. This recognition will be arbitrary right now, but once the hub is functional it will be driven by the community…

You all are ultimately the founders of this hub!


Heard about your project on LTB Network and was directed here. Some question to clarify your vision:

  1. Why 90/10 split and not other numbers? Looks like there’s a footnote on your slide, but there’s no text to it :slight_smile: Is that MWIR mentioned later?

  2. Any idea on project governance process? How a distributed swarm of project contributors will come to a common decision?

  3. Would Work Item funding (pledges) be done on a consensus base (see q.2) or by each project contributor himself?

  4. What’s the Hub Fuel and how it’s different from Hub Tokens?

  5. Can you elaborate more on creation a specific token type against using safecoin? In particular this:

At what stage project is now?

Very interesting project, I’ll follow it!


Have a couple minutes to answer one or two of these and will write more later.

  1. We think (not proven so that is why the *) that this division will incentivise both groups appropriately. The Project Backers will get the larger portion while the Project Makers will get enough to keep them invested for the long haul. The Project Makers also receive the Hub Tokens (#4 which is the same as Hub Fuel - two terms for the same thing. One descriptive and the other the name).
  2. Features will turn into actual work items when there is enough detail to create a “passing” use case. The work items will get worked on and finished when enough incentive is pledged/assigned. There are potentially some holes in this. What if two incompatible features are both curated and pledged to? What if the Maker claims the work item is done while the backers disagree. There will probably need to be a way to vote on some of these issues and the current holders of Project Utility Tokens would vote. Another solution is a hard fork of the project into two projects. We have discussed a bit about what this might look like but still a lot of things to sort out with that.
  3. The only consensus needed would be between the Project Maker and the Project Backers. From the Project Maker’s perspective there simply needs to be enough incentivised return to do the work. Until that amount is reached (free market) the work item will probably sit untouched…
  4. They are the same thing (as mentioned above).

— more later —


What do you think about having those percentages customized/dynamic? It seems different projects would have different perceived values. For example,one way I could get my “less than popular idea” to move forward is to be the significant investor to provide funding and also set up a higher percentage of HT’s and project tokens to makers; to “sweeten the pot.”

I see the enormous power of community driven projects, particularly for foundational projects like Decorum, but I think smaller projects and individuals could also benefit from using the Founders Hub for smaller individual projects like “Bob’s Burgers” website upgrade project or something.

Kind of a github vs. kickstarter vs. approach.


Giving the current Project Utility Token holders a choice to define their own percents is probably a good feature to have. It really is their project and to hold to the autonomy aspect it should be up to them. In reality they are in charge of their own DAO.

Leads me to another thought. These aren’t projects, they are DAOs.


Then The Hub has to have a governance process, just because the process of coming to a consensus (e.g. on the MWIR) will heavily affect the outcome.

Let me rephrase my 3rd question.

Say, Alice, Bob and Carol are Project Contributors. The work item pops up that Alice and Bob think is worth funding, but Carol disagrees. Is there a joint pool of Hub Tokens that is used for the pledge and, thus, Alice and Bob, can still outvote Carol and use her funds? Or there’s none and each of them pledges on an individual basis?


Yep, you are correct.

At this point there are no plans for a pool of resources except the pledged amounts could be considered a pool. The pledged amount is an aggregate of each backer’s individual pledge per feature being curated. Pledges are also reassignable until the work items are created (by a consensus - so yes, governance) and at that point the aggregate pledges are assigned.

I foresee times when work items might get cancelled before work is started (and that process of starting a work item by devs needs some explaining). This would then release the assigned tokens back to the original backer.


In the interview, this idea wasn’t talked about, but there is an idea being curated around the concept of developer backers.

You can find background material in this post relating to the following section in the OP.

Remember that aside from those Hub Tokens distributed during the initial crowd sale, all further Hub Fuel will be generated only as compensation directly to Makers (and Recognized Contributors) in exchange for valuable tasks accomplished.

The current status of the project is we are building a team (getting to know one another and building trust in one another) of people who are passionate about seeing the vision come into existence. We continue to iterate over the existing ideas and hopefully making them stronger. Your questions and feedback are greatly appreciated. This process would be so much easier if the Hub already existed :wink:

At the same time those of us involved are strategizing the way forward and investigating the available technologies (Counterparty, Etherium, Tokenly) we can currently use with an eventual view of porting to the safe network when the features of the SAFE network are ready for it.


Count me in. I’m going to migrate our centralized system to something very similar (and decentralized) anyway.

Tokenly is, basically, a set of useful wrappers around Counterparty.

Counterparty itself is a solid product, but too slow and too expensive for my taste. Nowdays if user doesn’t see an app reacting in less in a second, he considers it broken. 10 min confirmation times (on average) are too slow. And explaining why one should pay $0.01-0.05 (and rising!) per action would be ever worse.

Ethereum is nice, but user tools are very alpha stage. Besides, its price is rising and now simple transactions are just 10 times cheaper than on BTC (correct me, if I’m wrong).

My current approach is to prototype it over ipfs (github repo) and see how it evolves then.


This concept looks really awesome, and its in a great time to start actually a little to late cause it could of worked togheter with some of the already finished ICO on the maid network.

Just sucks everyone switch to Tokens etc, pref to see maid beeing used more.

1 Like

BTW, another two questions pop up.

  1. Is Work Item locked to a Project Maker who decided to accept it? If yes - how then it is unlocked if he’s not performing? If no - what’s your idea to keep up with competing implemenations?

  2. If Work Item is done by two Project Makers - how they split the compensation? There might be an agreement between them, but it would be (at least) nice to have a default option.

Yesterday I started work on creating a discourse forum that will be used to ideate through these kinds of feature questions/answers. I’m hoping to have it up and running by this weekend.

To answer your 2nd question I’m planning on “stealing” and modifying a compensation process from a disbanded OS project called Better Means. You can youtube to see some of the ideas, but in short each contributor on a story/feature will rank the percent of value each contributor contributed (including themselves) and a final ranking will be applied for compensation. There are some cool weightings that can go into this over time as people will come to over/under value their own contributions.

The first question I don’t have an answer for yet. This is important and will need to be figured out…

2 Likes ? I wonder why it is abandoned. Was this a commercial startup or an opensource project? Project name seems to be carefully chosen to be ungoogleable :wink:

In my current setup it’s locked, but just for two hours. After 2hrs of inactivity any project member can pick up the work item (ticket in our lingo) and continue.

1 Like

I watched the video.

It’s a hippy pipedream; no wonder they disappeared.

My anarchism is tempered by an awareness that civilization is built by the constant operation of the leader principle, on all scales. Most people are followers, which is alright, but if that’s all we have then we’re condemned to a subsistence living. Come to think of it: even hunter-gatherers had team leaders, so not even a subsistence existence is possible without hierarchy.

1 Like

Leadership isn’t a hierarchy. Hierarchy at most should be situational.


Yep, that’s the video. - The compensation material starts at 2:55.

I’m not sure why it was abandoned. I think they started it after winning some startup competition if my memory serves me right. I don’t know what the plans were ultimately with it and if there was really a business model. I think some folks were talking about using it during the whole occupy movement fiasco but I don’t know if they ever did (so yeah @bluebird - the community fits).

I like your solution at the moment. When I was discussing this very feature years back with a buddy of mine, we talked about what a live coding session might look like where people could drop in and out and make suggestions or pair up (almost like a shared google doc or like the Cloud9 IDE).

With your solution would the system monitor a source control repo and devs would then have to do a checkin within the first 2 hours then?