[CCBL] Crowdfunding platform

I agree with comments made by Stefan, i would much rather see a project with more functions for a slightly higher price. I like the new version of the proposal. Including an option for the creator to disperse NFTs or Snips is worth it imo although i highly doubt this form of decentralized funding for Tokens is legal, the NFT part might be.

In general this will increase the open source code database for Secret Network and highlight a novel use case of Secret Contracts. I am keen to know how Different this is from Siennalaunch and (if that is going to be open source) why we should fund this project if they are very similar.

1 Like

Thanks for the feedback! I donā€™t know anything specific about how Siennalaunch works so I canā€™t speak to that.

Although I am fairly certain that whatever Siennalaunch ends up being, it is focused on projects with tokens wanting to do IDOs, not general-purpose crowdfunding for any kind of creative project.

2 Likes

Hi everyone,

I had a good conversation with Dan at Bizdev. Thereā€™s a use case for crowdfunding as an investment vehicle on the network ā€“ it helps to vet projects to see they have a clear audience as well as it gives funders the opportunity to invest in projects they like without getting the whole network onboard, or going through traditional VC routes. In a crowdfunding tool investing would essentially be done through rewards for contributors.

The devil is in the details about what specific mechanisms funders would like in place to receive rewards. Building a trustless platform requires that the contracts enforce these reward mechanisms without any manual intervention, so the more complicated we want those mechanisms the more time it takes to build.

I have added a SNIP-24 minting reward in the current proposal but it is pretty simple. In addition, there will be ways for project creators to put funding thesholds on different rewards. However, one additional set of features that Dan identified, which is not included in the proposal as it stands, is a way to add stages to the funding. That would work in 2 ways:

  1. A vesting schedule for tokens generated for the project, so they cannot be dumped immediately.

  2. The ability for funding to be dispersed in stages where contributors can vote to cancel the rest of the crowdfunding if milestones have not been met (votes would be proportional to the amount they funded).

In the first case, it would require a generic vesting contract that can be parameterized appropriately. The second one also adds a fair bit more logic to the crowdfunding contract. For both because they add complexity, it will add more to testing and so on.

Thereā€™s a lofi workaround to stages of crowdfunding which is just that someone creates multiple crowdfunding projects one after another. However where that breaks down is when you want to include locked in dispersment of tokens based on milestones.

The bottom line is that adding in these additional mechanisms will definitely push the budget of the project beyond the limits of the CCBL (at least at current SCRT price). There are two ways I see proceed: keep the proposal as is, once it is developed if there additional features that people feel are must haves, then that can be a follow-up project. Or I work out a new proposal, but one that just goes on chain but not as a CCBL project. Iā€™m leaning toward the first option because my sense is that doing a smaller project that delivers relatively quickly is a good first goal. It will still be a useful tool, and thereā€™s no reason more bells and whistles cannot be added after that. I will keep this forum going for another 3 days for any additional comments on this before doing anything.

Finally, regardless of the scope, I will definitely continue to involve stakeholders such as Bizdev regularly to get feedback as I develop the user interface for the crowdfunding site. In the end it would great for crowdfunding to be seen as one of the main avenues for getting projects going on the network alongside grants, VC funding, and incubators.

1 Like

Thank you for the additional details, this post also addresses some of the concerns mentioned earlier in the thread regarding future plans and worries that it would be ā€˜abandonedā€™ after completing the CCBL bounty.

The CCBL definitely is meant to enable proof of concepts of larger projects, which is what you are currently leaning towards it seems. Following successful completion of that PoC, it should then hopefully be easier to get follow-up funding through other sources.

You mentioned in the opening post that you are hesitant to incorporate a fee structure, would that continue to be the case in the expanded application (after the PoC stage)? What kind of upkeep costs do you expect for an eventual final product?

1 Like

Thanks for the feedback!

