The dev fund has short funds and long ambitions with huge responsibilities. Critical work on moving from zcashd to zebrad comes to mind. We need better developer tools to make building something like this scooter rental easier. I’d like to see smaller steps towards this with smaller budget. Are your running a full node? Can you detect payments and run automation based on payments to this wallet? How are you doing it? Maybe you could write tutorials and howto articles on free2z to journal the progress, help the ecosystem move forward, and gain some ZEC in the process.
I see not much on free2z, you haven’t shared much knowledge there:
I like having a big vision for a goal to guide progress but Zcash needs small steps with small budgets to iteratively move forward. The ecosystem hasn’t done well with big budgets for big goals in general. We need to start breaking up large budgets for large projects in general and reward progress iteratively and granularly.
I’m not saying your budget is too big for the ambition. In fact, it’s extremely small, probably way too small to deliver the whole thing. But, the Zcash ecosystem isnt ready. There are a lot of core priorities that need to get funded. Running a zcash node will be relatively expensive, slow, possibly not too reliable. How are you going to detect the payments? What interface, what programming language? Do you have experience running and upgrading a node and running automation against it?
I’d recommend working with Zechub and Free2Z and making smaller progress for smaller rewards. The ZecHub model has been proven. Break down the work into smaller bites and demonstrate the value step by step. Try things, document the progress, keep the community posted. Active contributors are being rewarded value-for-value.
The plan here would be to start against zcashd and move to zebrad? Probably choose something more like helping to move, test, document zebrad and make that interface great rather than building something against zcashd only to have to port it immediately?
@skyl, thank you so much for your sincere and realistic comment, however I will respond thus;
In as much Zcash is focus on critical work on developer tools, my question is do we really want to get high number of ZEC transactions or we just want to keep building projects that does not lead to massive Zcash adoption?
I am not asking for upfront funding but based on milestones completion
I am glad you mention that this grant request is relatively small compared to others that have received hundreds of thousands of USD from Zcash and yet Zcash is still having the adoption challenge.
Please note that I am not here to discredit any project, but If I may ask sir, the platforms you ask me to work with, apart from educational content creation on those platforms which is very good, how is Zcash wallets or ZEC being used compulsorily on these platforms?
I have learnt so much from here and it has broaden my web3 experience in general.
I noticed so much focus on media related projects, when some of these projects do not onboard their users with either Zcash wallets or ZEC transactions. My question thus, is Zcash ready for mass adoption or continue to support projects that does not translate to Zcash wallet usage nor does it involve ZEC transactions.
I want to believe that the entire Zcash ecosystem wants Zcash to be adopted by many & I also want to believe that we are not sentimental here, that we are fully decentralized without any regional biases.
At this point, I will only wait for the outcome of this grant application and I sincerely appreciate everyone for your comments. Thank you.
One of the pathologies of the current dev fund is that most people view it as a source of USD. And, for accounting purposes in the US, grants are treated as USD income. The dev fund doesnt have USD and doesnt pay USD though - it pays ZEC. Potential buyers of ZEC are the ones who may be willing to exchange for the granted ZEC. But, in a bid ask market with limited liquidity, the actual USD amount can not be retrieved. Taxes are paid on a fictional amount of USD.
There needs to be a substantial shift in this perception. The dev fund does not receive USD and does not pay USD.
Why did you put a transparent address on your free2z profile? If you used a unified address or shielded address then I could send messages and funds to that address. I would rarely if ever donate to a t-address unless there is some cool reason for the transparency.
On free2z you can buy 2Zs with Zcash that can be used for a bunch of things, you can comment with Zcash, send messages and ZEC to shielded addresses p2p. We implemented polls and goals using viewing keys. As one of the only people who has apparently ever implemented long-standing automation with shielded ZEC payments, I can tell you that it’s not ready for something like scooter rental at scale. We need to take incremental steps towards building the tools for bigger consumer-facing ideas rather than shoot for the consumer-facing ideas directly.
Here’s an analogy. We have some people and some hand tools. There is a huge mountain full of precious metals. We could send a few people to the mountain with hand tools to pick away at it. But, a better approach would be to work to improve our tools and our plan. One of the main tools is going away - zcashd. So, it doesn’t make sense to send a couple of people to the mountain with this old hand tool.
Maybe people have questioned the use of the 2Z credit on Free2Z as opposed to synchronous, onchain functions. Wouldn’t it be cooler if everything was onchain? Actually, no. If you were going to implement scooter rental to be paid in Zcash, you would inevitably arrive at a similar system of credits where people could load up a balance ahead of time (with Zcash, other crypto, or fiat) and then instantly use the credits when they want to do something. When actually activating a scooter, people dont want to wait for their wallet to sync, wait for blocks to confirm, etc. Just like when making a comment on a website, people want instant, synchronous, ACID functionality that they are accustomed to.
It makes me think of a new idea: renting scooters with 2Zs . Really, you need a traditional database with secure user accounts, a system to buy credits (with Zcash), an API, a UI ,… rebuilding all of that generic functionality is a lot more work than people like to think. But, prove me and other doubters wrong! Do it onchain and spark an instant automation from a ZEC payment. I suggest you strip it down to the minimum viable proof of concept though - here is a zebra node, here I send a payment, here is a minimum event triggered in the “real world” - flipping a simple switch based on the amount. What are the scaling challenges?
Sir, i do understand this clearly, that most blockchain protocol grants payments are made in their respective cryptocurrencies via their compatible wallets, and these grant are valued in USD.
So my usage of USD here is for the financial value of the grant project and not the currency being used for grants payment transaction.
Just for the records sir, it will be a classical fundamental error for any blockchain protocol not to make payment in their own cryptocurrencies, be it grant beneficiaries payments, or projects payment, as well as staff payments, this is because “…charity they say begins at home.”
Zcash adoption, as well as ZEC usage must start with Zcash and the entire Zcash ecosystem, as well as everything that relates to Zcash. Anything short of that, is just mere child’s play.
@ogasky Thank you for your submission. After consideration from @ZcashGrants and sufficient time for the community to provide feedback on the forum, the committee has decided to reject this proposal as it is out of scope.
The committee appreciates your grant submission efforts and encourages you to continue as an active member of the Zcash community going forward, both here on the forum and in the below avenues as well:
I knew clearly that it was going to end up this way, as it was never new to me here. But in all, special thanks to everyone for your comments.
However, my advice to the Zcash community is to treat everyone equally and be free of regional biases, in order to advance the Zcash blockchain just like other blockchain protocol. We must learn not to under rate anyone irrespective of where the person is coming from, because the solution you seek, might be with that person.
Also, those exploiting and depleting Zcash financial resources through grants valued at several hundreds of thousands in USD with payments in ZEC, with no commensurate returns to the Zcash protocol, should stop it. And those leading the Zcash protocol should focus more on used cases projects, infrastructures, tooling as well as educational activities with meetup events in various cities across the world. At this juncture, I rest my case.
Thank you all for the wonderful experience received here.
The decision has nothing to do with the region and everything to do with quality of submission.
I suggest you take the patient advice of @skyl and break down your work, as well as concretely demonstrate to the community that you have relevant knowledge and ability.
@ambimorph Thank you so much for your concern but the truth is I have gone pass the grant application outcome. Without missing words, even if a grant application for as low as 20,000 USD in value, is coming from this region, it will never be approved, or should we put it to test? There is high level regional sentiment in this ecosystem which is not really healthy for the advancement of the protocol. The truth about life is that, “…a rejection from one protocol could lead to multiple acceptance in other protocols”, so I am not angry and I will never be angry, but I will only keep saying the truth and my observation with things here. Thank you
. Really, you need a traditional database with secure user accounts, a system to buy credits (with Zcash), an API, a UI ,… rebuilding all of that generic functionality is a lot more work than people like to think. But, prove me and other doubters wrong! Do it onchain and spark an instant automation from a ZEC payment. I suggest you strip it down to the minimum viable proof of concept though - here is a zebra node, here I send a payment, here is a minimum event triggered in the “real world” - flipping a simple switch based on the amount. What are the scaling challenges?