# New PG docs

| old docs | top level page in new? | new docs |
| ---------------------- |:-------------------------- | ------------------------ |
| 0-homepage | ✅ | 2.0 homepage |
| 1-proposal-rationale | ➡️ rename to 2.6 | 2.1 Membership |
| 2-existing-mechanisms | ❌ | 2.2 Eligibility |
| 3-smart-contract | ✅ rename to 2.3 | 2.3 Onchain |
| 4-roles-expectations | ➡️ folded into 2.1 and 2.2 | 2.4 Donate |
| 5-initial-pilot | ➡️ folded into 2.8 | 2.5 design principles |
| 6-operating-guidelines | ➡️ folded into 2.1 and 2.2 | 2.6 the Ethereum commons |
| 7-anticipated-concerns | ❌ | 2.8 design rationale |
| 8-case-studies | ❌ | 2.9 resources |
| 9-membership | ✅ rename to 2.1 | |
| 10-donate | ❌ | |
| 11-resources | ✅ rename to 2.8 | |

# Homepage

Protocol Guild is a collective funding mechanism for Ethereum Layer 1 R&D. It has three components:

- an eligibility framework
- a member registry
- onchain contracts (vest and split)

The eligibility framework determines which projects' contributors should receive a share of the funding flow. This framework can then be used to maintain an active member registry. The registry addresses and weights are regularly published onchain to the split, where vested funding can be claimed.

