Hey all,
Thanks again for the feedback, both here on the forum post and in the governance call from a couple weeks ago.
In a nutshell, the majority of the discussion has been along the lines of:
“I support spending a portion of the community fund on end user growth, but I’m not convinced that this specific proposal is the best way to spend it”
In light of our ongoing discussions, and addressing how the community engages with proposals and ideas more broadly - we have some ideas for discussion. Thanks to @nitya, @jackie, and @tim.
In order to have this discussion, I think it’s important to highlight the iterative nature of this proposal. I think it would be most valuable for us to focus on reaching consensus on a framework for how the community fund should be used to drive end user growth, as opposed to agreeing on a specific reward structure that we feel would be impactful, as that is something that the community can iterate on as we gather more data.
Framework
As I understand it, what we’re proposing is more or less a decentralized implementation of a standard consumer growth playbook.
To execute on this playbook, I think it’s helpful for us to agree on the following three questions:
- What are the goals of this program?
- How will we measure success?
- How will we iterate and learn?
This is what I would suggest:
Goals:
- Increase the total number of users using Celo as a payments platform
- Increase the engagement of users using Celo as a payments platform
Metrics:
- Sign up rate of users
- Distribution of cUSD balances held per user
- Time between signing up and moving value onto Celo (i.e. “cashing in”)
Iteration:
- Make some hypothesis, based on the available data, as to a specific reward structure that would further the program’s goals.
- Choose a subset of users to automatically enroll, the size of which depends on the confidence in that hypothesis
- Communicate the reward structure to the user
- Execute, via governance, the rewards distribution
- Compare the target metrics across the “experiment” and “control” groups to see if the reward structure had the desired effect
- Repeat
Technical implementation
When talking about a specific rewards structure, I think it makes sense to start with the technical implementation of how rewards may be be distributed, as that will restrict the universe of reward schemes that can be supported.
Because this rewards program is intended to be iterative, the technical implementation prioritizes flexibility. The idea is to borrow Uniswap’s Merkle Distributor contract, which allows, in a single transaction, a “commitment” to be made to a merkle tree for which the leaves are (address, balance) tuples. Users can then withdraw their funds by providing the merkle proof corresponding to their address.
Each on-chain governance proposal in this program would fund a new Merkle Distributor contract with the appropriate CELO balance and commit to a new merkle root.
Importantly, this implementation allows for the calculation of “which addresses receive how much in rewards” to be done entirely off chain. This calculation can be done in a simple, lightweight, verifiable, script, that can easily adapt to changes in hypotheses.
It’s also important to note that these rewards are calculated and distributed retroactively. The nice thing about this is that it allows for fraud to be detected before the distribution is made. On the flip side, it makes it impossible to fully guarantee a specific reward to users, since that reward is ultimately contingent on the governance proposal passing.
A first hypothesis
Celo is likely to face the same obstacles to adoption that many other two-sided marketplaces have seen in their infancy. The value prop to users depends in large part on critical mass of users on both sides of that marketplace.
We see an opportunity here to leverage the community fund to help “bootstrap” that marketplace by supporting a “single player mode”, i.e. reasons to use Celo even when the network effects may be limited.
Furthermore, we’ve learned from other mobile money initiatives that it can take a while for users to trust the platform. At first, users may be reluctant to leave money in the platform, because of a perception of increased risk as compared to cash.
One hypothesis is that a small incentive to hold cUSD, paid in CELO, may help attract users by supporting a “single player mode”, encouraging them to hold a balance of cUSD, which, when seeing that cUSD holds its value, will increase trust in Celo as a platform.
The data available here is limited, as are engineering resources (as always 
) so we’re proposing the first reward distribution be the simplest test of this hypothesis possible, by providing a reward to a randomly selected subset of users that have completed at least [3] attestations and hold at least [30] cUSD. The reward would be [2%] of their time-averaged cUSD balance over [two weeks]. Eligibility would be restricted to [5%] of users, chosen randomly based on their address.
IIUC, we would mainly expect this to influence the latter two metrics. I’m not sure how we would measure this experiment’s influence on sign-ups, since users will not know ahead of signing up whether or not they would be eligible.
