Welcome to the "Create" section of Snowcone DAO. This is where you'll find all the resources you need to start your own project, understand our governance structure, and engage with our vibrant community.

Make Your Snowcone Project

Have an idea for a project that could benefit the Snowcone DAO community? We're here to help you bring it to life. Our platform provides a range of resources and tools designed to support project development within our ecosystem. From technical documentation to best practices, you'll find everything you need to kickstart your project.

Understanding our governance structure is key to participating effectively in Snowcone DAO. We've compiled a set of resources to help you navigate our governance model, understand the decision-making process, and learn how you can contribute to shaping the future of Snowcone DAO.

Our community is the heart of Snowcone DAO. Whether you're looking to connect with other members, share ideas, or get support, our community resources can guide you. Discover our forums, social media channels, and other platforms where you can engage with the Snowcone DAO community.

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.

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.

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

Import​

Add the protocol files to the project.

# command linenpm install @Snowcones/snowcones-icy-contracts/

If referencing from typescript:

const contract = require(`@Snowcones/snowcones-icy-contracts/deployments/${network}/${contractName}.json`)

If referencing from a contract:

Now what​

From here, you can build the following:

Basics - Interact with the protocol's basic functionality. Useful for building front-ends.

Pay a project - Deploy or inherit from a contract that makes it easy to forward funds to Snowcone projects.

Split payments - Deploy or inherit from a contract that makes it easy to forward funds to groups of splits whose members are either addresses, Snowcone projects, or arbitrary contracts that inherit from ISNOWSplitAllocator.

Program a treasury - Get familiar with the configurable properties available when launching a project.

Program project permissions - Build custom Snowcone Project NFT logic to create your own project access controls.

Program treasury extensions - Create custom contractual rules defining what happens when a project receives funds, and under what conditions funds can leave the treasury during a funding cycle.

Workflows

The first transaction to call when getting started is SNOWController.launchProjectFor(...).

Specifications

A contract can become a split allocator by adhering to ISnowconeSplitAllocator:

interface ISnowconeSplitAllocator {
  function allocate(SnowconeSplitAllocationData calldata _data) external payable;
}

When extending payout distribution or reserved token distribution functionality with an allocator, the protocol will pass a SnowconeSplitAllocationData to the allocate(...) function:

The msg.sender to the allocator will either be the payment terminal that facilitated the payout distribution, or the controller that facilitated the reserved tokens distribution.

In payment terminals based on the SnowconePayoutRedemptionPaymentTerminal3_1_1, such as SnowconeETHPaymentTerminal3_1_1's and SnowconeERC20PaymentTerminal3_1_1's, the allocator hook gets called while the payouts are being distributed to splits. View the docs.

If the allocation is coming from an ETH payment terminal such as SnowconeETHPaymentTerminal3_1_1, the ETH will be included in the call to allocate(...). If the allocation is coming from an ERC20 payment terminal such as SnowconeERC20PaymentTerminal3_1_1, the tokens will be pre-approved for the allocator contract to transfer them to it. Make sure to initiate the transfer, and make sure to not leave allocated tokens stuck in the allocator contract. If the allocation is coming from a controller such as SnowconeController3_1 distributing reserved tokens, the tokens will be minted pre-distributed to the allocator's address. If the split's preferClaimed property is true and the project has a token a contract attached, the tokens will be minted directly to the allocator contract. Otherwise, they will be allocated in the SnowconeTokenStore as unclaimed tokens from which the allocator can then claimFor(...) itself or transferFrom(...) itself to another address. Make sure to not leave allocated tokens stuck in the allocator contract or unclaimed in the SnowconeTokenStore contract.

Attaching

New allocator contracts should be deployed independently. Once deployed, its address can be configured into a project's payout splits or reserved token splits so that any distribution triggered while the funding cycle is active sends the relevant token to the allocator contract's allocate(...) hook.

Before implementing, learn about delegates here. Also see snow-delegate-template.

Specs

A contract can become a treasury pay delegate by adhering to ISNWPayDelegate3_1_1:

interface ISNWPayDelegate3_1_1 is IERC165 {
  function didPay(SNWDidPayData3_1_1 calldata data) external payable;
}

When extending pay functionality with a delegate, the protocol will pass a SNWDidPayData3_1_1 to the didPay(...) function:

struct SNWDidPayData3_1_1 {
    address payer;
    uint256 projectId;
    uint256 currentFundingCycleConfiguration;
    SNWTokenAmount amount;
    SNWTokenAmount forwardedAmount;
    uint256 projectTokenCount;
    address beneficiary;
    bool preferClaimedTokens;
    string memo;
    bytes dataSourceMetadata;
    bytes payerMetadata;
}

struct SNWTokenAmount {
  address token;
  uint256 value;
  uint256 decimals;
  uint256 currency;
}

The msg.sender to the delegate will be the payment terminal that facilitated the payment.

In payment terminals based on the SNWPayoutRedemptionPaymentTerminal3_1_1, such as SNWETHPaymentTerminal3_1_1's and SNWERC20PaymentTerminal3_1_1's, the pay delegate hook gets called after the project's tokens have been minted and distributed. View the docs.

Make sure to only allow trusted contracts to access the didPay(...) transaction.

Attaching

New delegate contracts should be deployed independently. Once deployed, its address can be returned from a data source hook. See how to build a data source for more.

Examples

Welcome to the Data Structures section of Snowcone documentation. Here you'll find comprehensive details about the different data structures used within Snowcone. We'll go through each of these data structures one by one and discuss how they are used.

Contents

1. SNOW721PricingParams

SNOW721PricingParams

This section covers the SNOW721PricingParams data structure, which manages the pricing parameters for Snowcone's NFTs.

SNOW721Tier

This section covers the SNOW721Tier data structure, which is used to define the different tiers for Snowcone's NFTs.

SNOW721TierParams

Here we discuss the SNOW721TierParams data structure, which is used to set up the parameters for each tier.

SNOWBitmapWord

This section covers the SNOWBitmapWord data structure, which is used to handle bitmap-based operations.

SNOWDeployTiered721DelegateData

In this section, we explore the SNOWDeployTiered721DelegateData data structure, which sets up the delegate data for the tiered 721 tokens.

SNOWDidPayData

This section covers the SNOWDidPayData data structure, which is used to manage payment data in the Snowcone protocol.

We hope this guide helps you understand the various data structures used in the Snowcone protocol. If you have any questions or need further clarification, please reach out to our team.

Code

link to github

Definition

/**
  @member id The tier's ID.
  @member contributionFloor The minimum contribution to qualify for this tier.
  @member lockedUntil The time up to which this tier cannot be removed or paused.
  @member remainingQuantity Remaining number of tokens in this tier. Together with idCeiling this enables for consecutive, increasing token ids to be issued to contributors.
  @member initialQuantity The initial `remainingAllowance` value when the tier was set.
  @member votingUnits The amount of voting significance to give this tier compared to others.
  @member reservedRate The number of minted tokens needed in the tier to allow for minting another reserved token.
  @member reservedRateBeneficiary The beneificary of the reserved tokens for this tier.
  @member encodedIPFSUri The URI to use for each token within the tier.
  @member allowManualMint A flag indicating if the contract's owner can mint from this tier on demand.
*/
struct SNOW721Tier {
  uint256 id;
  uint256 contributionFloor;
  uint256 lockedUntil;
  uint256 remainingQuantity;
  uint256 initialQuantity;
  uint256 votingUnits;
  uint256 reservedRate;
  address reservedTokenBeneficiary;
  bytes32 encodedIPFSUri;
  bool allowManualMint;
}

Code

github link

Definition

/**
  @member contributionFloor The minimum contribution to qualify for this tier.
  @member lockedUntil The time up to which this tier cannot be removed or paused.
  @member initialQuantity The initial `remainingAllowance` value when the tier was set.
  @member votingUnits The amount of voting significance to give this tier compared to others.
  @memver reservedRate The number of minted tokens needed in the tier to allow for minting another reserved token.
  @member reservedRateBeneficiary The beneificary of the reserved tokens for this tier.
  @member encodedIPFSUri The URI to use for each token within the tier.
  @member allowManualMint A flag indicating if the contract's owner can mint from this tier on demand.
  @member shouldUseBeneficiaryAsDefault A flag indicating if the `reservedTokenBeneficiary` should be stored as the default beneficiary for all tiers.
*/
struct SNOW721TierParams {
  uint256 contributionFloor;
  uint256 lockedUntil;
  uint256 initialQuantity;
  uint256 votingUnits;
  uint256 reservedRate;
  address reservedTokenBeneficiary;
  bytes32 encodedIPFSUri;
  bool allowManualMint;
  bool shouldUseBeneficiaryAsDefault;
}

Code

link to github

Definition

/**
  @member tiers The tiers to set.
  @member currency The currency that the tier contribution floors are denoted in.
  @member decimals The number of decimals included in the tier contribution floor fixed point numbers.
  @member prices A contract that exposes price feeds that can be used to resolved the value of a contributions that are sent in different currencies. Set to the zero address if payments must be made in `currency`.
*/
struct SNOW721PricingParams {
  SNOW721TierParams[] tiers;
  uint256 currency;
  uint256 decimals;
  SNOWPrices prices;
}

Specifications

A contract can become a treasury pay delegate by adhering to ISnowconePayDelegate3_1_1:

interface ISnowconePayDelegate3_1_1 is IERC165 {
  function didPay(SnowconeDidPayData3_1_1 calldata data) external payable;
}

When extending pay functionality with a delegate, the protocol will pass a SnowconeDidPayData3_1_1 to the didPay(...) function:

struct SnowconeDidPayData3_1_1 {
    address payer;
    uint256 projectId;
    uint256 currentFundingCycleConfiguration;
    SnowconeTokenAmount amount;
    SnowconeTokenAmount forwardedAmount;
    uint256 projectTokenCount;
    address beneficiary;
    bool preferClaimedTokens;
    string memo;
    bytes dataSourceMetadata;
    bytes payerMetadata;
}

struct SnowconeTokenAmount {
  address token;
  uint256 value;
  uint256 decimals;
  uint256 currency;
}

The msg.sender to the delegate will be the payment terminal that facilitated the payment.

In payment terminals based on the SnowconePayoutRedemptionPaymentTerminal3_1_1, such as SnowconeETHPaymentTerminal3_1_1's and SnowconeERC20PaymentTerminal3_1_1's, the pay delegate hook gets called after the project's tokens have been minted and distributed. View the docs.

Ensure to only allow trusted contracts to access the didPay(...) transaction.

Attaching

New delegate contracts should be deployed independently. Once deployed, its address can be returned from a data source hook. See how to build a data source for more.

Examples

Interfaces

Inheritance

Constructor

_operatorStore is an ISnowconeOperatorStore contract storing operator assignments.

Events

Properties

Read

Write

Create a new project for the specified owner, which mints an NFT (ERC-721) into their wallet.

Anyone can create a project on an owner's behalf.

Definition

function createFor(address _owner, SNWProjectMetadata calldata _metadata)
external
override
returns (uint256 projectId) { ... }

Arguments:

owner is the address that will be the owner of the project.

metadata is a struct containing metadata content about the project, and domain within which the metadata applies. The function can be accessed externally by anyone. The function overrides a function definition from the ISNWProjects interface. The function returns the token ID of the newly created project.

Below are some sample queries you can use to gather information from the Snowcone contracts.

You can build your own queries using a GraphQL Explorer—enter your endpoint to limit your queries to the exact data desired.

Get Project Metrics By Owner

Get Project ID.

query ProjectByOwner(
  $Owner: String! = "0xaf28bcb48c40dbc86f52d459a6562f658fc94b1e"
) {
  projects(where: { owner: $Owner }, first: 10) {
    createdAt
    id
    owner
    projectId
    totalPaid
    totalRedeemed
    metadataUri
    handle
    terminal
    currentBalance
    cv
  }
}

Project Metrics

Get the latest metrics for your project.

Project Payments

Get the 20 latest payments into your project.

Welcome to the "Subgraph" section of Snowcone DAO. This is where you'll find detailed information about our subgraph, a crucial tool for querying and indexing blockchain data. Whether you're a developer looking to extract data from our protocol or someone interested in analyzing our blockchain data, this section provides the resources you need. Here's what you can find in each subsection:

Subgraph Entities

This subsection provides a comprehensive overview of the entities in our subgraph. Entities represent the various objects in our protocol, and understanding them is key to querying our subgraph effectively. You'll find definitions, properties, and usage examples for each entity.

If you're new to querying subgraphs or just looking for some examples, this subsection is for you. It provides a collection of sample queries that you can use as a starting point for your own data extraction and analysis. Each sample query comes with a detailed explanation and usage instructions.

Background

Welcome, developers and enthusiasts, to the comprehensive documentation of the Snowcone Protocol.

Snowcone is a sophisticated, programmable treasury protocol designed to provide projects with a flexible and secure financial infrastructure. It empowers projects to define the rules for token creation upon receiving funds, and to determine how these funds should be distributed to preprogrammed addresses or reclaimed by the community.

The protocol's flexibility allows for adjustments over the course of financing cycles. This adaptability enables anyone to launch open-ended initiatives, progressively adding structure, limitations, extensions, and incentives as needed. While simple enough for a small group of friends to utilize, Snowcone has the capacity to uphold a global network of anonymous users engaged in the distribution and exchange of various digital assets such as AVAX, ETH, and ERC-20s.

However, navigating the intricacies of the protocol requires a nuanced understanding. That's where this documentation comes in. Whether you're conducting an audit, building your own Snowcone project, developing extensions, hunting for bugs, or simply seeking to deepen your knowledge of Solidity and contract design, these documents are designed to be your comprehensive guide.

We've structured this documentation to cater to both detailed analysis and high-level overviews, ensuring you can easily find the information you need. So, whether you're diving deep into the technical details or just getting a grasp of the big picture, we've got you covered.

Welcome to the world of Snowcone. Let's build the future of decentralized finance together.

Directory

• The "Create" subsection provides resources and guides to help you start your own project within the Snowcone DAO ecosystem. Whether you're looking to build a new dApp or propose a governance change, you'll find the necessary tools and information here.

Reach out to SnowMaker on to bring their attention to a potential improvement.

What is Gnosis Safe?

The majority of Crypto wallets are protected by a private key that may be converted into a 12-word "seed phrase." If this private key is compromised, the money are susceptible to theft.

Gnosis Safe is an Ethereum-based smart contract wallet that needs a minimum number of persons to authorize a transaction before it can take place (M-of-N). If, for instance, your firm has three primary stakeholders, you may configure the wallet to demand consent from all three before sending a transaction. This ensures that no one individual may jeopardize the cash.

Why Use a Multisig wallet?

A multisig (like Gnosis Safe) protects you and your community.

• If your wallet becomes compromised, the attacker cannot take over your Snowcone project.

• You (or another Safe signer) could not unilaterally execute malicious transactions affecting your Snowcone project.

A multisig is an extra shield to protect your projects from harmful or faulty reconfigurations. It does come with risks though—if you cannot meet the Safe's threshold, you will lose access to everything inside of it.

Deploy a Gnosis Safe

1. Visit and click Open app in the upper right-hand corner.

2. Connect your wallet and click + Create new Safe.

3. Click Continue

• More than one owner.

• A threshold higher than one.

• A threshold lower than the number of owners. Therefore, even if one owner loses access to their account, the Safe can still be accessed.

5. Click create and confimr the transaction to deploy your Safe. Then click Get started.

Deploy your Snowcone Project from a Safe

To deploy your Snowcone Project from a Gnosis Safe, open the Apps page in the left-hand menu on gnosis-safe.io/. Search for the Snowcone app and open it. From there, you can follow standard creation guides—instead of deploying your project at the end, a transaction to deploy your project will be queued, and other multisig owners will have to sign that transaction.

Someone will have to pay gas fees and execute the transaction once it reaches the required number of signatures.

Welcome to the "Mark Your Snowcone Project" section of the Snowcone documentation. This guide aims to provide you with the knowledge to mark your Snowcone project effectively and efficiently, whether it is in terms of project details, funding, token management, or the rules to be followed.

Contents

Overview

Project Details are displayed on your Snowcones.io project page. This section includes your project's title, description, logo, important links, and pay button customization.

• These details can be updated later.

• Emojis can be used in these fields.

• This information is stored on IPFS.

Options

What is a snapshot?

From the Snapshot Docs:

Snapshot is a decentralized voting system. It provides flexibility on how voting power is calculated for a vote. Snapshot supports various voting types to cater to the needs of organizations. Creating proposals and voting on Snapshot is user-friendly and does not cost gas as the process is performed off-chain.

In short, Snapshot is an off-chain gasless multi-governance client with easy to verify and hard to contest results.

You can easily set up Snapshot voting with a Snowcone project token by using the strategies below. Make sure you follow the TODO notes, and delete the notes once you do. If you need help customizing your parameters, send a message in the Snowcone Discord.

Overview

Restrictions on project reconfigurations and global toggles for suspending payments and activating token minting at will

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.

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.

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.

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.

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.

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.

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

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.

🟢This may be used effectively to control discretionary expenditure.

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

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.

🟢Utilized effectively, this may be utilized to issue tokens to members or to fulfill other agreed-upon inflationary treasury tactics.

🔴This may be used maliciously to issue more tokens and redeem them to get treasury cash into an arbitrary wallet, so robbing the whole treasury.

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.

🟢Utilized effectively, this may be utilized to control token issuance over time.

🔴This may be used maliciously to influence token issuance and transfer the whole treasury to a random wallet.

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.

🟢This may be utilized effectively to enable projects to complement a prior token strategy with a Snowcone treasury, remove a token from a Snowcone treasury, or construct new token mechanisms connected with their Snowcone treasury.

🔴This may be used maliciously to shut off a community of token holders from their treasury while reclaiming treasury monies into an arbitrary wallet through the redemption of a new token.

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.

🟢This may be utilized profitably to enable projects to creatively tweak how their treasury is accessible.

🔴This may be used maliciously to prevent token holders from accessing regular treasury services.

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.

🟢This may be used usefully to personalize what occurs when a treasury receives cash, under what circumstances monies can leave a treasury, and under what conditions reconfigurations can take effect.

🔴This may be used maliciously to issue excess tokens, transfer the whole treasury to an arbitrary wallet, deceive users into compromising their own wallets, generate arbitrary undesirable and extractive behavior, or inject smart contract faults into otherwise useful extension designs. Do not engage a project that employs an untrusted extension.

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.

🟢Utilized effectively, this may be used to begin accepting new tokens into a treasury or to create completely unique treasury behavior.

🔴This may be used maliciously to shut off a community of token holders from their treasury, to generate arbitrarily undesirable and extractive behavior, or to introduce smart contract vulnerabilities. Do not engage with a project using unreliable payment terminals.

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.

🟢Utilized well, this may be utilized to generate completely bespoke treasury behavior.

🔴This may be used maliciously to shut off a community of token holders from their treasury, to generate arbitrarily undesirable and extractive behavior, or to introduce smart contract vulnerabilities. Do not communicate with a project whose controller is untrusted.

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.