Yes, I would prefer to keep it a free and trustless system regardless. I can envision a version of the crowdfunding website that essentially needs no upkeep cost. It is easy to host a modern website on cloudflare or IPFS for free, and buying a domain name for several years is cheap. Since the site would not be moderated, it does need manageable spam resistance baked in. The easiest solution is probably to require people make a deposit when they create a new project, and if enough people flag it as spam then the deposit is dispersed among the next successful projects as a little bonus.

Maybe the only other sticking point is what API endpoint(s) it uses. If the endpoint goes offline then that needs to be updated but that should not be a hard thing to do. Apart from that it would not need any more active monitoring.

Since the UI will be open source, there are no barriers to improving or updating the UI by anyone and spinning up their own versions of the website. There are some features like a keyword search engine for projects that might need off-chain indexing, but if the crowdfunding site is popular enough to require that kind of functionality then there is probably a pretty good case for that to be built. In the meantime I donā€™t think it is necessary. People will be able to choose categories for their project and it will be possible to view projects filtered by those categories.

But to go back to your original point, yeah I have no interest in doing the work to develop this and then ā€˜abandonā€™ it before it is doneā€“I want to build something that is actually useful to the community. In fact, I have other projects that I would actually like to use this platform for and I doubt it would sit well with people if I abandoned this project or left it in a state that was not very usable. My main point is that we can build it in a way that minimizes centralization and if it is done well then it should not require any significant running costs.

2 Likes

Thank you for all your extensive ideation sessions and feedback rounds with the community.

If you think doing a smaller project first will not hinder future ease of development/upgrading then that is fine with me. I would like to see the project get build, any and all open source contract usecases are a plus for a network. I 100% agree with a focus on low upkeep cost and it needing to be a permission less platform (to avoid legal problems).

Only feature i can see being important later is a KYC integration, maybe we can mix Certik by Trivium in with that. (some form of sybil resistance/liveness etc)

I just want to point you to a contract for SNIP vesting which might ease development. GitHub - digiline-io/snip20-token-vesting

3 Likes

Thanks to everyone for their feedback on the crowdfunding platform proposal. Your suggestions have resulted in a much better proposal. I have now put this proposal on chain. https://secretnodes.com/proposals/109

The full ask is 18679 SCRT based on 7-day average price of SCRT @1.06 + 10% volatility buffer.

Vote YES if you would like to see this work funded. Vote NO if you do not want to see this work funded. Vote Abstain if you are unsure or do not feel you have enough information to make an informed decision (please feel free to contact me if this is the case). Vote ā€œNo with Vetoā€ if you do not want anyone else to ever put in a proposal for a CCBL project. :slight_smile:

2 Likes

Digiline is voting yes because the network needs more good examples of what is possible on Secret and not other chains.

Weā€™d like to call out some concerns that were deliberated on at length and hopefully do not present in future CCBL funding proposals.

  1. In general, the scope of a single CCBL project really should be limited to 1 month dev time - even if itā€™s a 1 developer project. The single developer exception should be removed in the CCBL guidelines. In addition to privacy by default, Secretā€™s top strength is also the ease and safety of the development experience. By completing an MVP in 1 month, the network shows the rest of the world the power and value of Secret

  2. Waiting 3 months before releasing anything for alpha or beta testing is a risk that could be avoided, again, if only there was something delivered in 1 month and then tested and iterated upon.

  3. Are there any signals showing actual demand for a product like this? We fear another Secret DreamScape scenario where the product is either a little bit ahead of the market or there is no viable marketing platform for the product. This concern is not blocker to voting yes at this time because the need for more open source example code outweighs the risk of an unused product.

1 Like

Hi @gino thank you for the feedback and voting yes despite your concerns.

I guess your first 2 questions are really more for the governance committee/CCBL WG. There was leniency added on the 1 month timeline for individual teams (2022-Q3 Community Curated Bounty List (CCBL)). In my case, I work full-time at another job so I can only do this project on a part-time basis and the time budgeted is less than 1 month full-time work.

