Example Use Case: Charity

[bitwalker]

As an exercise in examining how various parts of the rollup would fit together, and in particular what it would look like as a user in various roles, I came up with an example use case that I think could be useful for future discussions. What I'm hoping to discuss here specifically though, is how we envision this kind of use case working in the rollup, as well as what the experience of writing programs for it would be like.

---

Let's assume that we've done some research and discovered that a non-trivial number of people in the community would like to donate to humanitarian causes, but experience some form of analysis paralysis due to the overwhelming choice in the number and variety of such causes, and end up not donating at all. As we're interested in solving this problem, we've decided to implement a protocol that allows the community to donate to a common pool which is then distributed proportionally to the top 10 most popular charities as determined by the community. The rules of the protocol are as follows:

• The protocol owner provides a list of all accounts at protocol creation which are eligible recipients of donations. This information is public, so that the community can evaluate and provide feedback on the list, as well as verify that the accounts belong to the charities claimed by the protocol owner. Changes to the protocol and the list are not permitted after creation, to protect against a malicious protocol owner from modifying the protocol and taking donations for themselves.
• Members of the community donate by sending funds to the protocol account, along with a ranked-choice vote of the 10 charities from the list of eligible charities that they would like to see donations go to. Invalid donations are returned to the sender.
• Donations have a required minimum amount (i.e. you cannot donate nothing)
• Donations may submit a vote with fewer than 10 charities, but all charities must be in the list of eligible charities maintained by the protocol, or the donation is rejected. A donation with no vote simply adds to the pool.
• You may donate any number of times, and each donation provides another opportunity to vote.
• A weight/multiplier is associated with each vote based on the size of the donation, i.e. the minimum donation is equal to 1 vote, but 10x the minimum donation is 10 votes. This encourages participants to donate more if they wish to have a larger impact on where the funds will go, and ensures that 1 donation of a large amount provides just as much voting power as many donations of smaller amounts.
• Once a month, the votes are tallied, and the funds are distributed based on the proportion of the total vote that each charity received. If there were donations, but no votes, then all charities receive an equal proportion of donated funds. Ideally the monthly nature of this would be automated, but if it requires a transaction to be submitted, then either the protocol owner or any of the charity accounts may submit a request to release funds, and if all the criteria are met, then the protocol distributes the funds to all parties.
• When funds are distributed, the vote counts of all charities are reset to zero

A couple of simplifying assumptions:

• Let's assume programs are written in Rust
• Let's assume the state of the protocol is equivalent to HashMap<AccountId, u32>, where the key is the identifier/public key of the account associated with a charity, and the value is the number of votes received since the last distribution of funds
• Let's assume that all donations are denominated in the same currency (whatever currency underpins the rollup)
• Assume that vote counts saturate on overflow, i.e. u32::MAX + 1 == u32::MAX
• Assume it's fine that if multiple charities overflow to u32::MAX votes, that they are going to receive equal distributions, even if the actual number of votes would have been different, since in practice this is unlikely to happen

With that in mind, I have some questions:

• What does the program I write (as an account submitting a donation) look like? Do I need a special account to submit a donation (i.e. an account used solely for interacting with this donation protocol)? All accounts are associated with some quantity of funds, correct? Are those funds in a particular denomination, or is that defined by the account?
• What does the program written by the protocol owner look like? Are there two accounts required here, i.e. one representing the protocol state, and one which is used by the owner to issue administrative commands, or can they be the same? Are there constraints on how the storage is represented, or is that entirely left up to the implementation?
• Are there ways to represent scheduled tasks in the rollup, or must someone submit a transaction to trigger events like the distribution of funds described in the protocol rules?
• What does the program written by a charity wishing to participate and receive donations look like?

I'm hoping this will help determine what approach we need to take with the compiler toolchain, e.g. how projects are structured, what metadata is needed, what artifacts are produced and how are they bundled, etc. That said, I think it's also useful to have a more comprehensive example to use as a reference point for discussion than just a simple wallet, since it helps clarify what extension points are needed, and how custom behaviors will be expressed in a language like Rust.

/cc @bobbinth