Architecture

There are seven core contracts and three surface contracts in the protocol.

• Core contracts are used to hold all the separate protocol components.

• Surface contracts bind together core contracts and handle finances. Anyone may create new surface contracts for usage on projects.

Core contracts

The first two fundamental agreements are self-explanatory. They hold the essential opinionated protocol components.

• SNOWTokenStore oversees the minting and destruction of tokens for all projects.

• SNOWFundingCycleStore maintains settings and scheduling for funding cycles. The data structure SNOWFundingCycle is used to represent funding cycles.

The next few are a little more general. They are not ecosystem-specific and are available for use by other protocols or future additions.

• SNOWProjects organizes and monitors the ownership of ERC-721 tokens representing projects.

This is used by the protocol to enforce the necessary access rights for multiple project-oriented transactions.

• SNOWSplitsStore holds information about the division of arbitrary distributions. The data is represented using the SNOWSplit data structure.

These are presently used by surface contracts to divide payment distributions and reserved token distributions.

• SNOWPrices maintains and normalizes currency-specific pricing feeds.

Using this, the protocol enables projects to account in any number of currencies, while managing all monies in AVAX or other assets independent of accounting denomination.

• SNOWOperatorStore contains operator permissions for each and every address. Addresses may authorize any other address to do particular indexed activities on their behalf, while restricting the rights to an arbitrary number of domain namespaces.

contracts authorization to perform administrative tasks on their behalf. This is beneficial for promoting a composable environment in which proxy contracts may execute operations on behalf of an address as a Lego brick.

• SNOWDirectory maintains a record of which terminal contracts each project is presently receiving payments via, as well as which controller contracts manage the tokens and funding cycles for each project.

Surface contracts

Currently, there are three surface contracts that govern how projects handle finances and outline how all core contracts should be used together. Anyone may create new surface contracts for usage on projects.

• SNOWController integrates financing cycles and project tokens, enabling limited control, accounting, and token administration.

• SNOWPayoutRedemptionPaymentTerminal controls all incoming and outgoing cash flows (pay, addToBalanceOf, distributePayoutsOf, useAllowanceOf, redeemTokensOf). This is an abstract implementation used by any number of payment terminals, including SNOWETHPaymentTerminal and SNOWERC20PaymentTerminal.

• SNOWSingleTokenPaymentTerminalStore manages accounting data on behalf of payment terminals that handle just one token type's balances.

The abstract SNOWPayoutRedemptionPaymentTerminal implements the ISNOWPaymentTerminal interface to offer outflow mechanisms. SNOWETHPaymentTerminal and SNOWERC20PaymentTerminal extend the SNOWPayoutRedemptionPaymentTerminal to provide token-specific inflow/outflow environments. It is permissible for projects to develop their own ISNOWPaymentTerminal implementations to take payments. This is important if you want to accept other tokens as payment, skip protocol costs, or experiment with a unique design. Using SNOWDirectory, a project may add or delete terminals from the basic SNOWDirectory contract. setTerminalsOf(...) is called if the current financing cycle configuration permits it.

A project may also bring its own contract to function as its controller. The only contract with direct access to a project's coins and financing cycles is its controller. Using SNOWDirectory, a project's controller may be configured from the core SNOWDirectory contract. setControllerOf(...) is called if the current financing cycle configuration permits it.

Utility contract Bonuses

• SNOWETHERC20ProjectPayer supplies utilities for the payment of a project. Contracts that seek to transfer cash to a treasury while defining the token recipient, message, and other contextual information may inherit this contract. Instances of this contract may also be deployed as standalone addresses that transmit incoming cash straight to the project's treasury.

• SNOWETHERC20ProjectPayerDeployer offers a method for deploying new SNOWETHERC20ProjectPayers that operate independently.

• SNOWETHERC20SplitsPayer offers utilities for the payment of a set of splits. This contract is helpful for contracts that desire to express contextual information with the routing of cash to a set of splits. Instances of this contract may also be deployed as standalone addresses that transmit received payments straight to a collection of splits.

• SNOWETHERC20SplitsPayerDeployer offers a function for deploying new SNOWETHERC20SplitsPayers that operate independently.

• SNOWProjectHandles enables project administrators to associate an ENS name with a project handle. Indexers may use events to make the Snowcone project directory searchable and filterable. Front ends can substitute a project's handle for its project ID.