Protocol Guild is only concerned with managing these components and soliciting funding to support the eligible work. The day-to-day stewardship discussions surrounding the Ethereum protocol continue to happen in existing non-PG venues (All Core Devs calls, ethresear.ch, Magician's forum) with the participation of a much broader set of contributors. Donations to fund PG have no bearing on stewardship decisions taking place in those existing venues.

This is a simple but powerful mechanism which allows Ethereum core protocol R&D to be funded in the same way it is produced: **a commons of peers and their collaborative effort over time.**

There are three main sections of the docs:

- [how Protocol Guild works](link) (members, eligibility, smart contracts) a handbook for operation
- [high level framing](link) (commons, design principles, rationale)
- [resources](link) (donate, Pilot retro, text + audio media)

Now - let's learn together! :shield: :chains:

> "And, Ebling, there's another, greater purpose. Hari Seldon founded two Foundations three centuries ago; one at each end of the Galaxy. You must find that Second Foundation." Foundation, Isaac Asimov

# Eligibility

Protocol Guild eligible projects **must**:

- be fully open source: both “source available” and free to fork, modify, redistribute
- have a regular presence in R&D or governance venues, such as
- specification repos (e.g. `consensus-specs`, `execution-specs`, `execution-apis`)
- research forums (e.g. ethresear.ch), feature prototyping (e.g. EIPs, devnets, etc.)
- regular protocol calls (e.g. AllCoreDevs, testing/interop calls, etc.)
- target at least one of the following projects/areas:

1. Ethereum core protocol maintenance and development

- Contributors to well-tested, technically-differentiated and production-ready Ethereum mainnet client implementations. Currently, this includes [Erigon](https://github.com/ledgerwatch/erigon), [EthereumJS](https://github.com/ethereumjs), [Geth](https://github.com/ethereum/go-ethereum), [Hyperledger Besu](https://github.com/hyperledger/besu), [Lighthouse](https://github.com/sigp/lighthouse), [Lodestar](https://github.com/ChainSafe/lodestar), [Nethermind](https://github.com/NethermindEth/nethermind), [Nimbus](https://github.com/status-im/nimbus-eth2), [Prysm](https://github.com/prysmaticlabs/prysm), [Teku](https://github.com/ConsenSys/teku), Reth
- Client testing/security/infra which supports these implementations: [ethereum/tests](https://github.com/ethereum/tests) [ethereum/execution-spec-tests](https://github.com/ethereum/execution-spec-tests)
- Coordination related to upgrades and maintenance: [ethereum/pm](https://github.com/ethereum/pm)

2. Research and implementation experiments related to potential protocol changes
- [Verkle tries](https://github.com/gballet/go-verkle) (Verge)
- [Portal Network](https://github.com/ethereum/portal-network-specs) (Purge)
- EVM improvements: [Ipsilon](https://github.com/ipsilon)
- Consensus work
- Cryptography
- Mechanism design
- Resource pricing

3. Spec work resulting from the above (should be implementation agnostic, unopinionated)
- [Execution specs (EELS)](https://github.com/ethereum/execution-specs)
- [Consensus specs](https://github.com/ethereum/consensus-specs)

4. Protocol Guild
- General comms
- Fundraising
- Research related to the evolution of the Guild itself
- Internal maintenance for the Guild membership

## Context

The eligibility framework is a "best effort representation" of Ethereum Layer 1 R&D. It tries to be sufficiently accomodating to what is the core protocol, but not any broader. This framework has been modified previously and will likely continue to be: more restrictive in some places and more permissive in others.

Contributing to the efforts referenced above does not guarantee Guild membership. While this list tries to be explicit by linking to example repos, there are some research areas which can't be linked to a single repo.

Formal organizational affiliations are not necessary for membership. It may be the case that some members of an organization will be eligible but others will not be.

Independent or unaffiliated contributors are considered by the same guidelines as any contributors "officially" part of teams/projects.

## How to Modify the Framework

Changing the eligibility framework can be made through a PR to the [documentation repo](https://github.com/protocolguild/documentation). This PR should add the project in the appropriate section, along with the following info:

- Name of project
- start date of the project
- Summary of why this project should be considered eligible/ineligible

# Membership

## Active Members

The membership is a set of people working within the eligible projects who have also opted into Protocol Guild. As of the last onchain update (May XX, 2024) Protocol Guild had 176 members who cumulatively contributed over 600 years of effort to protocol stewardship. See the latest membership numbers [here](link_to_dune).

- existing table

## Membership Requirements

All current members have been contributing:

1. to one or more of the list of [eligible projects](link_to_eligibility_framework).
2. continuously for **at least 6 months** ahead of inclusion. This work is expected to be ongoing (e.g. not a short-term or one-off project). To avoid removal from the current membership, any breaks in contribution must be shorter than 1 quarter (3 months). Beyond this length, the member should be moved to "Inactive" status until contribution resumes.
2. in a roughly full-time capacity. Anything less receives a [partial weighting](link_to_smart_contracts_weighting_section).

## Adding a Member

An existing member should make a PR at [this repo](https://github.com/protocolguild/documentation/tree/main) which proposes an addition to the member list above, along with the accompanying info:

- Name / Identifier
- Affiliated project they work on which is eligible
- Links to relevant eligible work, eg. GitHub, research
- 3-4 sentence summary of their contributions

See some examples here: [open]([link](https://github.com/protocolguild/documentation/pulls)) or [closed](https://github.com/protocolguild/documentation/pulls?q=is%3Apr+is%3Aclosed+label%3A%22add+member%22) PRs

Discussion should be open for at least one week to give members time to review and discuss.

Bias or conflicts of interest of the nominator should be disclosed, if they exist, e.g. where one is an advisor to the other’s side project. After one week of rough consensus, the PR should be merged or rejected.

## Removing a Member

### Self-removal, affiliation, weights

Removals from the active membership should come from the member themselves, i.e. self-removal. Where this isn't possible due to extenuating circumstances, the member should be notified or tagged on the PR so they are aware of the changes.

Affiliation and weight changes should include some rationale for the change, ideally from the member themselves and seconding by a colleague.

### Forced-removal

This situation occurs when another member proposes the removal of an existing member - even if they are continuing with eligible work. This should only happen in special circumstances where the cost of contention is higher than the loss of institutional legitimacy which their continued membership would produce.

The PR should include ample references to the alleged misconduct and justification for the removal. To date, this method has never been used.

## Time-weight formula

The mechanism uses a formula with member-specific inputs to produce a time-weight:

`time_weight` = `SQRT`((`start_date` - `months_inactive`) * `full_or_part_time`)

Each member's time-weight is updated onchain every quarter along with an Ethereum address they control to allocate the funding flowing through the mechanism. Let's explore each of the formula components below.

1.`time_weight`

Our formulation recognizes the local knowledge contributors gain over time, and uses that as a proxy for "value to the commons" and to allocate funding to members. Existing contributor weights get "diluted" as newcomers show up. Continuing contributors get additional weight per month they are active.

2.`start_date`

The mechanism is retroactive: the earlier a contributor shows up, the higher their weight allocation for funding.

3.`months_inactive`

Members can take up to 3 months break without triggering a membership change. Beyond that, the mechanism tracks breaks to ensure weights are a fair representation of contributions.

4.`full_or_part_time`

- full-weight: 1.0x
- partial-weight: 0.5x

These multipliers roughly track the effort per week given by contributors. Full-weight is considered full-time, at least 40 hr/wk. Partial-weight is anything between 20 - 40 hr/wk.

5.`SQRT`

The final step of the formula uses a Square Root to compress the weight range. This is done to not overly privilege long-term members over newer contributors.

### Time-weight example

The table and graphs below illustrate how the 5 year weight change of a hypothetical three member Guild. The effect of the square root can be seen in how the difference between older and newer contributors gets smaller over time.

| | 0 | 12 | 24 | 36 | 48 | 60 |
| ---------------------------------------- | ---- | ---- | ---- | ---- | ---- | ---- |
| **Peer 1** (starting weight 6mo) | 4.24 | 5.48 | 6.48 | 7.35 | 8.12 | 8.12 |
| **Peer 2** (starting weight 24mo) | 6.00 | 6.93 | 7.75 | 8.49 | 9.17 | 9.17 |
| **Peer 3** (starting weight 12mo, part to full-weight at 18 months) | 3.46 | 6.00 | 6.93 | 7.75 | 8.49 | 8.49 |


## Quotes

- existing content