WAGOI - Empowering drivers through data sovereignty.

Deciding
Content
AI Summary
Reply
Up
Share
Request
330KUSDC
Status
Decision28d
Confirmation
4d
Attempts
0
Tally
44.6%Aye
55.4%Nay
Aye
12.34MDOT
Nay
15.3MDOT
  • 0.0%
  • 0.0%

    Threshold

  • 0.0%
Support
0.13%
2.11MDOT
Issuance
1.59BDOT
Votes
Nested
Flattened
Actions
Or do delegation here, check wiki.
Call
Metadata
Timeline3
Votes Bubble
Statistics
Comments

Hello,

Could you please indicate if this project is EBSI compliant, especially regarding DID management?

How can the on-chain transactions you are submitting be validated?

Reply
Up

A resounding nay.

  1. First and foremost, the proposing entity demonstrates zero track record in blockchain software development and delivery. The proposal also lists no past work in the broader field of software development by the proposer. $330K for an MVP by a person/company with no prior demonstration of merit in a highly challenging technical domain simply doesn't make sense.
  2. The proposal states that the Android and iOS apps are going to be built with Flutter, which requires developers to code in Dart, while the detailed document states that the apps are going to be built using PlutoFramework, which requires using C# on .NET. If this is not a contradiction but a deliberate decision, the reasons for the switch should have been addressed in the document.
  3. Also regarding the development of the iOS and Android applications, the proposal cites zero past working experience, personnel, or any examples of previously delivered work in the field of mobile application development.
  4. The proposal states that smart contract development costs were dropped from $140K in the rejected proposal down to $70K, stating that "the previous budget was 140K - but we will start with Moonbeam here," with zero explanation of how the costs could drop simply by deciding to build on Moonbeam.
  5. Also following the previous concern, the budgeting lacks sufficient granularity. There are broad categories such as Backend Development and API Integrations, but no detailed information as to why these were considered separately, and what goes into each line item.
  6. There isn't sufficient information on how the proposer plans to tackle data privacy challenges on a technical level. There is no prior research or development by the proposer referred to in the proposal.
  7. Lastly, the initial document for the rejected proposal cites a tweet by Vitalik Buterin that refers to an article by Mozilla Foundation on poor data privacy practices by car manufacturers. It is a known fact that data privacy is an issue in this field, but again, the proposal provides zero explanation on what past experience the proposer is planning to rely on solving the serious issue of data privacy using blockchain technology, other than a list of buzzwords in the original document that fail to address the complex technical architecture (a clear threat model, Sybil resistance, protection of identifiers) required to back such a solution. Also, the one week allocated to finalize such a complex technical architecture is naïve at best.

In summary, the proposer should demonstrate skills and merit on a smaller budget, and ideally first address the technical challenges through a period of R&D and report back to the community before embarking on a budget and complexity of this size.

Best Regards,
kukabi | Helikon

Reply
Up

Dear Proposer,

Thank you for your proposal. Our first vote on this proposal is AYE.

The Medium Spender track requires 50% quorum (at least 5 aye votes) and simple majority of non-abstain votes according to our voting policy v0.2, and any referendum in which the majority of members vote abstain receives an abstain vote. This proposal has received five aye and one nay votes from ten available members, with three members abstaining. Below is a summary of our members' comments:

Voters expressed a range of positions, with several supporting the proposal due to its potential to drive wallet growth and transaction volume on Polkadot and Moonbeam through connected vehicles and compliance with upcoming EU rules. Some members highlighted the project’s promising market potential and strategic niche, emphasizing its attractive figures despite concerns over the proposed budget. Others abstained because of conflicts of interest or uncertainty regarding tangible benefits, while one voter opposed it, citing a lack of proven software delivery experience and urging a more modest initial investment. Overall, the discussion underscored both optimism about expanding on-chain activity and caution regarding project execution and costs.

The full discussion can be found in our internal voting.

Please feel free to contact us through the links below for further discussion.

DISCLAIMER: Our Decentralized Voices delegation voted to abstain on this referendum in accordance with our conflict of interest policy, announced on the 27th of March, 2025.

Kind regards,
Permanence DAO
Decentralized Voices Cohort IV Delegate

📅 Book Office Hours
💬 Public Telegram
🌐️ Web
🐦 Twitter
🗳️ Delegate

Reply
Up

PolkaWorld Vote: NAY

While PolkaWorld supported this proposal in the first vote, we believe the concerns raised by HELIKON merit a further response from the team.

In addition, we would like to see a more detailed breakdown of the budget — for example, how many team members are involved in developing each specific feature.

In the first proposal, our main focus was whether there would be future contributions back to the Treasury. We were glad to receive a positive response from the team on this. However, we’ve heard that a VC Bounty might soon be launched by the Treasury, which could be a potential avenue for funding.

More feedback here.

Reply
Up