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 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.

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.

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 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.

• 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.

• 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​

• 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​

• 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(...)

• 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.

• 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.

• 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​

• 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.

• 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.

• 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.

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(...).