🟢Utilized effectively, this may be utilized to migrate a treasury into a completely customized environment or to trustworthy improved versions of the protocol.

🔴This may be used maliciously to shut off a community of token holders from their treasury, to generate arbitrarily undesirable and extractive behavior, or to introduce smart contract vulnerabilities.

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.

COMING SOON

Welcome to the Governance Resources section of Snowcone DAO. Here, we provide detailed information and guides on our governance structure and the tools we use to ensure a fair and transparent decision-making process. Our primary tools for governance include Snapshot and Gnosis Safe.

Snapshot

Snapshot is a gasless, multi-governance client with easy proposal mechanisms and voting. It allows Snowcone DAO members to propose changes and vote on them in a democratic and decentralized manner. Snapshot ensures that every voice in our community is heard and that decisions are made collectively.

Gnosis Safe

Gnosis Safe is a secure and trusted platform for managing digital assets and smart contracts. At Snowcone DAO, we use Gnosis Safe to implement multi-signature wallets, enhancing the security of our operations and ensuring that major decisions are approved by multiple trusted parties.

By understanding and utilizing these tools, you can actively participate in the governance of Snowcone DAO, contributing to our growth and success.

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.

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.

Welcome to the Community Resources section of Snowcone DAO. Our community is the lifeblood of our organization, and we're committed to fostering a vibrant, engaging, and supportive environment. One of the key platforms we use for community interaction is Discord.

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

• 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

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

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.

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​

• 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

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

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%

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.

Welcome to the "Build" section of Snowcone DAO. This is your comprehensive guide to actively contributing to our ecosystem. Whether you're a seasoned developer or just starting out, you'll find resources here to help you understand our protocol, create your own projects, and extend the capabilities of our treasury. Here's what you can find in each subsection:

New to Snowcone DAO or blockchain development? Start here. This subsection provides a step-by-step guide to setting up your development environment, understanding our protocol, and getting your first project off the ground.

Specifications

A contract can be transformed into a funding cycle ballot by adhering to ISnowconeFundingCycleBallot:

interface ISnowconeFundingCycleBallot {
  function duration() external view returns (uint256);

  function stateOf(
    uint256 _projectId,
    uint256 _configuration,
    uint256 _start
  ) external view returns (SnowconeBallotState);
}

Two functions must be implemented: duration(...) and stateOf(...). The result of duration(...) is the number of seconds the ballot lasts for from the moment the reconfiguration is proposed. During this time, the protocol automatically interprets the ballot's state as SnowconeBallotState.Active. The result of stateOf(...) returns the SnowconeBallotState. If a configuration is approved and the duration has expired, the SnowconeFundingCycleStore will use it as the project's current funding cycle when it becomes active. Otherwise, it will make a copy of the latest approved cycle to use.

When extending the pay functionality with a delegate, the protocol will pass a projectId, a configuration, and a start to the stateOf(...) function. configuration is the identifier of the funding cycle being evaluated, and also the unix timestamp in seconds of when the reconfiguration was proposed. start is the unix timestamp the reconfiguration is scheduled to start at if that reconfiguration is approved.

Once the duration(...) has expired, the returned value of stateOf(...) should no longer change.

Attaching

New ballot contracts should be deployed independently. Once deployed, its address can be configured into a project's funding cycle. The ballot will take effect while that funding cycle is active, and will be used for evaluating subsequent reconfigurations.

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.

SNOWETHERC20ProjectPayer contracts make it easy to route funds to projects' treasuries from other contracts or within inheriting contracts. This is useful for routing funds to a Snowcone treasury within other contracts such as an NFT's minting function, or creating contracts that will automatically route any received funds to a project's treasury with preconfigured parameters to send along with the payment.

The SNOWETHERC20ProjectPayer can be inherited from any contract to facilitate internal transactions to Snowcone treasuries in AVAX or any ERC-20, assuming the project is using a payment terminal that accepts the tokens. They can also be deployed as standalone project payer copies using SNOWProjectPayerDeployer.

Inheriting SNOWProjectPayer​

Inheriting from SNOWETHERC20ProjectPayer will give a contract access to a public SNOWProjectPayer.pay(...) function, a public SNOWProjectPayer.addToBalanceOf(...)function, an internal SNOWProjectPayer._pay(...) function, and an internal SNOWProjectPayer._addToBalanceOf(...) function. These can be used from within the contract to route funds to a Snowcone treasury while specifying all relevant parameters to contextualize the payment. Use the internal versions if the inheriting contract has already handled receiving the funds being forwarded.

Follow instructions in Getting started to import the SNOWProjectPayer files into a project.

Overview

When individuals fund a project, project tokens are generated. Token parameters determine how tokens function.

