2. Smart Contract Architecture

This section describes Protocol Guild’s current smart contract architecture. You can learn more about the pilot’s architecture here.

Protocol Guild uses smart contracts created by Splits to trustlessly manage the vesting and distribution of donated funds. All donations are deposited into immutable vesting contracts, which vest funds into pass-through wallets, before being transferred to split contracts for distribution to the membership.

The mainnet split contract also serves as Protocol Guild’s membership registry of Ethereum’s active core protocol contributors. A DAO is used to ratify changes to the membership onchain every quarter.

2.1 Modules

The Guild’s smart contract architecture is modularized as follows:

OnchainArchitecture

Vesting Contract

The Guild’s donation addresses on Ethereum mainnet, Arbitrum, Base and Optimism are immutable vesting contract, built by the Splits team, which irrevocably vests donated funds on a linear (block-by-block), basis. Here, “irrevocably” means donations cannot be stopped or otherwise redirected during the vest by anyone, be it the donor or Protocol Guild membership. Anyone can donate ETH and ERC-20 tokens to these vesting contracts.

NFT donations are not supported - standard NFT transfers (safeTransfer) will be rejected by the contract (i.e. meaning the transaction will fail), while non-safeTransfer NFT donations will be lost.

How it works:

  • Donated tokens will accrue in a per-asset queue until a vesting stream is started for that batch of tokens, by triggering the startStream function (permissionless, as in any actor can trigger this function, regardless of whether they are a Guild member)

  • Once the vesting stream is started, the tokens will vest linearly, and anyone can permissionlessly trigger releaseStream to push any vested tokens into a pass-through wallet (this must be done per vesting stream)

  • Official documentation: https://docs.splits.org/core/vesting

All donated tokens are thus forced to vest - there is no way to do anything with them until they are vested into the pass-through wallet.

Deployed Vesting Contracts:

Pass-Through Wallet

All funds from vesting contracts go into a pass-through wallet (PTW), built by the Splits team, which pools vested tokens to be pushed to split contracts.

The PTW allows the Guild’s membership to make arbitrary calls with vested tokens if needed, since the current split contract does not have such functionality. For the avoidance of doubt: the PTW can only be used to interact with tokens which have already finished vesting. Tokens still vesting in vesting contracts cannot be prematurely interacted with.

How it works:

  • The PTW has a permissionless passThrough function, which allows anyone to push vested funds accumulated in the PTW to the contract’s passThrough, which is set to the Guild’s split contract.

  • The PTWs owner (the Guild’s DAO), can pause / unpause the contract by changing the paused value, allowing the owner to move specific tokens using arbitrary calls instead.

  • The PTW owner can also update the passThrough recipient if needed e.g. if the Guild migrates to a different split contract in the future

  • Official documentation: https://docs.splits.org/core/pass-through

Deployed PTWs:

Split Contract

Split contracts, built by the Splits team, contain all Guild members’ addresses and their respective share of vested funds (based on the time-weight formula). Unlike the vesting contract, the split contract is mutable, as it needs to be updated quarterly to reflect changes to the membership (i.e. members being added or removed), as well as to update member weights over time.

How it works:

  • Distributions:

    • The distribute function allocates tokens in the split contract to Guild members according to their weights (it does not move the funds into the member wallets)

    • Once distribute has been triggered, members can trigger the withdrawForMyself function to deposit tokens into their wallets

    • Distributions are permissioned to the Guild’s DAO on mainnet, and multisigs on L2s

      • On mainnet, split distributions are triggered once a week via so-called “scoped proposals”, which require a simple majority but no quorum, while maintaining the 7-day voting period + 2 day grace period

      • On L2s, split distributions are triggered by multisigs on a monthly basis or when enough funds have accumulated for distribution

  • Updates:

    • Split updates - member additions, removals and weight changes - are permissioned to the Guild’s DAO on mainnet, and multisigs on L2s

      • On mainnet, split updates are triggered once a quarter via a DAO proposal which requires a simple majority plus 33% quorum, with a 7-day voting period + 2 day grace period

      • On L2s, split updates are triggered via multisigs once the mainnet DAO vote is complete

  • Official documentation:

Deployed Splits Contracts:

DAO

The Guild currently uses an Agora DAO for onchain governance. The DAO includes all Guild members, with one person one vote, including vote delegation.

The DAO controls the Guild’s PTW and split contracts on mainnet, but does otherwise not keep track of member weights, nor does it hold any funds.

How it works:

  • The DAO is generally used for two purposes; (1) update the mainnet split and (2) trigger split distributions

    • Split updates are triggered once a quarter via a DAO proposal which requires a simple majority plus 33% quorum, with a 7-day voting period + 2 day grace period

    • Split distributions are triggered once a week via so-called “scoped proposals”, which require a simple majority but no quorum, while maintaining the 7-day voting period + 2 day grace period

  • All proposals need to be sponsored by an existing DAO member before the voting period starts

  • “Signal proposals” may be used for membership-wide voting on important Guild matters

Deployed DAOs:

Multisigs

The Guild has deployed 6/10 Safe multisig contracts to control the PTW and split contract, and to claim funds on mainnet and optimism (when donations cannot be sent to the vesting contact directly). Multisigs are also used to receive donations on most L2s, and then bridge those funds to mainnet.

The multisigs’ signers are not disclosed publicly, and are rotated regularly.

The aim is to reduce reliance on multisigs over time, to replace them with the DAO or other more trustless alternatives as the become available.

Safe official documentation: https://docs.safe.global/

Deployed Multisigs: