This is a discussion paper in response to Tjark’s Contributor Fund document. The views expressed here are strong opinions loosely held, and I expect my views to change as the discussion matures.

I participate in the PoolTogether community because I'm aligned with PT’s core values. Openness and autonomy differentiate PT from traditional finance, while positive-sum, secure, fair, and fun also differentiate PT from... many other things in crypto that I avoid talking about in polite company.

Sustaining and growing the protocol and its community is valuable work. There are multiple layers to consider in sustaining the work, however, and differentiating between those layers is important.

I see three core layers:

ADOPTION - The adoption layer is about growing use of the protocol itself, and its audience is people who want value from the protocol today. The first-exposure layer, this layer is focused on user experience, developer onboarding, and growing PT integrations across the broader ecosystem, along with building out the implementation catalog (Cabana, Pooltime, etc).

ADVOCACY - The advocacy layer goes beyond raw protocol adoption to grow the impact of PT's core values, and its audience is people who are focused on the protocol’s longterm utility. The activities of advocacy are values-aligned community growth, specification development and protocol improvement, and bug bounty and other security activities.

TRUST - The trust layer is about responsible stewardship of those things that can't be legally, safely, or productively moved to a fully distributed context*, and is focused on protecting the future of the protocol and its participants. The trust layer securely bridges the community and its critical real-world requirements like DNS ownership, communications routing, brand protection, and trust and safety orchestration.

Each of these layers have unique qualities and constraints, and likely benefit from different funding approaches and revenue generation expectations:

The ADOPTION layer is the "rational actor" layer, and should be more-or-less revenue-neutral with respect to the other layers. Syphoning value at this layer is a non-starter for permissionless protocols (someone can simply redeploy the contract and remove or redirect fees), and injecting value boils down to giving money away.

Related, adoption growth initiatives should be anchored in sustainable revenue models, so we aren't pursuing death-spiral economics where the faster we grow the more capital the community loses.

Front end tooling, for instance, costs money to build and deploy and secure and fix - and at least some of those OPEX costs scale with demand. Developers should be empowered and encouraged to pursue native revenue capture mechanisms to offset these costs.

Retroactive funding makes a lot of sense here too, as straightforward adoption KPIs can define clear net-value outcomes and even inspire healthy competition. Partner subsidies (like native chain token rewards) also fit here as potential win-win scenarios, though the challenge of converting to lasting value is an important consideration when dealing with farming dynamics.

What doesn't fit here is treasury or utility token spend that trades short-term usage boosts for long-term community resource losses or value dilution.

The ADVOCACY layer is the "value aligned" layer, and should be revenue generating, producing funds that subsidize the long-term viability of the protocol. Activities include subsidizing the trust layer, growing the number of advocates, and driving strategic improvements in both functionality and user experience.

While NFT mints, Mirror subs, swag sales, and lots of other tactical revenue-generating activities fall into this category, this should also include more strategic (scaling) revenue mechanisms like front-end fees, win-sharing or fund-supporting delegations, staking, community flashbots, community vaults, etc.

Finally, the TRUST layer is an essential safety backstop, a sustaining good for the protocol and community - and it consumes rather than generates revenue. It’s scope should always be as narrow as possible without compromising its function, and funding can come in one or more of the following ways:

• Passive recurring revenue: including from legacy treasury returns, protocol-owned liquidity, or other residual revenue streams

• Active user donations: whether direct, through optional fractional delegation or reward-share from supporting front-ends, or some other mechanism

• Advocacy activity passthrough: including fee sharing with other advocacy revenue mechanisms

Each layer can (in the spirit of decentralization) consist of one or more teams or DAOs or other types of organizations operating independently. At the TRUST layer, for instance, there can be more than one entity funded to support and protect critical brand resources and support trust and safety - but there can’t be no entity directly accountable for these functions if the protocol is to endure long-term while staying aligned to the PT core values.

Aligning revenue approaches to a clear intent at each layer should make it easier to enable autonomy & transparency while reducing confusion, risk, and missed opportunities.

FWIW, I would, right now, throw a switch to give a portion of any of my prizes to a team explicitly tasked to steward trust and safety, and I'd also throw the switch to support the developers who built the front-end I use. But I wouldn't so quickly throw a switch to add to a generic contributor fund, particularly if the intended spend process was opaque or undefined.

--

*Aside on the TRUST layer and decentralization: while blockchains replace one role of centralized authority with distributed consensus, most trust-dependent components remain in our daily interactions. We’re compelled to trust client implementations, API providers, the DNS system, CI pipelines, multisig holders, whitelist maintainers, wallet builders, OS vendors, community comms channels, and on and on. Recognizing where human trust remains in the service delivery chain is a vital part of understanding how our distributed systems actually work (and can fail). Communities that aspire to decentralization can best handle this with greater honesty about the components of their systems that invoke trust, and then strengthen those components with robust transparency and accountability mechanisms.