[Draft] Proposal for continuing developments on NuBits Android wallet

NuShares Grants
#1

Dear shareholders and community members,

Like to have your attention for a draft proposal for a custodial grant for further exciting developments for the NuBits Android wallet (see Link with info and Download link). The proposal is still ‘draft’ as I would appreciate a discussion and feedback from this community about the proposal before voting takes place. I suggest to leave it open for comments for the next few days and up to week depending on the feedback. After that I will consolidate all the comments into a final proposal and republish that soon thereafter allowing voting to occur.

The complete proposal have been posted as a Gist on my Github account. This was done so that the community can be made aware if any changes made to the document (through the version control system), and so that it can easily reviewed by Shareholders. If amendments to this draft proposal are required, I will clearly call them out within this topic and republish the final proposal for voting.

The draft proposal can be found here: https://gist.github.com/Cybnate/f38fed991467873ef9b2

Overview of grant:

Custodian: Cybnate
Proposal: Development of NuBits Android wallet
Submission Date: 14-Feb-2015
Requested Grant Amount: 28,600 NBT
Custodial Fee: 500 NBT
NuBits Grant Address: To be published with final proposal
Vote Amount: 29,100 NBT

Summary of grant:
The Development has been split up in 3 releases:
Release 1 Pincode Lock will take up to 3 weeks (1,300 NBT)
Release 2 Shapeshift API will take up to 12 weeks (14,000 NBT)
Release 3 Server Config will take up to 8 weeks (7,200 NBT)
Total 22,500 NBT*

I will deduct the donated 260 NBT (Link) from the grant and will also deduct the promised 1000 NBT donation to release 2 by Shapeshift. Total 1,260 NBT

The Marketing is for the advertising on CMC including a moving banner or multiple banner during 3 months and a Reddit giveaway soon after release 2 has successfully been delivered (NBT 6,100).

I’ve deliberately chosen to combine a bunch of work to be able to contract the same developer (Matthew M.) and secure ongoing development for the next 5 months as per the proposal instead of going piecemeal with the risk loosing the developer or slowing down the rate of further Developments.

I think it is clear that release 2 is the cornerstone of this proposal which will provide some pretty unique functionality. Given the complexity it comes at a considerable cost. Release two covers seamless payments with foreign coins while holding Nubits stable in value. It won’t cover receiving foreign coins at this stage given the expected significant additional development time and cost I haven’t included this. For the same reason I took out the ability to receive an email receipt during payment.

Marketing
When the release 2 functionality is in our hands I propose to make a good marketing effort to advertise the existence of the mobile wallet and the unique functionality. Advertising on CoinMarketCap.com with an attractive banner supported by a mobile webpage and a Reddit give-away is therefore part of this proposal.

Feedback
Love to hear your feedback about the costs, the marketing effort, my fee and the order of the releases or anything else you think can be done better or different. Check out the link to the gist above for all the details of this proposal.

– Cybnate –

4 Likes
GOOGLE MAY INTRODUCE BITCOIN ON NEW PAYMENT SYSTEM - Plaso
NuBits Android kickstarter-style pre-funding and roadmap - Please donate now!
#2

Well done, glad to finally read this proposal!

  • Costs: seems adequate to me and I trust estimation of the developer and marketing budget.
  • marketing effort : seems very reasonable to have a banner up there for a month. Did you take into account costs of designing the banner?
  • your fee : this is up to you and you should feel satisfied and take into account risks of the project being dragged and taking longer than expected or requiring much more interaction on your side. You can always ask for an “insurance” in case things goes wrong and commit to return it / burn it / donate back in case things goes right.
  • the order of the releases : this is also reasonable. I would add some intermediate checkpoints/sprints, maybe every two weeks.

Now, a section that might require some improvement is the risk section imho. Six months is a long time in crypto and other risks need to be taken into account, and exit strategies specified. That is, what happens to funds in case something goes wrong?

Then, we have this risk worth considering with care : what if in 6 months shapeshift is not around? And in one year?

Developer is not able to finish the product due to external circumstances, e.g. unavailability of Shapeshift API.