Crowdfunding has been successfully deployed on other chains for commercial as well as public goods (see e.g. gitcoin). @dbamberger has contacted me saying there is interest from the BizDev side. I have also heard from others who would like to fund projects that donā€™t fit into the standard model. Whether or not specific projects will find funders/backers using such a platform is another question all together, but as it stands thereā€™s no way to test that and this project would allow that.

3 Likes

@darwinzer0 Thanks for the copious amounts of details that you included now! You definitely got my yes on this, wish you the best :slight_smile:

2 Likes

Iā€™m probably a bit late because I think this is already on-chain. But Iā€™ll add my comments regardles for the people thatā€™s deciding how to vote.

Fist I want to say that I think the core idea is great, there are many small projects that could benefit from this to bootstrap development.

However in the form proposed, even with all the added features I think it will be a feast for scammers sice there are no controls over the funds once a project has been funded and, being funded by SNIP-20 tokens makes it really easy to rug-pull.

In this form I would strongly encourage everyone to vote NO. This being done in this way could bring a lot of bad publicity to the network.

I would like to see:

  • Mandatory information to be provided: a video, a roadmap, funding plan for after the crowfunding campaign, mock UIs, etc. I.e. things that take time to put together and would discourage quick scams
  • Release of funds based on deliverables and approval by investors
  • Ability for an investor to pull their funds at any point before the proposal is fully funded
  • Restrict the ammount any single address can fund. E.g. no single address can provide more than 25% of funds (or another more suitable %)
  • After funding is complete, during the ā€œdeliveryā€ phase. Ability for investors to stop any further release of funds and get a refund from remaining funds proportional to what theyā€™ve contributed. I would make this require a high % of quorum and votes

Without these safeguards, and maybe more, I think this will bring more harm than good

1 Like

While I think your suggestions are good and it would be good to think more about these points for future versions Iā€™d like to highlight that this is a proposal under the CCBL structure. That structure allows for proofs of concept, MVPs, or projects that can be completed quickly. With all the additional features you mentioned it would no longer fall within the CCBL boundaries.

@darwinzer0 has said he doesnā€™t intend to abandon this project after the CCBL proposal milestones have been met. So the features you have suggested might make it into the final product, just not this early version that will be delivered under the CCBL format.

2 Likes

Forgive my ignorance but arenā€™t contracts on scrt immutable, I.e. not upgradable? If yes, how could these features be added after deployment?

Also I believe the intention is to make this available immediately after this proposal is completed. Therefore making it very easy to be exploited by scammers. If the features I mentioned donā€™t fit this type of proposal then that means that this type of product is not fit for this type of proposal

1 Like

Hi @votor133t thanks for your comments.

Scams have been discussed in the context of crowdfunding since it was first introduced. The fact is that some crowdfunded projects finish, others donā€™t but the stats from traditional platforms show that they do more often than not. I donā€™t really see how crowdfunding is any different than any other funding mechanism current available on secret network for risk of scams, though. The same could be said for going on chain, or for poorly vetted projects that are promoted by network leads (that is a much greater risk of concern for bad publicity, in my opinion).

Responses inline:

How do you propose to mandate this information-- every project is unique? People put together proposals on crowdfunding platforms all the time that are badly written without supporting information and those proposals do not get funded. People will be able to include video links, information about the team etc. and I would expect successful projects will do that.

This is not how the crowdfunding model works. Perhaps there needs to be two different versions of the platformā€“one that is traditional crowdfunding with rewards, another that is an equity crowdfunding platform for investors? Either way, as @pmuecke mentioned in his response, this is a CCBL project that provides a launching pad for additional features.

This is how it will work.

I think individuals can decide for themselves how much they are willing to contribute to a project.

This is similar to your second point. Logic for milestones is something that could be added but as I have discussed earlier in the thread this is out of scope for the size of a CCBL proposal.

