Fraction Protocol Architecture

From the user's perspective, the Fraction Protocol consists of two integral components:

1. Fraction Platform: A collection of smart contracts that enable the fractionalization of valuable assets, allowing owners to sell these fractions to buyers.
2. Sale: A set of rules that define how an asset is fractionalized, the criteria for participation, and the benefits participants receive from acquiring fractions.

The Fraction Platform is based on the Multi-Facet Proxy (Diamond) Standard EIP-2535 standard, meaning that there are two types of the smart contracts that dictate how the Fraction Platform is managed after deployment and what functionality it will have:

1. Facets - represent the predeployed smart contracts, each of them containing the necessary functionality to assemble the Fraction Platform. Each facet contains a specific functionality that must be customly selected by the future administrator of the platform instance.
2. Diamond proxy - defines a smart contract that serves as the entry point for interaction with the Fraction Platform. This contract serves as a proxy between users and the selected facets (smart contracts) that execute the business logic for fractionalizing assets and running sales.

The only component deployed by an administrator is the diamond smart contract, which serves as a proxy between users and the chosen facets. This diamond proxy contract holds storage layouts and a list of functions that can be executed on the facets through delegate function calls. When a user interacts with the platform, they call a function on the diamond smart contract, which subsequently makes a delegate call to the relevant facet.

When the delegate call is succesfully invoked, the result of that operation changes the state of the diamond proxy smart contract and the storage gets updated. Therefore, facets only provide functions and the storage layouts, but the diamond proxy stores the state associated with sales and also a list of target functions.

A list of target functions in the diamond proxy contract represents a mapping of facet addresses to the functions that must be called by a user to interact with the platform. The diamond proxy contract heavily relies on the fallback function, which acts in the following manner:

1. When a user calls a facet function that the diamond proxy in fact doesn't have, an error occurs, and the fallback function is triggered.
2. The fallback function is written in a way that allows it to read the signature of the facet function that was called.
3. The program searches for the signature in the mapping of function selectors to facet addresses.
4. If it finds the signature name in the list, it makes a delegate call, the facet function is executed, and the state of the diamond proxy gets updated.