Not every project needs a grant. Sometimes it needs a way to ask for help.
Imagine an open-source developer whose tool is used every day but who still cannot afford to maintain it. Or someone organising a community initiative with people ready to help, but no straightforward way to turn that support into funding.
Potlock began by helping Web3 communities fund public goods. Projects could register, accept direct donations and apply to Pots—funding rounds where sponsors supplied a matching pool and community participation influenced distribution.
That infrastructure solved a real but specialised problem. Wallets, on-chain identity, verification, matching calculations and round-specific rules made sense inside Web3 funding programmes. They were not necessarily where a filmmaker, maintainer or local organiser wanted to begin.
As Lead Product Designer, I worked with the team on a larger question: how could we bring the funding infrastructure to people who simply wanted to raise money for a project, cause or idea? Campaigns became our path into that broader market.
- 01
Pots and public-goods funding
Register projects, apply to funding rounds, meet eligibility requirements and raise matched donations within Web3 communities.
- 02
Campaigns for projects and causes
Create a public fundraiser, explain the goal, share it with supporters and make the funding conditions understandable.
We had the infrastructure to distribute money. The opportunity was helping more people raise it.
Campaigns became the bridge beyond the Web3-native use case.
Someone raising money for a project or cause should not have to organise a quadratic funding round. They want to describe the initiative, establish a target, share it and help supporters understand what their money will do.
Campaigns needed a simpler fundraising narrative: what are we raising for, who receives the funds, how close are we to the goal and what happens if the goal is not met?
The creator journey focused on describing the initiative, identifying its beneficiary, establishing its funding conditions and publishing a page worth sharing. The donor journey prioritised purpose, progress, terms and the next action.
We also separated creating a campaign from being officially endorsed by its beneficiary. A success screen explained when a newly created campaign would remain unofficial until the organisation approved it. Creation could not be presented as organisational consent.
This was a deliberate move toward more recognisable fundraising. It did not mean every piece of Web3 friction had already disappeared from the 2024 designs.
An approachable Campaigns page gives causes and projects a familiar way to present fundraising opportunities. Use a recognisable campaign directory rather than requiring every donor to understand a Pot or matching round.
Trust came from explaining what happens to the money, not simply making the transaction button obvious.
A familiar campaign still carried real financial consequences.
Campaigns could use minimum targets, defined time windows and conditional escrow. Depending on the configuration, funds might not be immediately available to the beneficiary. If the conditions were not met, donors needed to understand when and how a contribution could be refunded.
We designed progress, ownership signals, fee breakdowns and refund actions around the moments people needed them. Before confirming, a donor could inspect the amount entered, the relevant fees and what the beneficiary would receive.
Blockchain made the transaction technically transparent, but a transaction hash did not answer the practical question: where did my money go? The interface had to translate infrastructure-level transparency into product-level clarity.
These states also had smart-contract implications. Product, design and engineering needed consistent definitions for campaign status, transaction finality, fee allocation and refunds. The interface could not promise an action the contract would not allow.
Simplify the experience, not the truth. More policy information used space that could promote the campaign, but that space was justified when it changed someone's understanding of the commitment.
- 01
Show the commitment
Explain the minimum, deadline, campaign status and beneficiary relationship before asking for money.
- 02
Show the movement of money
Connect the entered amount, fees and net contribution within the same transaction review.
- 03
Show what happens next
Make escrow conditions and refund eligibility understandable through explicit states and actions.
We explored a wider funding toolkit, then chose not to build it all.
Alongside Campaigns, the Pot V2 exploration considered quadratic funding, ranked-choice voting, stake-weighted voting, donation-gated participation, human verification and a more flexible deployment wizard.
An assisted recommendation concept let an operator describe the outcome they wanted instead of choosing a mechanism by name. The exploration was useful because it exposed both possible value and implementation cost.
Each mechanism could introduce new smart-contract logic, eligibility constraints, role permissions, interface states, security review and long-term maintenance. The concepts were not even all the same kind of thing: quadratic funding is an allocation method, while human verification is a participation condition.
Campaigns was producing the more compelling transaction signal for the team. We decided not to engineer the entire mechanism catalogue simply because it had been designed. We prioritised the clearer fundraising route and retained the research for concrete partner requirements.
The demand signal reflects the team's product experience, not a published feature-level conversion study. The mechanism screens remain design artefacts unless separately documented as released.
- A
Build every funding mechanism
Create a highly configurable product before knowing which combinations organisations would use or support financially.
- B
Campaigns first; customisation on demand
Invest in the clearer use case while retaining the wider exploration for validated programmes and partners.
The explored selection screen presents quadratic funding, voting approaches and verification-related choices. Not all options are the same kind of rule; the difference mattered to the product design. Compare mechanism choices before asking operators to configure their financial rules.
Research can create valuable options without obligating the team to ship them all.
Meta Pool DAO brought back an idea we had chosen not to build.
Then Meta Pool DAO approached Potlock with a concrete programme. They wanted to give back to their community by rewarding public-goods contributions, but the decision could not be reduced to a standard quadratic matching round.
In our conversations, the requirements became more specific: participants needed to verify they were human, governance participation had to matter, and staking-related signals could increase voting weight. People needed to choose eligible projects, understand their influence, sign the required transactions and follow the result.
The important moment was recognition. This combination of verification, weighted participation and alternative voting was close to territory we had already brainstormed during the broader mechanism exploration—and deliberately chosen not to build without validated demand.
Meta Pool DAO supplied that demand. Instead of reviving the entire configurable mechanism catalogue, we focused on the programme in front of us. I translated its rules into a participant journey and interface states that made eligibility, vote weight, project selection and outcomes understandable.
That changed the meaning of the earlier exploration. It was no longer a collection of speculative options; one part of it had been confirmed by a real partner, a funded programme and a defined community need. The right response was selective delivery, not a universal builder.
The partner request validated a specific combination of rules, not every mechanism in the earlier exploration. The interface evidence shows the participant and outcome models; the published programme documentation establishes what was implemented.
The participant view connects eligible projects, remaining votes and weight-boost signals inside the Meta Pool DAO programme. Make the effect of verification and participation signals visible while someone is choosing projects—not after the vote is submitted.
We did not build the whole toolkit. We built the part a real programme proved it needed.
Leading design meant deciding which opportunity deserved to become a product.
The wider Potlock platform supported project discovery, direct giving and Web3 funding rounds. Campaigns reached testnet in 2024 and received its main public announcement in June 2025, creating a clearer entry point for fundraising beyond programme-based grants.
Across my time on the product, Potlock facilitated more than $709,000 in donations and 7,205 contributions, supporting 300+ projects and 7,000+ donors. Those figures show platform-wide activity; they do not isolate Campaigns or measure the causal effect of my design work.
The more useful business lesson was directional: broaden the audience through a recognisable fundraising experience, while treating advanced mechanisms as investments that needed validation. The Meta Pool DAO programme demonstrated that specialised funding logic could still be delivered when a concrete need justified it.
I learned that leading design means connecting user needs to engineering effort and business value. Sometimes the most important contribution is not another feature. It is helping the team decide which opportunity should become a product and which promising idea should remain an option.
Make the complex possible. Make the useful approachable.