# Funding proposal 1: Parallel Initial Block Download

**URL:** <https://forum.grin.mw/t/funding-proposal-1-parallel-initial-block-download/10584>\
**Category:** Governance\
**Created:** [June 13, 2023, 8:40am UTC](https://forum.grin.mw/t/funding-proposal-1-parallel-initial-block-download/10584 "2023-06-13T08:40:04Z")\
**Posts on this page:** 1\
**Showing post:** 22

<div class="post-metadata">

**Author:** ![l33d4n](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/l33d4n/32/5321_2.png) [@l33d4n](https://forum.grin.mw/u/l33d4n)\
**Post date:** [June 15, 2023, 2:18pm UTC](https://forum.grin.mw/t/funding-proposal-1-parallel-initial-block-download/10584/22 "2023-06-15T14:18:15Z")

</div>

**it sounds good but I think we should wait with the funding** to check how it goes with the rust first. **The beta just released 2 days ago** so in a few weeks/months after enough users try it and report bugs/improvements we will have a more stable version and enough information to discuss it.

**My main concern is to avoid another round of funding for fixing bugs, optimization, etc.**. I think that funding implementation now while it is still in the beta version is a safe way for additional expenses.

> [@Anynomous](#):
>
> 1. To have access to upfront payment there are two conditions a) all the deliverables for the previous funding requests must be finished, b) upfront payment for a milestone/deliverable is only accessible to developers and community members with a proven track-record such as @davidtavarez and @Yeastplume .

I am against any funding model that is not defined as **Code \> Release \> Payment** (or “Milestone \> Payment” in this case)

Upfront payment for milestones It’s just like the old funding request model, the only difference is the frequency of the payments and doesn’t solve any of the issues I mentioned here:

> [@CC Fund: expenses, responsibilities, spending guidelines and follow-up processes](https://forum.grin.mw/t/cc-fund-expenses-responsibilities-spending-guidelines-and-follow-up-processes/10522/71):
>
> **the funding requests method is much more complicated** , especially when we can’t enforce it, make sure what the end result will be or what will go wrong along the way **as happened several times. It worked, until it didn’t.**
> 
> > [@CC Fund: expenses, responsibilities, spending guidelines and follow-up processes](https://forum.grin.mw/t/cc-fund-expenses-responsibilities-spending-guidelines-and-follow-up-processes/10522/1):
> >
> > ![Follow-up tasks since 2021-10-21 (BTC)](https://canada1.discourse-cdn.com/flex036/uploads/grin/original/2X/1/183a0024d6721d75e8b7e4e889569223e6141984.png)
> 
> **The question that needs to be asked is, why put community funds at risk in the first place?**
> 
> **Bounties reduces the risk to zero** and simplifies the whole process with a **clear definition for the end result** , so we can avoid unnecessary arguments and dramas

I can expand if you want but we all know that the last funding requests did not go as we expected so if we want to avoid drama and keep it simple, that sounds fair:

> [@ardocrat](#):
>
> I think it will be more fair for all people who is going to be paid by CC Fund to follow same rules and be equal. We already had problems with track-record of last 3 months, so we learned from this.

---

_[View the full topic](https://forum.grin.mw/t/funding-proposal-1-parallel-initial-block-download/10584)._