• By default, token balances are tracked in snowcone contracts. Once their product has been implemented, project owners can issue ERC-20 tokens on snowcones.io if they so want. This ERC-20 is available for community members to claim.

Treasury extensions allow projects to override or extend the default Snowcone protocol functionality with custom contract logic.

Discord is one of the most prominent social platforms in cryptocurrency. It allows users to construct free servers for their communities that are invite-only. Discord servers offer multiple channel messaging, voice/video calls, and the setup of sophisticated permissions. Through its API, Discord also allows bots and other forms of automation.

Get Discord

If you don't already have an account, create one at discord.gg. You can access Discord via a web browser or through its native apps on Windows, macOS, Android, iOS, or Linux. If you are a complete beginner, take a look at Discord's beginner's guide.

In order to understand what Snowcone can do for your project, all you have to do is understand how one transaction works :SNOWController.launchProjectFor(...), which creates a project, configures its first funding cycle, and specifies where it can begin receiving and managing funds from.

SNOWETHERC20SplitsPayer contracts make it easy to route funds to a group of splits from other contracts or within inheriting contracts. This is useful for routing funds to a number of Snowcone project treasuries and other addresses within other contracts such as an NFT marketplaces.

The SNOWETHERC20SplitsPayer can be inherited from any contract to facilitate internal transactions to split groups in AVAX or any ERC-20, assuming the projects in the split group are using a payment terminal that accepts the tokens. They can also be deployed as standalone splits payer copies using SNOWSplitsPayerDeployer.

Inheriting SNOWSplitsPayer​

Inheriting from SNOWETHERC20SplitsPayer will give a contract access to a public SNOWSplitsPayer.pay(...) function, a public SNOWSplitsPayer.addToBalanceOf(...)function, and two functions SNOWSplitsPayer._payToSplits(...) and SNOWSplitsPayer._payTo(...). These can be used from within the contract to route funds to a group of splits while specifying where leftover funds should go. Use the internal function if the inheriting contract has already handled receiving the funds being forwarded.

Follow instructions in Getting started to import the SNOWSplitsPayer files into a project.

Specifications

A contract can become a treasury redemption delegate by adhering to ISnowconeRedemptionDelegate3_1_1:

interface ISnowconeRedemptionDelegate3_1_1 is IERC165 {
  function didRedeem(SnowconeDidRedeemData3_1_1 calldata data) external payable;
}

When extending the redemption functionality with a delegate, the protocol will pass a SnowconeDidRedeemData3_1_1 to the didRedeem(...) function:

struct SnowconeDidRedeemData3_1_1 {
    address holder;
    uint256 projectId;
    uint256 currentFundingCycleConfiguration;
    uint256 projectTokenCount;
    SnowconeTokenAmount reclaimedAmount;
    SnowconeTokenAmount forwardedAmount;
    address payable beneficiary;
    string memo;
    bytes dataSourceMetadata;
    bytes redeemerMetadata;
}

struct SnowconeTokenAmount {
  address token;
  uint256 value;
  uint256 decimals;
  uint256 currency;
}

The msg.sender to the delegate will be the payment terminal that facilitated the redemption.

In payment terminals based on the SnowconePayoutRedemptionPaymentTerminal3_1_1, such as SnowconeETHPaymentTerminal3_1_1's and SnowconeERC20PaymentTerminal3_1_1's, the redemption delegate hook gets called before the reclaimed amount is sent to the redemption beneficiary, but after all internal accounting has been updated. View the docs.

Ensure to only allow trusted contracts to access the didRedeem(...) transaction.

Attaching

New delegate contracts should be deployed independently. Once deployed, its address can be returned from a data source hook.

Specifications

A contract can be transformed into a treasury data source by adhering to ISnowconeFundingCycleDataSource3_1_1:

Two functions must be implemented, payParams(...) and redeemParams(...). Either one can be left empty if the intent is to only extend the treasury's pay functionality or redeem functionality.

Pay

When extending the pay functionality with a data source, the protocol will pass a SnowconePayParamsData to the payParams(...) function:

Using these params, the data source's payParams(...) function is responsible for either reverting or returning a few bits of information:

weight is a fixed point number with 18 decimals that the protocol can use to base arbitrary calculations on. For example, payment terminals based on the SnowconePayoutRedemptionPaymentTerminal3_1_1, such as SnowconeETHPaymentTerminal3_1_1's and SnowconeERC20PaymentTerminal3_1_1's, use the weight to determine how many project tokens to mint when a project receives a payment (see the calculation). By default, the protocol will use the weight of the project's current funding cycle, which is provided to the data source function in SnowconePayParamsData.weight. Increasing the weight will mint more tokens and decreasing the weight will mint fewer tokens, both as a function of the amount paid. Return the SnowconePayParamsData.weight value if no altered functionality is desired.

memo is a string emitted within the Pay event and sent along to any delegate that this function also returns. By default, the protocol will use the memo directly passed in by the payer, which is provided to this data source function in SnowconePayParamsData.memo. Return the SnowconePayParamsData.memo value if no altered functionality is desired.

