Updated 300 days ago

AlgoCitizens

AlgoCitizens is a participatory budgeting platform for citizens to submit, discuss and vote for local initiatives.

  • Crypto / Web3
  • Algorand
  • DAO / Community
  • Social
  • Creator Economy
  • DeGov

1. Problem:

There is a great tool in modern democracy such as a participatory budgeting. It is a form of citizen participation in which citizens are involved in the process of deciding how public money is spent. For example, only the NY City participatory budgeting is ~ $40 mln ($1 mln per district). And ppl can submit their idea and decide on how this money should be spent. However, there are some issues that make this process complex, unclear and not that transparent.

issueas.png

2. Solution: We designed AlgoCitizines, a platform that helps citizens to submit, discuss and vote (or delegate) for initiatives of participatory budgeting and get their proposals self-executed and funded. Also, users can earn city tokens based on their activities (proposals, discussions, votes) which they can exchange on city products and services.

algo main.png

3. Key features:

  • Token-gated access: only user with Residence Permit Token (RPT) will be able to submit/vote at the platform.

  • Submit and discuss proposals. Once user created their proposal they should sign tx to "submit" it on Algorand blockchain and then discuss it before voting epoch will be started.

  • Each user will get limited #of votes per Epoch (voting period in participatory budgeting, ~2 months), so that they can choose most relevant for their district proposals.

  • User has voting power. It works as a multiplier and increased through: voting (winner proposal); submitting proposal (winner proposal); meaningful discussion (appreciated by community).

  • User receives proof-of-voting badge (NFT), with clawback fx to prevent malicious behavior.

  • User can delegate their votes(10 out of 10). Receiver will get entrusted_vote_power, and can use only one delegated vote for each proposal. Also, we added in the smart contract possibility to withdraw your delegation.

  • Killer feature: Exchange city tokens on a city transport card. Based on users activities and contribution, they will get city tokens which they can exchange on city products and services.

card.png

4. Business model:

Since it's a B2G (business-to-government) project, it should be sold as a standalone solution for local (city) authority through their standard procurement process.

5. Tech flow:

We deployed a smart contract to Algorand blockchain with the following functions:

  • add proposal
  • Voting
  • Delegating
  • Withdrawal delegating
  • handle User’s parameters (#of votes, RPT etc)

IMG_5617.JPG

6. Prototype Test it here.

https://testnet.algoexplorer.io/application/479755206

7. Tech challenges we faced in development:

  • Problems with setup (starter templates do not work out of the box with latest software versions). 

  • Setup instructions are not complete and no troubleshooting guides (what to do if build scripts fail? How to check if kmd is running? etc) 

  • Very hard to find anything on internet, no readily available stackoverflow answers.
  • Lack of high-level examples, most tutorials beyond simple samples are written in Teal 
  • PyTeal is very far from perfect language for a smart contracts development: hard readability; convoluted API; unintuitive conversions with mass of boilerplate get/set calls; not always consistent as to where to use ABI types and where to use Teal types; syntax for more advanced structures is impossible to get right from first try (named tuples or even simple instantiation of static array like abi.make(abi.StaticArray[abi.Uint8, Literal[12]]) is already overcomplicated, just compare with uint8[12] in other languages).
  • Overall, language is a primary tool for a developers and is very important for boosting ecosystem growth.
  • Poor language design hinders developer experience, leads to more bugs and undermine overall ecosystem in the long run.
  • Unfortunately, for now dev experience is incomparable with what, for example, Solidity provides. And it doesn’t look like Python-based solution can actually catch up. Some dedicated statically-typed DSL with modern syntax closer to what Solidity/Rust/Kotlin/Swift provide might have been a much better approach.
  • Incomprehensible compilation errors with big stacktraces
  • Complicated storage model (global vs local vs box? Value vs ReservedValue vs Blob? PyTeal box methods vs Beaker box methods?) - steep learning curve
  • Gas limitation - 700 compute cost is quite low as one hash only with keccak takes 130 units already!

8. Future plans: Handle front-end part of designed system; start communication with local authorities; polish smart contract to create 1st version of the platform.

AC final.png