Welcome to the "Learn" section of Snowcone DAO. This is your one-stop resource for understanding the ins and outs of our organization. From our overall structure to the specifics of our tokenomics, you'll find comprehensive information here.

Overview

Get a high-level understanding of Snowcone DAO, our mission, vision, and the core principles that guide our operations. This section provides a broad perspective on who we are and what we aim to achieve.

Architecture

Dive into the technical structure of Snowcone DAO. This section covers our system architecture, including the design, components, and the interrelationships between them. It's a must-read for anyone interested in the technical aspects of our DAO.

Administration

Learn about the administrative structure of Snowcone DAO. This section provides insights into our governance model, decision-making processes, and the roles and responsibilities within our organization.

Risk

Understanding risk is crucial for any DAO member. This section outlines the potential risks associated with participating in a DAO and the measures we've put in place to mitigate them.

Glossary

New to DAOs or blockchain technology? Our glossary provides definitions for common terms and jargon you'll encounter when interacting with Snowcone DAO and other blockchain-based platforms.

Tokenomics

Understand the economics of our native token. This section provides a detailed breakdown of our token distribution, use cases, and the incentives for various stakeholders in our ecosystem.

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.

Snowcone is a protocol for financing and running projects publicly on Avalanche. It allows you:

Deploy an NFT that reflects project ownership.

This NFT's owner has administrative permissions to configure treasury settings inside the Snowcone ecosystem.

Gain insight into projects

Configure project financing cycles.

Cycles of funding establish the contractual limits within which the project will function.

Educate yourself about financing cycles

These characteristics may be specified for a financing cycle:

Mint tokens

A project begins with zero tokens by default and mints them when its treasury receives donations.

If its current financing cycle configuration allows minting, a project may mint and distribute tokens on demand.

By default, project tokens are not ERC-20 tokens, and are thus incompatible with typical market protocols like as Uniswap. You can issue ERC-20s that token holders may claim at any moment. This is optional.

Burn tokens

If the current fundraising cycle is not set to suspend token burning, anybody may burn a project's tokens.

Bring one's own token.

A project may provide its own token so long as it complies to ISNOWToken and employs 18-decimal fixed-point accounting.

This enables a project to use ERC-721, ERC-1155, or any other bespoke contract that will be invoked when the protocol requests to mint or burn tokens.

During any of its financing cycles that are specifically structured to enable token changes, a project may alter its token.

The protocol includes by default a transaction for deploying SNOWToken ERC-20 tokens.

Splits

A project may design token distributions to splits in advance. The destination of a split can be an Avalanche address, the project ID of another project's Snowcone treasury (the split allows you to configure the recipient of that project's tokens that are minted in response to the contribution), the allocate(...) function of any contract that adheres to ISNOWSplitAllocator, or the address that initiated the transaction that distributes tokens to the splits.

Find out more about splits

Explore the topic of allocators

Membership price for SNOW