delegateAllocations is an array containing delegates, amounts to send them, and metadata to pass to them.

delegateAllocations.delegate is the address of a contract that adheres to ISnowconePayDelegate3_1_1 whose didPay(...) function will be called once the protocol finishes its standard payment routine. Check out how to build a pay delegate for more details. If the same contract is being used as the data source and the pay delegate, return address(this). Return the zero address if no additional functionality is desired.

delegateAllocations.amount is the amount of tokens to send to the delegate.

delegateAllocations.metadata is the metadata to pass to the delegate.

The payParams(...) function can also revert if it's presented with any conditions it does not want to accept payments under.

The payParams(...) function has implicit permission to SnowconeController3_1.mintTokensOf(...) for the project.

Redeem

When extending redeem functionality with a data source, the protocol will pass a SnowconeRedeemParamsData to the redeemParams(...) function:

Using these params, the data source's redeemParams(...) function is responsible for either reverting or returning a few bits of information:

reclaimAmount is the amount of tokens in the treasury that the terminal should send out to the redemption beneficiary as a result of burning the amount of project tokens tokens specified in SnowconeRedeemParamsData.tokenCount, as a fixed point number with the same amount of decimals as SnowconeRedeemParamsData.decimals. By default, the protocol will use a reclaim amount determined by the standard protocol bonding curve based on the redemption rate the project has configured into its current funding cycle, which is provided to the data source function in SnowconeRedeemParamsData.reclaimAmount. Return the SnowconeRedeemParamsData.reclaimAmount value if no altered functionality is desired.

memo is a string emitted within the RedeemTokens event and sent along to any delegate that this function also returns. By default, the protocol will use the memo passed in directly by the redeemer, which is provided to this data source function in SnowconeRedeemParamsData.memo. Return the SnowconeRedeemParamsData.memo value if no altered functionality is desired.

delegateAllocations is an array containing delegates, amounts to send them, and metadata to pass to them.

delegateAllocations.delegate is the address of a contract that adheres to ISnowconeRedemptionDelegate3_1_1 whose didRedeem(...) function will be called once the protocol finishes its standard redemption routine (but before the reclaimed amount is sent to the beneficiary). Check out how to build a redemption delegate for more details. If the same contract is being used as the data source and the redemption delegate, return address(this). Return the zero address if no additional functionality is desired.

delegateAllocations.amount is the amount of tokens to send to the delegate.

delegateAllocations.metadata is the metadata to pass to the delegate.

The redeemParams(...) function can also revert if it's presented with any conditions it does not want to accept redemptions under.

Attaching

New data source contracts should be deployed independently. Once deployed, its address can be configured into a project's funding cycle metadata to take effect while that funding cycle is active. Additionally, the metadata's useDataSourceForPay and/or useDataSourceForRedeem should be set to true if the respective data source hook should be referenced by the protocol.

Examples

Code

Githublink

Definition

/**
  @member The information stored at the index.
  @member The index.
*/
struct BitmapWord {
  uint256 currentWord;
  uint256 currentDepth;
}

Welcome to the Utilities section of Snowcone documentation. In this part, we delve into the various utility functions that Snowcone provides to make your development journey smoother and more efficient.

Contents

1. Project Payer

Project Payer

This section explores the Project Payer utility, which is instrumental in managing payments within a Snowcone project. Understand how this utility can simplify transactions for your project.

Splits Payer

In this section, we cover the Splits Payer utility. Learn how this feature can help manage and distribute payments among different stakeholders in a project.

We hope this guide helps you understand the various utilities available in the Snowcone protocol. If you have any questions or need further clarification, please reach out to our team.

Contract: SnowconeProjects

Interface: ISnowconeProjects

The contract resolving each project ID to its ERC721 URI.

Definition

The resulting view function can be accessed externally by anyone. The resulting function overrides a function definition from the ISnowconeProjects interface.

Emitted from:

setMetadataOf Definition

event SetMetadata(uint256 indexed projectId, SnowconeProjectMetadata metadata, address caller);

projectId is the token ID of the NFT (ERC-721) that represents the project whose URI was set. metadata is the metadata that was associated with the project upon its creation. It can be found using the metadataContentOf property. caller is the address that issued the transaction within which the event was emitted.

Emitted from:

createFor Definition

projectId is the token ID of the NFT (ERC-721) that was created to represent the project. owner is the address that owns the NFT (ERC-721) token representing the project. metadata is the metadata that was associated with the project upon its creation. It can be found using the metadataContentOf property. caller is the address that issued the transaction within which the event was emitted.

Welcome to the "API" section of Snowcone DAO. This is where you'll find detailed information about our Application Programming Interface (API), which allows developers to interact with our protocol programmatically. Whether you're looking to integrate with Snowcone DAO or build on top of our platform, this section provides the technical details you need. Here's what you can find in each subsection:

