Background
It’s lovely to see the growth in interest in NEAR public goods funding gaining traction. One of our main missions is to bring more eyes into public goods, public goods funding, and impact. First, with no clear way to discover projects on NEAR, we built a project registry on top of Web3 social, enabling a simple concept; the ability to give NEAR to projects & see who else was supporting. Then we enabled communities to run and pool capital for their own funding programs through quadratic funding. This was completely juxtaposed to the situation at the time in the NEAR Ecosystem, with the NDC transitioning into the grassroots DAO funding, and only DevHub & Mintbase providing grants based on vertical-specific projects. We came into H1 of 2024 wanting to achieve the following with runway support and $100,000 experiment of community funding seeded by the NEAR Foundation.
- Allow for people (humans) to discover and support their favorite projects directly and use this as a signal for future funding
- Enable communities to run their own funding rounds with open-source & permisionless tools
- Rapidly launch funding initiatives across different verticals
- Involve more of the community into funding decisions
- Build a complete application on BOS on top NEAR’s social graph
- Put out a signal to other ecosystems that NEAR cares about public goods funding & garner support from builders & communities
- Expand, operationalize, and spin out Potlock from a two-person team to a Labs, Foundation, and supporting contributing organizations
We did not initially build this to answer the question “How would we fix public goods funding and the public goods ecosystem on NEAR as a whole” .----- but rather how do we enable the community to pool resources for their favorite products
Around 3 months ago, Potlock shipped quadratic funding which is good marketing for raising awareness about public goods funding while incentivizing external capital and creating your own rounds, but essentially its a popularity contest that requires a smooth UX for proving personhood. (Check out the round retros for more insights) Rolling out a funding protocol with quadratic funding initially makes sense as a go-to-market strategy, but at Potlock, we are now building mechanisms for different use cases (tentative roadmap here). Some mechanisms are tailored to different use cases and already exist in some form in other ecosystems, while some are completely novel.
From now on rather than a single funding mechanism as part of a core product, in the rest of 2024 we are focused on creating a multipronged approach to not only allow the ecosystem a toolkit to self-coordinate funding, but to tackle the public goods funding in the NEAR ecosystem as a whole. It is important that as a builder-focused blockchain, we iterate fast, experiment, track impact, and allocate capital to more relevant use cases.
While the following objectives cannot be entirely achieved by just funding public goods, they can be achieved by building funding infrastructure that aligns with the growth of NEAR, and what treasury funds should be used for.
Overall Objectives for NEAR PGF
- Reward onboarding, retention, and user conversion into the broader ecosystem
- Proactively fund & acquire “skin in the game” for multiple vendors for each domain-specific problem to build maintain, and commercialize open-source software
- Reward builders and founders for ecosystem alignment, building a culture of good vibes, experimentation, high product velocity, and revenue,
- Allow founders to go from zero to 1, tokenize their ecosystem, and bring new liquidity & high LTV users into the NEAR Ecosystem
- Streamline the tracking of funds and impact across all funding methods to streamline support network, follow-up, diligence, and ecosystem ROI
- Enable communities to bring in capital and coordinate assets & interest-based communtiies to bootstrap more funding sources
- Pivot from a NEAR community for the sake of community first approach to a product and builder acquisition methodology
- Minimize governance hurdles and gamify decision-making
- Build attestation frameworks to better attribute onboarding & beneficial impactful narrative shifts by communities and KOLs
- Build community-based revenue-generating aqueducts to reallocate towards public goods to shift from NEAR foundation treasury
Mechanisms & Tradeoffs
Here are examples of funding mechanisms and their tradeoffs
| Mechanism | Description | Benefits | Downfalls |
|---|---|---|---|
| Direct Donations | Supporting projects with direct funding with no assets | Great for supporting projects without the need for KYC. With token incentives and tax write-offs this can be the most streamlined ways for traditional donations. Also known as tipping. As a primitive, this can be viewed as an on-chain invoice with a contextual memo. | Not always clear why you are donating, sometimes a campaign maybe suitable. If no ecosystem airdrops its purely out of altruism. Needs a clear impact measurement, tracking and reporting to see if their was ecosystem ROI. |
| Campaigns | Escrow-based campaigns system | Raise capital for an initiative that is target-based (with the option to return funds if a target is not hit by a date) and time-based. Better for things that are budget-based, and give the audience a sense of targets and strategic initiatives as opposed to direct donation Can be used as a way to convince funders that there is community support and to fund past a certain point. | Not good for governance or allocating capital to multiple entities. |
| Retroactive Funding | Airdrop or a no milestone grant given for work already done | Can create a culture of build and gaining traction first. Allows for environment where less people are asking for money. Rewarding people in an ecosystem with limited grant funding or already existing players. For verticals where things are easy to measure. Where subject matters from different backgrounds/biases exist | Proactive funding needed to create more complex builds. Some builds dont result in traction aligned with RetroPGF goals. Takes governance to decide metrics, and attest if metrics are not automated |
| Pairwise Voting | A budgeting process where options are presented in pairs, and participants choose their preferred option from each pair. The formula distributes funding by computing the preferences over all pairwise comparisons. | Reduced decision-making and gamifies the process. Allows to make funding decisions from large projects / proposals sets. | Doesn’t have a predictable funding amount. Doesn’t bring in external capital like through donations. Donations can be implemented in new versions of this Limits discovery for entire set of projects. |
| Quadratic Funding | quadratic funding is an inclusive funding mechanism that values the collective preference of a community for public goods by amplifying the contributions of many small donors rather than a few large ones. | Amplifies grassroots-level awareness and virality around funding verticals It’s a great way to de-incentivize whales for donation campaigns. | Need verified humanity which is difficult for UX. May need data scientist to monitor action and provide minimal collusion tactics. Not for scoped projects Unreliable & variable funding amountsTakes work from projects and becomes a “Keynesian beauty competition. Requires a matching pool to raise for and coordinate to be appealing. |
| Direct Grants | Directly issuing grants based on proposals sent to the treasury. | Good for new treasuries with program managers to allocate capital. | Takes overhead and reviewers. Not much incentives for the community to get involved |
| Lossless Lotteries | Lossless lotteries in DeFi allow users to deposit cryptocurrency into a pool, where their capital is preserved while earning yields, and random winners are selected periodically to receive the yield earned as prizes. This gamifies saving by offering a chance to win rewards without risking the initial deposit. | Can be directed to another cause not just depositors. In conjunction with an application and pool governance can direct rewards for a period to those who apply. Capital Preservation: Participants never lose their initial deposits, making it a low-risk investment opportunity | Opportunity cost for individuals who can just earn yield. Usually not used for project funding and has element of randomness. |
| Quadratic Voting | A voting mechanism where participants can allocate a limited number of voting “points” to different options, with the number of points allocated being proportional to the square root of the number of points. | It mitigates the “tyranny of the majority” problem by giving more weight to intense minority preferences. Voters with stronger preferences on an issue can allocate more voice credits to it. | Too reliant on identity and sybil attacks (creating multiple identities) can be used to gain disproportionate influence by splitting voice credits across wallets/identities. Makes sense if there is a lot of options to vote for like candidates or an influx of proposals. The quadratic cost function makes the system less intuitive and harder to explain to voters compared to traditional voting. Introducing “voice credits” that map non-linearly to votes can be confusing. Voters may not be able to allocate all their credits due to the quadratic nature of the cost function, leading to wasted votes. It fails to satisfy the “independence of irrelevant alternatives” criterion, meaning the addition of an irrelevant option can change the outcome. This opens up strategic voting opportunities. |
| Conviction Voting | Funds proposals based on the aggregated preference of community members expressed continuously. In other words, voters always assert their preference for which proposals they would like to see approved, rather than casting votes in a single time-boxed session. A member can change their preference at any time, but the longer they keep their preference for the same proposal, the “stronger” their conviction gets. This added conviction gives long-standing community members with consistent preferences more influence than short term participants merely trying to influence a vote. | It is good for large treasuries with a lot of inbound proposals where the treasury is determined by a token. It can support custom RFP and amounts It gives utility to token economies. There is less pressure to submit and approve proposals on time, and continuous rolling funding. | Need some type of reputation token. Not best suited for projects with a lack of in bound proposals. |
| Brackets | Potlock new concept, where projects or accounts are put against each other in tournament-style brackets. Projects are either voted on, donated to, or results from round is determined by on-chain or off-chain outcomes. Funding can be awarded at different distributions based on what tier of the bracket projects end up on. | Gamifies the way projects are matched against each other. Can be adopted for different criteria to award grants. Additional capital can be added to the pool. Can incentivize voters to vote correctly. | Where someone ends up on a bracket may not be on who is qualified, but rather who someone was against.Timely based and takes a marketing effort to rally people. Manager needs to control who can vote and who can apply. Someone needs to facilitate the round as there are many stages of voting. |
| Streaming & Vesting | Streaming payments in DeFi allow real-time, continuous transfer of tokens or assets to recipients, enabling use cases like salaries, subscriptions, and investments. Vesting or lockup contracts restrict the transfer of tokens for a specified period, promoting long-term commitment from stakeholders and preventing sudden sell-offs that could destabilize the project. In the case off Potlock, this can be accompanied with a cliff and a cliff payout. | Streaming is good for continuous payments for workers. Vesting is good token token equity agreements and making sure there is long-term alignment. Can also be used as a continuous revenue source. Can be combined with split for powerful community based allocation. | Not the best for instances where people need token for runway Is a payment type instead of a direct funding mechanism. Reporting on things like taxes maybe difficult due to receiving tokens at multiple prices Does not bring external capital through donations into a system. |
There are many more for the sake of brevity, we just outlined with mechanisms that are top of mind for us. For more mechanisms check out mechanism.institute as a resource
About Traction.money
In the context of this discussion, I want to raise the question of how do we perform retroactive funding to reward valuable ecosystem growth with minimal governance ?
Thesis
- Governance results in centralization vectors for subject matter experts
- There is a cold start problem. Founders don’t know if they should start to build something now without getting funded, because there is no clear way to get funded for impact later.
- Traditional metrics on dappRadar, flipside can be gamed, and we need to refine what is impactful as an ecosystem constantly
- Establishing measurable metrics that even if gamed still benefit the ecosystem will align the ecosystem to grow
- Often builders & founders who are shipping aren’t the same people asking for non-dilutive grants, there is a “governance cartel” issue
Objectives
- Get a higher rate of non-proactively funded teams to start building on NEAR with traction
- Create a minimal governance retroactive funding system that cannot be gamed with an initial pilot
- Create metrics from community sentiment that are not easily gamed and also translate to growth in revenue & network effects for NEAR
- Create a streamlined way to automatically reward projects retroactively based on ecosystem-aligned metrics
- Streamline towards an autonomous agent that can update metrics and allocate capital accordingly
Limitations
- This won’t proactively fund teams for clearly scoped projects that the ecosystem needs. Other funding mechanisms will exist for funding specific teams and funding initiatives. Meaning their is still a cold start issue of funding founders to build something to get traction.
- It is harder to track community-based metrics and the impact of developer tooling especially for closed-sourced projects
- Most of the people in NEAR who built something with traction have gotten grants or done a deal with the NEAR Foundation. It’s hard to establish a program similar to the retroPGF program. In this case, we need to directly fund projects that haven’t been funded and move to just traction-based rewards for retro funding.
- This proposal doesn’t reward users, this is up to applications, as they can reallocate rewards. If applications use other contracts, up to the underlying “protocol” to allocate their rewards to those who build on their contracts.
Reference: Since RetroPGF 3 with badgeholders, Retro round 4: On-chain builders they are more aligned with these “traction” metrics.
- Onchain impact metrics for Optimism Retro Funding 4 | Open Source Observer
- Upcoming Retro rounds and their design - Retro Funding 🔴 - Optimism Collective
Initial MVP
Rather than a product, initially, traction.money will be more of a process.
- The initial MVP consists of working with data providers in the ecosystem to develop dashboards based on these weights.
- Getting a distribution of payouts based on amounts.
- Publishing these amounts
- KYC’ing entities and then paying them out on a monthly basis.
What We Value as “Traction”
For each stakeholder, we care for
- Builders that their contracts and tooling are adopted and contributing to high value generating products in the ecosystem, and additional developer mindshare. This will be harder to measure due to off chain analytics, verifying source code, and also encompassing metrics from applications sections.
- Community whether certain communities are funneling in quality users into applications and quality developers. This is harder to measure, voice of share, general attestations, and can’t really translate traction into on-chain metrics. Moreover, an effective community that has mindshare may be limited by applications and developers’ resources resulting in low conversion and curn. On-chain referrals can be used to quantify what we have in Potlock contracts, but and on-chain onboarding touchpoints like linkdrops. However for the sake of the initial rollout of this system, we are putting it onto the project to reallocate their rewards to communities who onboarded them to their platform. At the same time, the thesis is products should build communities around and generate leads.
- Applications / Founders: active users with money that use many ecosystem-wide applications.
Possible Metrics
These metrics are just to start the metric and we appreciate your feedback.
High Level Metrics:
- Liquidity brought into the ecosystem through user base
- Amount spent by user base
- Assets launched and traction of assets, token + NFT liquidity + volume
- Number of users onboarded: accounts first interactions with contract
- Number of weekly active users
- Transaction fees generated from user base
Multipliers: actions that get applications extra points for their scrae
- Whether the user onboarded has trickled down into other applications; has interacted with other contracts and if regularly using other applications. (Indicates whether other applications in the ecosystem have low conversion)
- Asset-generating users: users who mint, deploy contracts, create tokens, yield farming, creates DAOs, funds public goods, etc
- Cross user interactions: whether users are interacting with other users directly, social engagement, tipping, swapping, referrals
- Life Time Value: churn against balance, and spent fees and amounts
- Human verified: by identity protocols, account fingerprinting, etc
- User balances, whether they are whales, onramping new assets, and have a basket of ecosystem tokens
- Behavior of users, if a user is a power users and transacts multiple times a day
- Open Source amplification → if contract code is verified with source scan and if that contract has been forked
- Factory contracts
Subtractors: On-chain actions that get a reduction in points
- Account Abstracted Accounts: if an account is subsidized from metatransactions than this can deduct points, unless the user has paid for a relayer service to streamline UX
- Noticeable bot activity, wash trading, or scam-generating users
- High churn or lack of user retention
- Noticeable lack of growth
- Clear user-buying
Concerns
- Do we take into account, if a project has charged a service in the ecosystem, does this discount their weight or are we strictly outcome-based?
- Do we take into account past funding amounts for payouts? Some projects have gotten more significant non-dilutive funding, staking to their validators etc, which makes them more sustainable. Or should it be an even playing field? Should we have a payout debt that gets paid out after past “credits” have been surpassed by traction points?
- Do we enable a maximum amount a project can receive from a round or make it directly related to metrics to prevent the monopolizing of rewards?
- Since contracts have 30% developer rewards, aren’t we already accounting for transaction fees?
- Are we optimizing for daily, weekly, or monthly users? Should we have different tiers for this
- Should there be penalties for ghost contracts that have gone completely dead?
Future of traction.money
- More automated and streamlined metrics
- Permissionless vaults that hold money in treasury rather than manual payouts w/ signers to approved payouts
- A governance process of getting additional metrics, making ”PRs” to queries for agent
- A clear dashboard showing ecosystem growth for projects as they evolve and potential earnings
- More fine-tuned metrics as ecosystem evolved.
- Ability to add rewards to overall pot based and pools based on certain metrics the community wants to optimize for
- Self-served metrics board → like automated quests means condition vesting, the ability to put in
- Tailor your own traction program + treasury for your metrics and weights and add a pool for NEAR chain
- Integrate a point system to allow others to airdrop growth metrics based on these scores retroactively.
- More streamlined insights on the attestation and the impact of funding and other funding sources on growth.
- Developers should be able to submit the source code of their smart contracts to an open-source repository.
- The system should verify the authenticity and ownership of the submitted source code.
- Data auditors and firms should be able to submit independent queries of correct information (potential rewards for this)
Dashboard
Some things to include in a dashboard
- Last time queries ran
- Leaderboard, able to expand on each metrics, percentage of total pot, and estimated earnings
- How score was developed
- Associated contracts
- Source scan verified whether the source code was verified
- Query on each metrics: Context on methodology of each metric
- Total amount for this payouts → next payout period
- Look up all last payout periods
Next Steps
- Get Feedback from the ecosystem
- Field top level metrics and prospective weights and scoring systems
- Secure consistent funding to reward
- Work with data team to contextualize this weight on a monthly basis
- Onboard main players and payouts based on proper KYC
- Work with flipside and other entities like pikespeak & sourcescan for signing ownership of contracts, assets and collections to dApps
- Reward teams accordingly via pilot program
Call to Action
- We want you to comment on your insights; What metrics should we focus on NEAR? What metrics are primary metrics vs amiplifiers? Any mechanisms you would like to see?
I really appreciate the learnings, teachings, innovations, and insights from our friends at the Optimism Collective, Arbitrum DAO, General Magic, Gitcoin, Mechanism.institute and Open Source Observor that influenced my thoughts
From,
PlugRel, Core-Contributor at Potlock
P.S while writing this NEAR Ukraine Guild submitted a proposal [Proposal to HoM] Automated Communities Grants Program