We have good mitigation here and the team on our side, but uncertainty is quite high. Shapeshift is doing a good job and I think we will see some competitor joining the scene soon.
Will the contract bind our dev to shapeshift? I suggest not, and leave it open for generic “instant exchange”, possibly more than one. The application should be designed in such a way that the API wrappers can be interchanged, to a decent degree (aka not requiring another 4 months of work).

For the rest, can’t wait to cast my vote.

#3

Thanks for some good feedback. Have been sitting on this for a while as I had to reduce the complexity and duration of the contract by taking out some desired functionality (see exclusions) and prioritize others. I think release 3 is important as it enables users to strengthen the resilience of their NuBits Android client if they wish. It doesn’t deliver such a server though.

Yes, although hard to estimate as the requirements haven’t been completed. Moving banner or multiple static banners.

Agree that we need something like that for release 2 given the duration. It is the only outstanding item I still need to settle in the contract. Maybe two weeks is a bit too often but I take your advice into the mix.

The gist has an ‘unexpected termination’ clause under Grant delivery.
The contract has exit strategies for both Developer and Custodian. We could both terminate in between releases before the initial payment for that Release is made. Practically that would only enable us to opt out Release 3 when Release 2 is underway of just delivered. The time between start of Release 1 and Release 2 is only 3 weeks max.

No, no contract binding, but Release 2 is built on the Shapeshift API only

Good one. However there is a high chance that an API from a competitor would look different and offer different functionality. It is very hard to specify and verify this without any examples on the market right now.
I guess the only thing a developer can do is setting this up on a modular bases and document it properly. It still doesn’t guarantee anything as the way new API might work can be very different. We have already seen this with exchanges and with upcoming decentralised exchanges it will get even more complicated.
Having said all this, I will take this aboard and raise with the Developer and see what we can do to mitigate.

Thanks!

#4

Just bumping. Was really hoping for more feedback, but I’ve probably been snowed under the events in the last few days. Hope you still have some time or just give a shout if you think I need to extend till e.g. the weekend.
Please review as it will be confusing when I need to change things when we started voting. Your time is appreciated.

When no further feedback I’m intending to close the feedback in next 24 hours or so and take a leap of faith.

Updates
Based on Desrever’s feedback we have added an item to address how API would technically be implemented in order to ensure API wrapper can be interchanged. In other words, it should be relatively easy when we need to move away from Shapeshift to another provider. Also added something around receiving a clear error message with limit when Shapeshift limits are exceeded. To keep things in budget and less complicated we simplified the use case. The text in italics replaces the text in the gist as published in the OP.

Alice want to pay merchant Bob. Bob only accepts Bitcoin. Alice scans the Bitcoin QR code and the App recognises a foreign coin. The App queries the shapeshift API for the payment details. The app presents the required NBT amount to Alice. Alice approves the amount and the rate and sends the NBT. The App shapeshifts the NBT into BTC and sends the coins to the designated BTC address of the merchant. The value of the NBT transaction will be visible in her App. The merchant will get the usual confirmation(s) in his Bitcoin wallet and won’t even know Alice paid from a non-Bitcoin wallet.

I will add all the changes into the gist when I publish the final proposal. These can be easily tracked.

2 Likes
#5

I apologize I haven’t been able to comment on this in more detail yet, as the past few days have been rather unusual for us. Generally speaking I strongly favor an aggressive advertising campaign to promote our mobile wallet functionality. It is a critical pillar of our Stage 2 marketing activities.

My only reservations now will be the size of the grant given our recent loss in shareholder funds. We will need to look at this closer in a week or so when the dust has settled around BTER and Exco.in and we have a better idea if the funds lost are permanently gone.

#6

Agree that we all need to assess the damage done in the last few days. However I still think this grant is worth it, unless we are completely broke, which I still believe is unlikely. Investing in the mobile wallet is still the best way to go to achieve the actual usage of NBT where in the end of the day we would get the dividends and benefits of transaction costs from.

When Shareholders like to postpone the investment, they can just hold their votes until we have a better idea of our losses.

1 Like
#7

Final proposal posted here: [Passed] Final proposal for continuing developments on Android wallet (v3.0 released)

2 Likes