All monies distributed by projects from their treasuries to destinations outside the Snowcone ecosystem will suffer a protocol cost. This fee is sent to the SnowconeDAO treasury, which runs on the Snowcone protocol itself (project ID of 1), triggering the same functionality as a payment directly to SnowconeDAO from an external source (by default, minting SNOW for the fee payer based on SnowconeDAO's current funding cycle configuration).

This cost is modifiable up to a maximum of 5% by SnowconeDAO.

The transfer of money between Snowcone treasuries through splits is free of charge.

Personalized treasury strategies

Using an ISNOWFundingCycleDataSource, ISNOWPayDelegate, and ISNOWRedemptionDelegate, funding cycles can be configured to extend or override the default protocol's behavior that defines what happens when an address attempts to make a payment to the project's treasury and what happens when someone attempts to redeem the project tokens during a specific funding cycle.

Learn more about data sources

Explore the subject of delegates

Accept multiple tokens

A project may define an arbitrary number of payment terminal contracts via which it may receive cash denominated in different tokens. This enables projects to establish separate rules for accepting AVAX, any ERC-20 token, or any asset.

Anyone may create a contract that conforms to ISNOWPaymentTerminal for usage by projects, and a project can move money across terminals that utilize the same token.

Transferability and portability

A project's treasury controller may be migrated to any other contract that complies to ISNOWController. This enables a project to adopt updated or customized treasury dynamics over time.

Operators

Addresses may designate other addresses that are authorized to conduct some administrative treasury activities on their behalf.

Explore the subject of operators

What everyone should know

• A delegate contract is a mechanism for extending the default SNOWPayoutRedemptionPaymentTerminal functionality for a treasury.

• Pay delegates contain a custom didPay(...) hook that executes after all of the default protocol pay logic in the terminal contract has been properly performed. A variety of contextual information is supplied to the hook through the SNOWDidPayData data structure.

• Redemption delegates provide a custom didRedeem(...) hook that executes after the default protocol redeem logic in the terminal contract has been successfully completed. A variety of contextual information is supplied to the hook through the SNOWDidRedeemData data structure. Redemption delegates provide a custom didRedeem(...) hook that executes after the default protocol redeem logic in the terminal contract has been successfully completed. A variety of contextual information is supplied to the hook through the SNOWDidRedeemData data structure.

• Each ISNOWPaymentTerminal branch might use delegates in a unique manner.

What you should know if you're constructing

• ISNOWPayDelegates and ISNOWRedemptionDelegates are both sorts of delegates. Any contract adhering to these interfaces may be used as a delegate in the financing cycles of a project.

• The dataSource of the financing cycle should specify which delegated contracts to utilize.

• didPay(...) is invoked in SNOWPayoutRedemptionPaymentTerminal. pay(...), and didRedeem(...) is invoked in SNOWPayoutRedemptionPaymentTerminal.redeemTokensOf(..). (...).

• The redemption delegate hook is called prior to the distribution of monies.

What everyone should know

The reconfigurations of a project's financing cycle might vary substantially. Custom ballots may be beneficial for controlling changes. A ballot contract must implement a function that indicates whether the status of a proposed reconfiguration is active, authorized, or unsuccessful, as specified by SNOWBallotState. If a reconfiguration is not authorized by a vote, it will not be implemented. Instead, the present financing cycle will be replicated.

What you should know if you're constructing ​

• A ballot is a custom contract that conforms to the ISNOWFundingCycleBallot interface that may be connected to a project's funding cycles to impose constraints that proposed funding cycle reconfigurations must comply to in order to take effect.

• Through the SNOWController.launchProjectFor(...) or SNOWController.reconfigureFundingCyclesOf(...) transactions, a ballot may be provided in a funding cycle.

• If a ballot is active, the funding cycle's ballot redemption rate will be applied rather than its normal redemption rate.

COMING SOON

What everyone needs to know​

• A discount rate is a percentage configured on each funding cycle that determines by how much the subsequent cycle's weight (i.e. exchange rate) should decrease compared to the funding cycle for which the discount rate is set.

• A discount rate is only applied if a new weight isn't explicitly set in an upcoming funding cycle reconfiguration.

• A discount rate can be used to automatically decrease token issuance over time. Funding cycles with higher discountRates and/or shorter durations will have token issuance decrease faster than those with smaller discountRates and/or longer durations.

What you'll want to know if you're building​

• A discount rate can be specified in a funding cycle through the SNOWCntroller.launchProjectFor(...) or SNOWController.reconfigureFundingCyclesOf(...) transactions.

What everyone needs to know​

• A project can set distribution limits from its treasury on a per funding cycle basis using SnowController.launchProjectFor(...) and SNOWController.reconfigureFundingCyclesOf(...). These limits are stored inSNOWController.distributionLimitOf(...). Any funds that are in the project's Snowcone treasury that it hasn't specified as distributable are considered overflow.

• Overflow serves as a project's runway since future funding cycles can tap into it within the bounds of the preconfigured distribution limits. Overflow can also serve as a refund or rebate mechanism, where everyone's net contribution price is pushed towards zero as volume outpaces what the project needs.

• By default, overflow also serves a means for allowing community members to exit with a portion of the treasury's funds in hand. Any funds in overflow are reclaimable by the project's community by redeeming community tokens along a bonding curve defined by the project's current redemption rate. Projects can override or extend this functionality using a custom data source.

• Projects can manage how much money is in overflow (and therefore how much each member can exit with) either by adjusting its distribution limits or by using a custom redemption extension.

• A project can set overflow allowances from its treasury on a per-funding-cycle-configuration basis within theSNOWController.launchProjectFor(...) and SNOWController.reconfigureFundingCyclesOf(...) transactions. These allowances are stored inSNOWController.overflowAllowancesOf(...). A project's owner can distribute the project's funds from its overflow on-demand up until the preconfigured allowance. Overflow allowances do not reset each funding cycle, they last until a new funding cycle reconfiguration takes effect.

What everyone needs to know​

• The redemption rate determines what proportion of treasury assets can be reclaimed by a token holder by redeeming their tokens.

• By default, all treasury assets that are considered overflow can be reclaimed by token holders. This can be modified using data source extensions.

• A project's redemption rate and extensions can be reconfigured each funding cycle.

• A redemption rate of 100% is linear, meaning a holder with 1% of the token supply can redeem all of their tokens for 1% of available treasury assets.

• A redemption rate of x% where x < 100% will leave some assets in the treasury to share between those who wait longer to redeem. The smaller the x, the fewer assets can be reclaimed.

• A project can set a different redemption rate that takes effect only when the project's current funding cycle has an active ballot.

What you'll want to know if you're building​

• A redemption rate can be specified in a funding cycle through the SNOWController.launchProjectFor(...) or SNOWController.reconfigureFundingCyclesOf(...) transactions.

• A ballot redemption rate can be specified in a funding cycle through the CSNOWController.launchProjectFor(...) or CSNOWController.reconfigureFundingCyclesOf(...) transactions, which will override the standard redemption rate if there is currently a reconfiguration ballot active.

What everyone needs to know​

• A project can be configured to use any contract that adheres to ISNOWPaymentTerminal to manage its inflows and outflows of token funds.

• Each payment terminal can have a unique distribution limit and overflow allowance.

• Each payment terminal can behave differently when it receives payments.

What you'll want to know if you're building​

• A project can set its terminals usingSNOWDirectory.setTerminalsOf(...).

• If a project uses multiple terminals to manage funds for the same token, it can set the primary one (where other Web3 contracts should send funds to) using SNOWDirectory.setPrimaryTerminalOf(...).

• To pay a project with a certain token, get its prefered payment terminal using SNOWDirectory.primaryTerminalOf(...). If no terminal is returned, the project is not currently accepting the specified token.

What everyone needs to know​

• Each project within the Snowcone protocol is represented as an ERC-721 NFT.

• Whoever is the owner of a project's NFT has access to admin functionality for that project within the protocol, which ultimately gives it control over the project's funds.

What you'll want to know if you're building​

• Projects can be created either within the context of Snowcone with a call to SNOWController.launchProjectFor(...) which also configures its funding cycle properties and sets it up to receive payments, or by itself with a call to SNOWProjects.createFor(...). The launchProjectFor(...) transaction calls createFor(...) as part of its routine.

• A project can accomodate arbitrary metadata for any number of domains that can be updated by the project owner at any time using the SNOWProject.setMetadataOf(...)transaction. This can be used by clients to store a reference to metadata stored on IPFS (or anywhere else). The protocol does not define standards for this metadata. A project's current metadata for any particular domain can be found by reading from SNOWProject.metadataContentOf(...).

• Look through theSNOWProjects contract for a complete list of relevant read functions, write functions, and emitted events.

The protocol's global governance is modest. The only global functions that may be accessible via a privileged administrative address, originally the SnowconeDAO multisig, a 9 of 14 multisig elected by SNOW members, are as follows:

• SNOWProjects.setTokenUriResolver(...) enables the SNOWProjects contract owner to provide and modify the ISNOWTokenUriResolver used to resolve metadata for project NFTs in its tokenURI(...) method.

• SNOWPrices.addFeedFor(...) enables the owner of the SNOWPrices contract to add additional price feeds for currency conversions. A price feed cannot be withdrawn once installed.

• SNOWDirectory.setIsAllowedToSetFirstController(...) enables the SNOWDirectory contract owner to add/remove addresses that may set a project's first controller on their behalf.

• SNOWETHPaymentTerminal.setFee(...) enables the owner of the SNOWETHPaymentTerminal (or any other terminal inheriting from SNOWPayoutRedemptionPayTerminal) to modify the protocol charge imposed when projects release treasury cash outside of the protocol ecosystem. Maximum cost is 5%. The

• SNOWETHPaymentTerminal.setFeeGauge(...) method enables the owner of the SNOWETHPaymentTerminal (or any other terminal deriving from SNOWPayoutRedemptionPayTerminal) to modify the fee gauge used to deliver per-project fee savings.

• SNOWETHPaymentTerminal.setFeelessAddress(...) Permits the owner of the SNOWETHPaymentTerminal (or any other terminal inheriting from SNOWPayoutRedemptionPayTerminal) to add/remove any other address used by other projects to/from a list of addresses to which distributed funds can be sent without incurring protocol fees, and from which funds can be added back to the project's balance without refunding held fees.

Each contract is administered individually, and the existing owner may transfer ownership to a new party.

Please note that "locked" tokens are held by the DAO and require community approval for unlocking. This ensures that any decision to unlock these tokens is made collectively, aligning with our commitment to decentralized governance and community involvement.

Seed

• Percentage: 8%

• Amount: 160 million tokens

• Vesting: 13 at TGE quarterly over 3 years

We have closed our seed round of funding at a valuation of $4.6 million. This funding will be used to accelerate our growth and development, and to bring our product to market. The tokens allocated in this phase will be vested quarterly over 3 years to ensure long-term commitment.

Public/Community

• Percentage: 2%

• Amount: 40 million tokens

• Vesting: Token Generation Event (TGE)

We value our community and public supporters. These tokens are distributed during our Token Generation Event.

Team/Advisors

• Percentage: 16% for team, 2% for advisors

• Amount: 360 million tokens

• Vesting: 6-month cliff, then quarterly over 4 years

Our team and advisors are essential to our success. To ensure their commitment, tokens will be vested over a 4-year period, starting after a 6-month cliff.

Bug Bounties

• Percentage: 12%

• Amount: 240 million tokens

• Vesting: Locked

We prioritize the security of our platform. These tokens are reserved for rewarding those who help us identify and fix potential vulnerabilities.

Staking/Ecosystem/Boost

• Percentage: 35%

• Amount: 700 million tokens

• Vesting: Locked

These tokens are allocated for staking rewards, ecosystem development, and boosting rewards for staked votes. They play a crucial role in incentivizing participation and fostering growth within our community.

Please note that these "locked" tokens are held by the DAO and require community approval for unlocking. This ensures that any decision to unlock these tokens is made collectively, aligning with our commitment to decentralized governance and community involvement.

Liquidity

• Percentage: 5%

• Amount: 100 million tokens

• Vesting: Locked

These tokens are locked to provide liquidity in the market, ensuring smooth transactions for our users.

Grants

• Percentage: 8%

• Amount: 160 million tokens

• Vesting: Locked

We believe in supporting innovative ideas and projects in our ecosystem. These tokens are reserved for grants.

Reserve

• Percentage: 12%

• Amount: 240 million tokens

• Vesting: Locked

These tokens are kept in reserve to ensure the long-term sustainability and growth of our project.

What everyone should know

• A data source contract is a means of supplying a treasury with extensions that either supersede or expand the capabilities of the default SNOWPayoutRedemptionPaymentTerminal.

• You may utilize a data source contract to give custom data to the SNOWPayoutRedemptionPaymentTerminal.pay(...) and/or SNOWPayoutRedemptionPaymentTerminal.redeemTokensOf(...) transactions.

• A data source receives contextual information from the transactions, from which it may extract bespoke data for the protocol to utilize to influence later pay and redeem transaction behaviors. Pay transaction context is supplied to the data source in the form of SNOWPayParamsData, while redeem transaction context is passed to the data source in the form of SNOWRedeemParamsData.

• Data sources may revert on user-defined conditions, allowing for the creation of a gated treasury, maximum token supply, minimum contribution amount, etc.

• A data source is responsible for defining any delegate hooks that should be executed after the main functionality of a pay(...) or redeemTokensOf(...) transaction has been properly executed.

• Each ISNOWPaymentTerminal variant may use data sources in a unique manner.

What you should know if you're constructing ​

• The ISNOWFundingCycleDataSource interface must be adhered to by a data source.

• A funding cycle may include a data source contract together with flags indicating whether the funding cycle should useDataSourceForPay or useDataSourceForRedeem. These are specified in either SNOWController.launchProjectFor(...) or SNOWController.reconfigureFundingCyclesOf (...).

• In SNOWSingleTokenPaymentTerminalStore.recordPaymentFrom(...) and SNOWSingleTokenPaymentTerminalStore.recordRedemptionFor(...), a financing cycle's data source is accessed (...).

• A data source grants implicit authorization to SNOWController.mintTokensFor(...) on behalf of a project.

• If no data source is given in a funding cycle, or if no flags are expressly set, default protocol data will be utilized.

Before engaging with the protocol, everyone should be informed of the following hazards. The architecture of the protocol exposes these vulnerabilities as a result of its standard operating procedures.

See also Security and Audits.

Smart contract dangers

The protocol relies only on publicly available smart contracts, which are described in full throughout these papers. All repercussions of dealing with networks using the protocol are the responsibility of the entities who sign each transaction. The protocol conforms to the standards stated in these documents if and only if the code is appropriately designed and deployed, which is a shared responsibility and is not guaranteed. There is a substantial possibility that this is not true. You must do your own research.

Project owner risk

On the Snowcone protocol, each project is owned by the address holding a SNOWProjects NFT with a unique token ID, which also acts as the project's ID. The address that has this token has the ability to alter a project's financing cycles, allowing it to manage the project's finances both maliciously and constructively.

• The following settings may be adjusted every financing cycle by the project owner:

Limiting distribution and dividing payouts

With no distribution limit, all treasury monies are common property. Token holders may redeem their tokens at any moment to regain their portion of the treasury, according to the redemption bonding curve rate of the current financing cycle.

A distribution limit greater than zero distributes a part of the treasury to payout splits.

A project owner may also adjust the split allocations that are constrained by the funding cycle's distribution limit at any time, unless the split was expressly frozen until a defined date after its creation.

This may be used constructively to withdraw assets to a community safe, disburse monies to donors, route funds to other projects running treasuries on the protocol, and more.

This may be used maliciously to transfer the whole treasury to an arbitrary wallet.

Establishing an overflow reserve

With a 0% overflow allowance, the project owner is unable to access any treasury money belonging to the community that exceed the distribution limit. The only method for monies to leave the Treasury is via redemption of tokens.

A non-zero overflow allowance provides the project owner with on-demand access to a part of the community's money for distribution to arbitrary addresses.

Allowing token production

While token minting is prohibited, new project tokens may only be minted and given if the project receives more cash into its treasury. Tokens will be issued in line with the values of the current financing cycle.

If token minting is permitted, the project owner may mint and distribute an arbitrary number of tokens, reducing the redemption value of all existing tokens.

Setting the weight of the financing cycle

The weight of a funding cycle defines the number of tokens that will be produced and distributed when a treasury receives cash. By default, a financing cycle has the same weight as the cycle that before it after applying the discount rate of the cycle that preceded it.

Permitting the exchange of project tokens

While changing tokens is not permitted, the existing project token will be utilized for the remainder of the fundraising cycle to meet redemptions and new issuance.

If token replacement is permitted, a new token may replace a prior token for new issuances and redemptions.

Halt payments, pause distributions, pause redemptions, pause burn

While not all functionality is suspended, basic functionality will be available.

If a project's payments are suspended, the protocol will refuse any incoming payments. If disbursements are suspended for a certain project, the protocol will deny any requests to disperse monies from the treasury. Any request to redeem tokens will be denied by the protocol if redemptions are suspended. If token burning is halted, the protocol will deny requests from token holders to burn their tokens.

Customized treasury add-ons

If there are no data source, delegate, split allocator, or ballot contracts associated to a project's financing cycles, the outcomes of each contact with the protocol are predictable, consistent, and described in these documents.

If a project has connected a data source, delegate, split allocator, or ballot contract to a funding cycle, the protocol will access information from them and invoke functionality inside them at certain times throughout the execution of different transactions within the protocol's normal operation.

Add or subtract payment terminals

A project may only accept payments and issue token redemptions via the payment terminals it has previously linked.

If installing payment terminals is authorized, projects may begin monitoring inflows and outflows of cash from new contracts, or delete existing contracts if they are doing so.

Configuring the controller

A project can only run in accordance with the rules of its presently configured controller, which cannot be changed.

If modifying the controller is permitted, projects may provide new operating guidelines.

Transferring money between terminals

While it is not permitted to transfer cash across terminals, a project's finances in one terminal cannot be transferred to another terminal with different limits.

If the transfer of money across terminals is permitted, a project may transfer its finances from one terminal to another.

Undistributed risk of reserve rate

If a project begins a funding cycle with a different reserved rate than the previous cycle and there are still outstanding reserved tokens to distribute, the amount of distributable tokens will change to match the new reserved rate.

For instance, if in FC#1 a project has a reserved rate of 10% and 9,000 tokens are minted, 1,000 tokens (10% of the total) are reserved for distribution to the reserved token receivers defined. If FC#2 with a 50% reserved rate occurs before the reserved tokens have been distributed, 9,000 tokens (50%) will be reserved for distribution to the preset reserved token recipients.

Anyone may make a transaction to distribute reserved tokens, since this is a public activity.

Price oracle risk

The protocol utilizes price oracles to standardize prices throughout its standard operations. These oracles are smart contract mechanisms that exist outside of the basic Snowcone protocol. Projects that use different currencies for specific functionality run the risk of these external oracle systems misreporting pricing values or stopping entirely. To eliminate this danger, distribution restrictions should be recorded in the same currency as the funds received.

Large number risk

Token holders trying to burn token amounts more than (2256 / 2) - 1, or 57896044618658097711785492504343953926634992332820282019728792003956564819968, would have their transactions rolled back owing to an arithmetic underflow.

What everyone needs to know

• Reserved tokens enable a project to ensure that a proportion of freshly generated tokens from payments will be reserved for a predefined list of SNOWSplits.

• This proportion is known as the reserved rate. Each financing cycle, the reserved rate and reserved token splits of a project may be adjusted.

• Reserved token splits may be routed to addresses, the owners of other Snowcone projects, contracts that comply to the ISNOWSplitAllocator interface, or the sender of the SNOWController.distributeReservedTokensOf(...) transaction.

• Reserved tokens are not immediately created when a fresh payment is made. Instead, they must be disbursed expressly within the financing cycle, which includes the applicable splits and reserved rate. If the reserved rate or splits for a funding cycle change before the allocation is dispersed, the new values will be applied.

What you'll want to know if you're building

• A reserved rate can be specified in a funding cycle through the SNOWController.launchProjectFor(...) or SNOWController.reconfigureFundingCyclesOf(...) transactions.

• Distributing currently allocated reserved tokens is done by calling SNOWController.distributeReservedTokensOf(...). Doing so will distribute the allocation according to the current funding cycle's reserved rate.

What everyone needs to know​

• An operator is an address that has been given permission to take one or more actions on another address's behalf.

• Several functions are only available to a project's owner, or to an operator address that the project's owner has set.

• Operator permissions are stored and managed in theSNOWOperatorStore, where they can be added or revoked at any time by the address being operated on behalf of.

• Operator permissions are expressed in terms of indexes defined in SNOWOperations.

• Operator permissions apply to a specific domain namespace, which is used in the Snowcone ecosystem to allow addresses to give permissions that only apply to a specific project (where the domain is the project's ID). A domain of 0 is a wildcard domain, giving an operator access to an action across all domains.

What you'll want to know if you're building​

• All permission indexes can be found inSNOWOperations.

• Any address can give an operator permissions to take one or more actions on its behalf by sending a transaction to SNOWOperatorStore.setOperator(...). To set multiple operators in the same transaction, use SNOWOperatorStore.setOperators(...).

• Access can be revoked from an operator through the same operations as above by sending an array of permissions that does not include those you wish to revoke.

• Permission for each operation is stored in a bit within an uint256. If the bit is 1, the permission is enabled for the particular operator within the particular domain. Otherwise it is disabled.

• SNOWOperatorStore.hasPermission(...) and SNOWOperatorStore.hasPermissions(...)can be used to check if an operator has a particular permission.

Operatable functionality​

For each project, the following functions can only be accessed by either the address that owns the project's NFT or by operator addresses explicitly allowed by the address that owns the project's NFT. Operators are only valid in the context of a particular owner – if the NFT changes hands, the operators for the project must be set again by the new owner.

An address can set operators for its project with SNOWOperatorStore.setOperator(...), using the indexes from the SNOWOperations library. An Operator's permissions depend on the specific parameters the admin allows them. Each of the following functions can be called by the admin, and also by any operator that has been granted permission to call the function by the admin.

• SNOWController.launchFundingCyclesFor(...)

• SNOWController.reconfigureFundingCyclesOf(...)

• SNOWController.mintTokensOf(...)

• SNOWTokenStore.issueFor(...)

• SNOWController.setFor(...)

• SNOWController.migrate(...)

• SNOWPayoutRedemptionPaymentTerminal.useAllowanceOf(...)

• SNOWPayoutRedemptionPaymentTerminal.migrate(...)

• SNOWPayoutRedemptionPaymentTerminal.processFees(...)

• SNOWProjects.setMetadataOf(...)

• SNOWSplitsStore.set(...)

• SNOWDirectory.setControllerOf(...)

• SNOWDirectory.setTerminalsOf(...)

• SNOWDirectory.setPrimaryTerminalOf(...)

The following transactions can be used by token holders or operator addresses explicitly allowed by the address that owns the tokens. If the tokens change hands, the operators must be set again by the new holder.

• SNOWController.burnTokensOf(...)

• SNOWPayoutRedemptionPaymentTerminal.redeemTokensOf(...)

• SNOWTokenStore.claimFor(...)

• SNOWTokenStore.transferFrom(...)

What everyone needs to know​

• Projects can configure funding cycles to create rules to follow over set amounts of time.

• A funding cycle's parameters can't be changed while it is in progress, but the project owner can propose reconfigurations to an upcoming cycle at any time.

• Funding cycles roll over automatically. If there is a reconfiguration in place and it has been approved by the current cycle's ballot, it will be used. Otherwise, a copy of the current funding cycle will be used with an updated start time and discounted weight.

• The mechanics of each project can vary dramatically depending on how its funding cycles are configured over time. Become familiar with how projects work to get a better understanding of how these decisions can be made.

What you'll want to know if you're building​

• A funding cycle is represented as a SNOWFundingCycle data structure.

• It is possible to create funding cycles that allow for total flexibility, total rigidity, or anything in between. Flexibility can be useful for rapid experimentation and evolution, whereas rigidity can be useful for dependability and trust. Anyone can configure a project's first funding cycle alongside creating the project with a call toSNOWController.launchProjectFor(...), and the project's owner can issue a reconfiguration to subsequent funding cycles with a call to SNOWController.reconfigureFundingCyclesOf(...).

• If a project has a current funding cycle, it can be found by reading from SNOWFundingCycleStore.currentOf(...). A project's upcoming funding cycle can be found by reading from SNOWFundingCycleStore.queuedOf(...). The funding cycles that carry each original configuration can be found by reading from SNOWFundingCycleStore.get(...). SNOWController.currentFundingCycleOf(...) and SNOWController.queueFundingCycleOf(...) can also be used to get a reference to the funding cycle's metadata alongside.

• A funding cycle's ballot property is useful for setting rules by which any proposed reconfiguration to subsequent cycles must adhere. This is useful for community oriented projects as it can prevent a project owner from maliciously updating an upcoming cycle's configuration moments before it begins without the broader community's consent. A funding cycle's ballot status, which is a SNOWBallotState enumeration, can be found by reading from SNOWFundingCycleStore.currentBallotStateOf(...).

• Look through theSNOWFundingCycleStore contract for a complete list of relevant read functions, write functions, and emitted events. Several properties ofSNOWController and SNOWSingleTokenPaymentTerminalStore also store information relative to funding cycle configurations.

What everyone needs to know​

• The payment distribution splits and reserved token distribution splits of a project may be directed toward bespoke allocator contracts.

• During any funding cycle setup, an allocator may be added to a project's split to automate the distribution of treasury cash and reserved project tokens.

• When a split receives money, an allocator's allocation(...) transaction is initiated automatically.

What you'll want to know if you're building​

• An allocator contract must adhere to the ISNOWSplitsAllocator interface.

• An allocator can be specified in a split through the SNOWController.launchProjectFor(...), SNOWController.reconfigureFundingCyclesOf(...), or SNOWSplitStore.set(...).

What everyone needs to know​

• A project may maintain splits for any number of groups, including payment distributions and reserved token distributions.

• A split can specify an address, a Snowcone project, a contract that adheres to the ISNOWSplitAllocator interface, or the address that calls the transaction to distribute payouts or reserved tokens as its recipient.

• By default, splits can be changed at any time for any funding cycle configuration. A project's owner can also independently lock a split to a funding cycle configuration for a customizable duration.

What you'll want to know if you're building​

• Splits can be set for a funding cycle configuration during the SNOWController.launchProjectFor(...) or SNOWController.reconfigureFundingCyclesOf(...) transactions, or separately using SNOWSplitStore.set(...).

What everyone needs to know​

• By default, all payments received by a Snowcone project are converted into tokens. These tokens are delivered to a payee-specified recipient as well as any addresses included in the project's reserved token list. The number of tokens created is proportional to the amount paid and the weight (i.e. exchange rate) of the current financing cycle for the project. Using data sources, projects may alter or enhance this default behavior.

• By default, the protocol distributes tokens to receivers using SNOWTokenStore's internal accounting system. These are fungible, but do not adhere to the ERC-20 standard; consequently, they are incompatible with ecosystem ERC-20/ERC-721 marketplaces such as AMMs and Opensea. Their balances may be used to cast votes on several platforms.

• Projects can issue their own ERC-20 token directly from the protocol to use as its token. Projects can also bring their own token as long as it conforms to the ISNOWToken interface and uses 18 decimal fixed point accounting. This makes it possible to use ERC-1155's or custom tokens.

• Once a project has issued a token, token holders can export tokens from the protocol's internal accounting mechanism in SNOWTokenStore to their wallet to use across Web3. A project's owner can also force project tokens to be issued directly to the exported version. This bypasses the internal accounting mechanism, but slightly increases gas costs for transactions that requires tokens to be minted.

• By default, tokens can be redeemed by holders to reclaim a portion of what's in the project's overflow. The amount of overflow claimable is determined by the redemptionRate of the project's current funding cycle. Projects can override or extend this default behavior. Redeeming tokens burns them, shrinking the total supply.

• A project owner can mint and distribute more of the project's tokens on demand. This behavior must be explicitly allowed on a per-funding cycle basis.

• A project can use its tokens however it wishes. It can be purely ceremonial, used for governance, used for airdrops, or whatever.

What you'll want to know if you're building​

• Tokens can be minted on-demand by project owners or their operators by calling SNOWController.mintTokensOf(...). The ability to do so must be explicitly turned on via a funding cycle configuration metadata parameter.

• Tokens can be burned on-demand by holders by calling SNOWController.burnTokensOf(...). The ability to do so can be turned off via a funding cycle configuration metadata parameter.