First off, at the end of the CCBL work there will be a testnet version with UI and contract that I will solicit feedback about. I anticipate that it will be in shape to be able to be put on mainnet at this time, but if there are concerns at that time, I will certainly take them into account. Furthermore, immutable contracts are not really an issue here. New versions of contracts can be uploaded and the UI could be changed to point to those instead. Thereā€™s no reason that we need to stick to one version for all time.

1 Like

Thanks for taking the time to reply to my concerns. My main issue is that I donā€™t see the benefit of a simple crowdfunding app. It doesnā€™t look too different to the current crowdfunding model (NFT sales), except for the ability to pull out funds, thatā€™s good to have, thanks for clarifying that.

You keep comparing this to ā€œtraditional crowdfunding platformsā€ but itā€™s not really comparable because youā€™ll make it decentralized permissionless and private, all good things actually, but put together mean that the protections MUST be built in into the system. From kickstarterā€™s term of service:

ā€œThe creator is solely responsible for fulfilling the promises made in their project. If theyā€™re unable to satisfy the terms of this agreement, they may be subject to legal action by backers.ā€

There are no safeguards like this in this model.

Iā€™m all for a platform like this but done properly and safely. In a way that protects backers and projects. I only disagree on the community funding a proof of concept with no further development plans. I much rather the community pays more and gets a safe high quality product in return. It was mentioned that this os outside of a CCBL scope as a justification to vote ā€œyesā€. That argument actually suggests strongly that the vote should be ā€œnoā€ since the work needed for a proper platform exceeds the scope of a CCBL

Mentioning how poorly others do the same kind of funding, doesnā€™t really help your case. IMHO the community should be held to higher standards and also do better where others have failed to do so

1 Like

What Kickstarter is saying is there are no safeguards built in on their site either. :slightly_smiling_face: They leave people on their own to sort it out. And the same laws apply to people crowdfunding on secret network as on Kickstarter.

But I hear what you are saying, and I guess to me it is just comes to whether or not you think the funding on this platform should be incremental or not. Everyone who has contacted me about this seems to have a different idea of what the scope should be and Iā€™ve tried to find a middle ground. (This is highlighting to me exactly some of the problems with getting funding on chain, which this project aims to help with). But really even with all those extra features youā€™ve listed thereā€™s not really any way to prevent scams and rug pulls 100%. If you want legal protections to be effective, then you need KYC on creators and that is big project on its own that has yet to be built on SN.

1 Like

But the point about kickstarter is that you can sue someone because they jave to give information that would identify them, a bank account a company name, whatever. Tracking someone ising a SN wallet to receive funds is much much harder if not impossible (when done right)

I know itā€™s impossible to stop scams 100% but the safeguards I recommended would deterr most of the low effort, quick cash grab scams. And even if a scam is identified after funding users may be able to recover some of their funds.

Iā€™ve been rug pulled and I think having these things would help.

Re-reading the proposal I donā€™t see a step to deploy this on mainnet. That is good actually. As long as this wonā€™t be deployed on mainnet as is, I get that this could be used for further development. Has anyone else expressed the desire to further develop this?

1 Like

The proposal for the work plan as written is already on chain, and you are free to vote how you want on that version. In future I would suggest putting your feedback in earlier in the process, so it can be considered.

What you are talking about involves a number of very interesting problems to be solved, but they are not small problems. Much of what you are asking for essentially requires people making nuanced assessments of different scenarios. (E.g. how do you define a rug pull vs a failed project etc.?). There are many different kinds of automated mechanisms that could be addedā€“it is unclear to me which or how much those mechanisms solve the real concerns, however, and adequately exploring that space will require a lot more resources than is likely to be approved with one on-chain proposal. So we make do with getting things bootstrapped and build from there.

1 Like

Thanks so much to everyone who voted and for the overwhelming support to fund this project! Iā€™ll get working on it right away and will post regular progress reports here on this thread. :hammer:

4 Likes