xGov prop. 153 (Neighborhood Rideshare - Use Case)

ID: 153
Period: 3
Title: Neighborhood Vehicle Share -mobility as a service application-
Author: William H. (@dangnangdang)
Discussions to: here and Reddit - Dive into anything
Company Name: Lifeshare Revolution/Coollife
Category: dApps
Focus area: Deployment
Open Source: No
Amount requested: 300000
Status: Final


This project aims to transform vehicle rental/operation for members of society who have not previously been able to afford such a luxury. This is not the tokenization of assets explicitly, but a rather similar idea functionally.


Project manager: B.A. of Business Administration with a degree in Business Management. Technical Advisor: Ph. D in Computer Science. We are both physically in Texas, USA. Developer: We will use contractors until the point in time whereby the dApp is required to be created/maintained. We are hoping to trade equity to a trusted group of unicorn developers when that time comes.

Experience with Algorand

We have minted our ASA and we have two to choose from. One has 4B total supply and one has 8B - both are adequately positioned pricewise to offer a low entry point to investors during the token presale.

Present Proposal

Phase 1 - Grant proposal, incorporation & legal/accounting setup, token presale - given the costs associated with these items, the passing of this proposal is necessary for the advancement of the project. Phase 2 - R&D the compatibility/integration aspect of the member’s cellphone being the key to the vehicle. Phase 3 - R&D the modification/re-programming necessary of the vehicle’s on-board computer allowing monitoring and communicating via the vehicle’s on-board wifi - i.e. who is authorized operator, location, gas level, etc. Phase 4 - Project rollout in one major metropolitan area - currently thought to be in either Latin America or India. Phase 5 - Expand as the financial health of the company allows.

The end product/subscription is aptly categorized as mobility-as-a-service. The member will have the privilege of using a motor vehicle for two separate 90 minute blocks per day - that they are allowed to reserve.
Their length of subscription will determine the hierarchy of reservation - meaning they will get the same ‘place in line’ every reservation sign-up period opening. It’s is thought that 3 vehicles will be in the designated location - or at least 2, to allow for some inevitable friction within the operational environment. The daily cost to these members will be around 60-80% of the local one-way rideshare cost. We envision young people starting out - either in a committed relationship or just friendships - being able to chauffeur one another to work/errands. We share Algorand’s goal of making better-life things possible.

Future Blueprint

We have a 3-4 year plan to have vehicles available to the end-user/subscriber. Then we hope to expand as the financial health of the company allows from year 4-5 onward. This is the reason it is currently considered desirable to only presale a maximum of 10% of the company’s shares/tokens. Our currently proposed pricing/entry point easily allows for $6 million to be generated from the sale of this percentage. This is deemed enough to fund the project through phase 3.

Benefits for the community

The benefits to the community are difficult to overstate. Lots of new wallets, lots of MRB/Vs, lots of opt-ins to USDCgo, robust support to the Algorand defy sector, and of course daily transaction volume. We plan to use a WEB3 payments widget on the presale website - which I’ve received estimates of over $20,000 + 5% commission as the cost associated with this and is a critical element prompting the necessity of this grant - to require a double transaction to/with Algorand for a minimum of USDC or STBL to enter the contract along with the Algorand -ALGOs, to swap for our token.

Additional information

We will not offer/sell our token in the United States. We have a marketing strategy and website to target native Spanish speakers. The proposed project manager is a fluent Spanish speaker. Cool life in Spanish is vida chida and www.vidachida.com is all ours!

The proposed project manager cashed out his government retirement account to invest around $20,000 in the project’s establishment/success. The community should be reassured that we’ve plenty of personal ‘skin in the game’. The ALGOs requested are needed for 3 things primarily: the previously mentioned widget for the token presale website, incorporation costs in a tax-friendlier jurisdiction, and marketing costs associated with directing traffic to the presale website. Therefore, 80% of the requested ALGOs are requested immediately to cover items 1 and 2. The last 20% can be released after proof of success regarding the widget and incorporation if that’s deemed desirable by the keepers of the ALGOs.