Data Structures

Understanding our data structures is key to working with our API effectively. This subsection provides a comprehensive overview of the data structures used in the Snowcone DAO protocol, including their definitions, properties, and usage.

This subsection dives into the specifics of our smart contracts. It provides detailed specifications for each contract in our protocol, including their functions, parameters, and events. Whether you're looking to deploy a new contract or interact with an existing one, this section has the information you need.

Anyone can build on the SNOWProjects NFT contract. This allows developers to write new contracts which use SNOWProjects NFTs to manage permissions in a standardized way, and allows any project using Snowcone payment terminals to access your contracts, and vice versa.

Create a project​

Instead of calling SNOWController.launchProjectFor(...) to create a project, configure its first funding cycle, and attach payment terminals and a Snowcone controller contract to it in the same transaction, SNOWProjects can be minted independently to represent ownership over projects with subsequent capabilities attached later on.

To create a project, call SNOWProjects.createFor(...). The SNOWProjectMetadata structure allows arbitrary metadata to be mapped to any namespace domain. Snowcones.io metadata uses a domain of 0 to store its formatted metadata.

Allows a project owner to set the project's metadata content for a particular domain namespace.

Only a project's owner or operator can set its metadata.

Applications can use the domain namespace as they wish.

Definition

function setMetadataOf(uint256 _projectId, SNWProjectMetadata calldata _metadata)
  external
  override
  requirePermission(ownerOf(_projectId), _projectId, SNOWperations.SET_METADATA) { ... }

Arguments:

• _projectId is the ID of the project whose metadata is being changed.

• _metadata is the struct containing metadata content, and domain within which the metadata applies.

Through the requirePermission modifier, the function is only accessible by the project's owner, or from an operator that has been given the SNWOperations.SET_METADATA permission by the project owner for the provided _projectId.

The function overrides a function definition from the ISNWProjects interface. The function doesn't return anything.

Body

Internal references:

• metadataContentOf

Emit a SetMetadataCid event with the relevant parameters.

Event references:

• SetMetadata

Interface: ISnowconeProjects

The number of projects that have been created using this contract.

The count is incremented with each new project created. The resulting ERC-721 token ID for each project is the newly incremented count value.

Definition

/**
  @notice
  The number of projects that have been created using this contract.

  @dev
  The count is incremented with each new project created.
  The resulting ERC-721 token ID for each project is the newly incremented count value.
*/
uint256 public override count = 0;

The resulting view function can be accessed externally by anyone. The resulting function overrides a function definition from the ISnowconeProjects interface.

See The Graph Docs for more on defining entities.

Entities​

• ProtocolLog

Notes:

• project.id is string concatenated from multiple properties. projectId represents an integer id of the project.

• Familiarize yourself with sample records of the various entities on GraphLooker.

ProtocolLog

Description: High level view of the Snowcone Protocol Applicable Versions: v1

ProjectCreateEvent

Description: Entity detailing info about the creation of a project Applicable Versions: v1.0, v1.1, v2

Project

Description: Applicable Versions: v1.0, v1.1, v2

ENSNode

Description: Applicable Versions: v2

Participant

Description: A users participation with a project. This is the M:M link between users:projects Applicable Versions: v1.0, v1.1, v2

ProjectEvent

Description: Applicable Versions: v1.0, v1.1, v2

PayEvent

Description: Applicable Versions: v1.0, v1.1, v2

MintTokensEvent

Description: Applicable Versions: v1.0, v1.1, v2

RedeemEvent

Description: Applicable Versions: v1.0, v1.1, v2

DeployedERC20Event

Description: Applicable Versions: v1.0, v1.1, v2

ProtocolV1Log

Description: Applicable Versions: v1.0, v1.1

PrintReservesEvent

Description: Applicable Versions: v1.0, v1.1

DistributeToPayoutModEvent

Description: Applicable Versions: v1.0, v1.1

TapEvent

Description: Applicable Versions: v1.0, v1.1

DistributeToTicketModEvent

Description: Applicable Versions: v1.0, v1.1

ProtocolV2Log

Description: Applicable Versions: v2

DistributePayoutsEvent

Description: Applicable Versions: v2

DistributeToPayoutSplitEvent

Description: Applicable Versions: v2

DistributeReservedTokensEvent

Description: Applicable Versions: v2

DistributeToReservedTokenSplitEvent

Description: Applicable Versions: v2

UseAllowanceEvent

Description: Applicable Versions: v2

DeployETHERC20ProjectPayerEvent

Description: Applicable Versions: v2

ETHERC20ProjectPayer

Description: Applicable Versions: v2

VeNftToken

Description: Applicable Versions: v2

Emitted from:

setTokenUriResolver Definition

newResolver is the new URI resolver contract. caller is the address that issued the transaction within which the event was emitted.