Skip to content

Add funder recognition multiplier to time weight - #585

Open
tvanepps wants to merge 1 commit into
mainfrom
funder-recognition-multiplier
Open

tvanepps wants to merge 1 commit into
mainfrom
funder-recognition-multiplier

Conversation

@tvanepps

@tvanepps tvanepps commented Oct 15, 2026 •

Copy link
Copy Markdown
Member

Proposes an opt-in 2x funder_recognition multiplier on time_weight for members who add the Protocol Guild funder recognition to their GitHub profile README, in a similar spirit to "Github Sponsors".

Why: While the leaderboards on our website, Dune dashboard, and tweets are a good start for donor recognition, we should try to increase the visibility footprint. This will help to maintain momentum on the funding flywheel. Member profile READMEs are visible wherever members commit, review, and open PRs across Ethereum's repos.

In a world where agents trawl the web and ingest markdown, this mode makes sense to provide more surface area to broaden the awareness of PG and its funders.

Changes to docs/01-membership.md:

  • time_weight = SQRT((start_date - months_inactive) * full_or_part_time) * funder_recognition
  • new component 5. funder_recognition: 2.0x with the table, 1.0x without
  • PG Ops maintains the table and sends quarterly PRs to each member that opts in; the table is checked at each quarterly membership update, and the multiplier drops off the following quarter if it is removed

Examples: github.com/protocolguild (org profile) and tvanepps LukaszRozmej (member profiles).

Also open to something visually smaller in the readme, eg. a bulleted list:

  • Funding Distributed: ⭐ EigenLayer, ⭐ Ether.fi, ⭐ Taiko Labs, Arbitrum DAO, LayerZero, Lido DAO, Uniswap DAO, ENS DAO, Moloch DAO, Nouns DAO
  • Funding Remaining: ⭐ Ether.fi, LayerZero, ⭐ EigenLayer, ⭐ Aztec, ⭐ Aligned Layer, Starknet, ⭐ Taiko Labs, Octant, Delivery at Dawn, ⭐ Puffer
  • Recent Donations: wagumi.eth, ⭐ Aligned Layer, Cosmic Signature, 0x969e...f4f4, 0x67ee...fde1, Octant, 0x512a...3d66, TheDAO, 0xc647...83ba, 0x799d...ae39

Since the pool is fixed, the effect depends on how much total weight opts in: at 10% opt-in, participating members get 1.82x their plain time-weight share and others 0.91x; at 100% opt-in, shares return to plain time-weighting. Future iterations of this policy can consider higher multipliers for team repos, given they are higher visibility.

As previously discussed, this also has the benefit of injecting some need-weighting into the allocation. Reason being, the people that attend to this and elect to participate are likely those which are in greater need of funding. It is good to have more expressivity in the mechanism on this axes.

Proposed to go live now and affect weights in the upcoming Q4 November update.

please direct discussion here: https://discord.com/channels/795514951376568391/1557039474943332362

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@tvanepps
tvanepps marked this pull request as ready for review October 16, 2026 21:04
@AnkushinDaniil

Copy link
Copy Markdown

Would it make sense to run this as a trial for 1-2 quarters first? It might be hard to tell later if the README block brought new pledges, so maybe track something simple, like new funders who mention they saw it.

@mkalinin

Copy link
Copy Markdown
Collaborator

I have a limited understanding of whether this will aid fundraising or not, and I personally trust PG Ops on that matter.

This will help to maintain momentum on the funding flywheel.

Assuming this is true, I don't see a problem in adding such a table to my GH profile. But if the majority does that, the penalties for those who did not might be too high.

It would be useful to see how the share multipliers would look like with different level of adoption.

@poojaranjan

Copy link
Copy Markdown
Contributor

I trust PG Ops on fundraising. However, I’m reluctant to use my personal GitHub profile for donor promotion, as I believe recognition on the PG website is more appropriate.

IMO, PG distributions should reflect contributions, not willingness to promote sponsors. I share the concern about penalties for those who opt out.

I wonder if we could put this to a vote before merging, allowing enough time for feedback given Devcon travel.

@MariusVanDerWijden

Copy link
Copy Markdown
Collaborator

I thought the whole point was not to whore us out to donors. I think 2x is unjustified. Encouraging everyone to do it is okay, maybe even giving a .25% bonus but a 2x??? Thats basically a "either you do it or you're out".

@tvanepps

tvanepps commented Oct 27, 2026 •

Copy link
Copy Markdown
Member Author

please direct discussion here to have it all in one place: https://discord.com/channels/795514951376568391/1557039474943332362

@nazarhussain

Copy link
Copy Markdown

@tvanepps I suggest to have a poll on our discord for that proposal before bringing that discussion here on the Github.

@jflo jflo left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm for it, the cost is negligible and this would be easy to both automate and audit.

@hangleang

Copy link
Copy Markdown

+1 for more donor visibility, but 2x is too much for those who don't opt in. should we make it smaller, like 1.25x?

I'd prefer team-repo recognition instead, since it's more visible and easier to keep track of.

@raxhvl

raxhvl commented Oct 28, 2026

Copy link
Copy Markdown

Fundraising matters, and if a banner helps, I’ll happily put one up.

I also agree that the 2x multiplier is unfair - no member should be significanlty worse off because they do their work
but skip a banner.

We can either

  • start off small
  • Or run a volunteer trial for one or two quarters, where members put a banner without a reward. if we have enough volunteers to move the needle.

If this works, can we fund a "bonus" for members who display the banner from the donations it brings in, in exchange for the spot, instead of carving it out of the main pool?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants