Overview

Architecture

The basic architecture of PartyFinance protcol uses Nick Mudge's EIP-2535 Diamond Standard (opens in a new tab) as a code implementation and organization strategy. Each Party consists in a diamond implementation that uses a fallback function to delegate function calls to to multiple other contracts called facets. The diamond pattern makes it possible to implement a lot of contract functionality that is compartmented into separate areas of functionality, but still using the same Ethereum address.

The code is further simplified and saves gas because state variables are shared between facets. This is helpful because Diamonds are not limited by the 24KB maximum contract size. Facets can be deployed once and reused by any number of diamonds.

Party Diamond

The PartyFactory is in charge of deploying Parties as a Diamond Standard. When deployed, the Factory adds all the functions from all the facets to the Party.

Upgrades synchronization

Since the deployed Diamonds are Upgradeable Diamonds, in the way that they can be upgraded by the Factory, whenever the protocol needs an upgrade it must make sure that all Parties will have the same functions. The role of the VersionFacet is to handle the upgradeability of already deployed Parties without the need of passing a FacetCut[] for each single party. It automatically checks the required functions from the PartyFactory and makes the needed upgrade.