We plan to use an NFT as the membership card to our service. The NFT/cellphone also serves as the keys to the vehicle by utilizing the vehicle’s internet connection in combination with the cellphone’s NFC technology. This NFT will require an amount of our ASA to be burned to create - which will create a steady supply of market token buyers. If it’s deemed a subscription to the dApp is better functionally, then say maybe half of the fee will automatically be used to burn tokens off the open market.
This is not some meme or moonshot coin. Our ASA - in the beginning - is tantamount to new shares of stock in a company. Our plan is tenable and our vision is supernatural. We believe is a perfect trial use-case for this wonderful technology - thanks SM!

I have a concern that the project hinges on these things being successful. While perhaps technically feasible, isn’t the actual implementation of this going to be dependent on cooperation by car manufacturers?

Certainly car companies let you download their app, register your car and the app with them, and then do things like start, check car info, etc. But, I can’t fathom these companies letting people tinker with and get permissions for a third party app to control it (at least not without being given a lot of money).

What is the actual “crypto” element here? Is the only thing that leverages blockchain the payment aspect? Or is there something unique as to this proposal that only blockchain solves?

I’m struggling to understand why the same results couldn’t be achieved by just having existing things like Uber, Turo, SnappCar, etc just integrate crypto as a payment option.

This project is ambitious for sure, with many obstacles. But to quote one of my country’s pioneers of industry, “Obstacles are those frightful things you see when you take your eyes off your goal”. But I will expound, because I don’t intend to sound trite. Cooperation by a car manufacturer, and we just need one, would shorten the project’s time to completion. One like Maruti Suzuki is currently considered a desirable one, especially given India’s recent proclamation to incubate/support all things web3 (maybe some helpful government nudging). The needed source code would be exponentially harder to reverse engineer, but all we would be asking for is the part designed/engineered to address the keyless entry aspect. We do not believe this specific aspect is considered secretive/proprietary at this stage in the evolution of automobile manufacturing. And maybe a company will accept a small percentage of our tokens in return, contractually locked until Phase 5; no cost to them, only “opportunity gain” so to speak.

I also want to reiterate here that this grant proposal is sought for the sole purpose of getting the project off the ground. The funding of the project will come from our token presale - which is just one of the aspects requiring blockchain utilization. You do make me reconsider raising the total amount of funds raised from the initial token presale, but we also want to keep in mind investor success - so that means a fine line needing to be walked there with respect to the project’s tokenomics. Thanks for the feedback/interest!

To operate in the proposed manner, the only way this project can work is blockchain. A system that automatically “updates” every few seconds. Say a member/end-user wants to use/reserve one of our vehicles at the last minute during an upcoming open “window” the vehicle currently has - or even just consider the weekly or bi-weekly reservation system (yet to be determined which). We can’t be constantly updating all that “manually”, and consequently requiring all end-users to manually update the app on their phones - that’s overtly unfeasible (especially once we are able to branch out to various locations/countries). It has to be a dApp to work - plain and simple! And we all know Algorand is superbly positioned to accomplish this kind of “work”.
Thanks again! And I might as well thank Silvio again here, regardless of how the community votes on this proposal (Divine inspiration I swear).

It doesn’t have to be a blockchain dApp to work. SnappCar lets you do everything you suggest using their app. It is all just automated through their app and servers. I’m not seeing anything here that needs blockchain to work. Nor am I seeing how this makes things simpler by using blockchain.

Maybe an app does turn out to be better. I still think blockchain might be necessary for solely electronic keys that don’t manually need to be passed/obtained.
These tokens are actually shares in the company right now, so either way - we need this funding to get either “off the ground”.
Then there’s my reward structure and tokenomics, which both basically ensure mutually assured success. This is the application/project y’all have all been waiting for. Together we can make a healthier team. Let she/he who has ears hear. Father, please move that mountain.