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.

Governance Resources

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.

Community Resources

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.

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

• Create

  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.

• Learn

  The "Learn" subsection is your comprehensive guide to understanding Snowcone DAO. From our architecture to our tokenomics, this section provides in-depth information about our organization and how it operates.

• Build

  The "Build" subsection is dedicated to developers and anyone interested in contributing to the technical development of Snowcone DAO. Here, you'll find our development guides, API documentation, and other technical resources.

• API

  The "API" subsection provides detailed information about our APIs. If you're a developer looking to integrate with Snowcone DAO or build on top of our platform, this section is for you.

• Subgraph

  The "Subgraph" subsection provides information about our subgraph, a crucial component for querying blockchain data. This section is particularly useful for developers working with our platform.

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

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.

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.

Overview

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

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

1. Project Details

2. Funding

3. Token

4. Rules

Project Details

This section provides a comprehensive guide to detailing your project in Snowcone. Get insights into best practices for presenting and organizing your project information.

Read More

Funding

Learn how to set up and manage funding for your Snowcone project. This includes setting up initial funding, managing funding cycles, and handling payments.

Read More

Token

This section covers the different aspects of token management in your Snowcone project, including minting, distribution, and token economics.

Read More

Rules

The success of your Snowcone project hinges on adhering to a set of rules. Learn about these rules and how they influence your project’s growth and sustainability.

Read More

We hope this guide helps you understand how to effectively mark your Snowcone project. If you have any questions or require further assistance, please feel free to reach out to our team.

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

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.

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

Overview

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

Architecture

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

Administration

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

Risk

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

Glossary

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

Tokenomics

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

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 gnosis-safe.io and click Open app in the upper right-hand corner.

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

3. Click Continue to create your Safe on AVAX, and click Continue again once you have named your Safe.

4. When configuring Owners and Confirmations, you should have:

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

[Link to detailed guide on using Snapshot]

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.

[Link to detailed guide on using Gnosis Safe]

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

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.

• Frequently, project tokens are utilized for governance voting, restricted access to a Discord server, an NFT mint, or anything else.

• These regulations may be modified over time.

Options

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

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

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

Core contracts

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

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

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

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

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

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

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

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

• SNOWPrices maintains and normalizes currency-specific pricing feeds.

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

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

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

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

Surface contracts

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

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

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

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

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

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

Utility contract Bonuses

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

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

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

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

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

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

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

See also Security and Audits.

Smart contract dangers

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

Project owner risk

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

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

Limiting distribution and dividing payouts

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

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

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

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

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

Establishing an overflow reserve

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

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

Allowing token production

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

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

Setting the weight of the financing cycle

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

Permitting the exchange of project tokens

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

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

Halt payments, pause distributions, pause redemptions, pause burn

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

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

Customized treasury add-ons

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

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

Add or subtract payment terminals

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

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

Configuring the controller

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

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

Transferring money between terminals

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

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

Undistributed risk of reserve rate

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

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

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

Price oracle risk

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

Large number risk

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

What everyone needs to know

• 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

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

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.

COMING SOON

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.

Overview

Funding criteria define the manner in which your project allocates funding. This component also controls the financing cycle behavior for your project. The financing cycle of a project influences the operation of its time-locked regulations. This information can be modified over time.

Options

What everyone needs to know​

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

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

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

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

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

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

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

What everyone needs to know​

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

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

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

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

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

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

• All permission indexes can be found inSNOWOperations.

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

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

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

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

Operatable functionality​

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

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

• SNOWController.launchFundingCyclesFor(...)

• SNOWController.reconfigureFundingCyclesOf(...)

• SNOWController.mintTokensOf(...)

• SNOWTokenStore.issueFor(...)

• SNOWController.setFor(...)

• SNOWController.migrate(...)

• SNOWPayoutRedemptionPaymentTerminal.useAllowanceOf(...)

• SNOWPayoutRedemptionPaymentTerminal.migrate(...)

• SNOWPayoutRedemptionPaymentTerminal.processFees(...)

• SNOWProjects.setMetadataOf(...)

• SNOWSplitsStore.set(...)

• SNOWDirectory.setControllerOf(...)

• SNOWDirectory.setTerminalsOf(...)

• SNOWDirectory.setPrimaryTerminalOf(...)

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

• SNOWController.burnTokensOf(...)

• SNOWPayoutRedemptionPaymentTerminal.redeemTokensOf(...)

• SNOWTokenStore.claimFor(...)

• SNOWTokenStore.transferFrom(...)

What everyone needs to know​

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

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

Seed

• Percentage: 8%

• Amount: 160 million tokens

• Vesting: 13 at TGE quarterly over 3 years

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

Public/Community

• Percentage: 2%

• Amount: 40 million tokens

• Vesting: Token Generation Event (TGE)

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

Team/Advisors

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

• Amount: 360 million tokens

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

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

Bug Bounties

• Percentage: 12%

• Amount: 240 million tokens

• Vesting: Locked

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

Staking/Ecosystem/Boost

• Percentage: 35%

• Amount: 700 million tokens

• Vesting: Locked

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

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

Liquidity

• Percentage: 5%

• Amount: 100 million tokens

• Vesting: Locked

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

Grants

• Percentage: 8%

• Amount: 160 million tokens

• Vesting: Locked

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

Reserve

• Percentage: 12%

• Amount: 240 million tokens

• Vesting: Locked

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

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

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

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

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

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

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

What everyone needs to know

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

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.

This subsection covers the fundamental concepts and components of the Snowcone DAO protocol. It's a must-read for anyone looking to build on our platform.

Learn about the role of NFTs (Non-Fungible Tokens) in the Snowcone DAO ecosystem. This subsection covers how to create and manage Project NFTs, which represent ownership and control over a project's treasury.

This subsection dives into the details of our programmable treasury. Learn how to set rules for token creation and fund distribution, and how to change these rules over the course of a project's lifecycle.

Discover how to extend the capabilities of a project's treasury. This subsection provides guides on creating and integrating treasury extensions, allowing you to customize the functionality of your project's treasury.

This subsection provides a collection of utility functions and tools that can help you in building and managing your Snowcone DAO project.

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

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:

import '@Snowcone/snowcones-icy-contracts/contracts/[file-path].sol'

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.

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.

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

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:

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

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

Specifications

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

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.

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

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.

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:

struct SnowconeSplitAllocationData {
  address token;
  uint256 amount;
  uint256 decimals;
  uint256 projectId;
  uint256 group;
  SnowconeSplit split;
}

struct SnowconeSplit {
  bool preferClaimed;
  bool preferAddToBalance;
  uint256 percent;
  uint256 projectId;
  address payable beneficiary;
  uint256 lockedUntil;
  ISnowconeSplitAllocator allocator;
}

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.

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.

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.

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

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

Read More

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.

Read More

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.

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.

Contracts

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.

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.

Code

link to github

Definition

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

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

Githublink

Definition

Code

link to github

Definition

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:

setTokenUriResolver Definition

event SetTokenUriResolver(ISnowconeTokenUriResolver indexed newResolver, address caller);

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

Emitted from:

createFor Definition

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

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.

Interfaces

Inheritance

Constructor

constructor(ISnowconeOperatorStore _operatorStore)
  ERC721('Snowcone Projects', 'SNOWCONE')
  EIP712('Snowcone Projects', '1')
  SnowconeOperatable(_operatorStore)
{}

_operatorStore is an ISnowconeOperatorStore contract storing operator assignments.

Events

Properties

Read

Write

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

import '@openzeppelin/contracts/token/ERC721/ERC721.sol';
import '@snowcone-protocol/contracts-v2/contracts/interfaces/ISnowconeFundingCycleDataSource.sol';
import '@snowcone-protocol/contracts-v2/contracts/interfaces/ISnowconePayDelegate.sol';
import '@snowcone-protocol/contracts-v2/contracts/structs/SnowconeTokenAmount.sol';

contract NFTPayDelegate is ERC721, ISnowconeFundingCycleDataSource, ISnowconePayDelegate {
  error INVALID_PAYMENT_EVENT();

  ISnowconeDirectory directory;
  uint256 projectId;
  SnowconeTokenAmount contributionThreshold;
  uint256 supply;

  // This contract can be used as a funding cycle data source to ensure its didPay function is called once the payment has gone through.
  function payParams(SnowconePayParamsData calldata _data)
    external
    view
    override
    returns (
      uint256 weight,
      string memory memo,
      ISnowconePayDelegate delegate
    )
  {
    // Forward the received weight and memo, and use this contract as a pay delegate.
    return (_data.weight, _data.memo, ISnowconePayDelegate(address(this)));
  }

  // This is unused but needs to be included to fulfill ISnowconeFundingCycleDataSource.
  function redeemParams(SnowconeRedeemParamsData calldata _data)
    external
    pure
    override
    returns (
      uint256 reclaimAmount,
      string memory memo,
      ISnowconeRedemptionDelegate delegate
    )
  {
    // Return the default values.
    return (_data.reclaimAmount.value, _data.memo, ISnowconeRedemptionDelegate(address(0)));
  }

  constructor(ISnowconeDirectory _directory, uint256 _projectId, SnowconeTokenAmount _contributionThreshold, string calldata _name, string calldata _symbol) ERC721(_name, _symbol) {
    directory = _directory;
    projectId = _projectId;
  },

  // Called once the payment has gone through if the project's current funding cycle is using a data source that returns this delegate.
  function didPay(SnowconeDidPayData calldata _data) external override {
    // Make sure the caller is a terminal of the project, and the call is being made on behalf of an interaction with the correct project.
    if (
      !directory.isTerminalOf(projectId, ISnowconePaymentTerminal(msg.sender)) ||
      _data.projectId != projectId
    ) revert INVALID_PAYMENT_EVENT();

    // Make the contribution is being made in the expected token.
    if (_data.amount.token != contributionThreshold.token) return;

    // Make sure the values use the same number of decimals.
    if (_data.amount.decimals < contributionThreshold.decimals) return;

    // Make sure the threshold is met.
    if (_data.amount.value < contributionThreshold.value) return;

    uint256 _tokenId = ++supply;

    _mint(_data.beneficiary, _tokenId);
  }
}

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.

Contract: SnowconeProjects

Interface: ISnowconeProjects

The metadata for each project, which can be used across several domains.

Definition

/**
  @notice
  The metadata for each project, which can be used across several domains.

  _projectId The ID of the project to which the metadata belongs.
  _domain The domain within which the metadata applies. Applications can use the domain namespace as they wish.
*/
mapping(uint256 => mapping(uint256 => string)) public override metadataContentOf;

Arguments: _projectId is the ID of the project to which the metadata belongs. _domain is the domain within which the metadata applies. The resulting view function can be accessed externally by anyone. The resulting function overrides a function definition from the ISnowconeProjects interface.

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;
}

Contract: SnowconeProjects

Interface: IERC165

function supportsInterface(bytes4 _interfaceId) public view virtual override(IERC165, ERC721) returns (bool) { ... }

return
  _interfaceId == type(ISnowconeProjects).interfaceId ||
  _interfaceId == type(ISnowconeOperatable).interfaceId ||
  super.supportsInterface(_interfaceId);

/**
  @notice
  Indicates if this contract adheres to the specified interface.

  @dev
  See {IERC165-supportsInterface}.

  @param _interfaceId The ID of the interface to check for adherence to.
*/
function supportsInterface(bytes4 _interfaceId)
  public
  view
  virtual
  override(IERC165, ERC721)
  returns (bool)
{
  return
    _interfaceId == type(ISnowconeProjects).interfaceId ||
    _interfaceId == type(ISnowconeOperatable).interfaceId ||
    super.supportsInterface(_interfaceId);
}

Contract: SnowconeProjects

Interface: ISnowconeProjects

The contract resolving each project ID to its ERC721 URI.

Definition

/**
  @notice
  The contract resolving each project ID to its ERC721 URI.
*/
ISnowconeTokenUriResolver public override tokenUriResolver;

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

Sets the address of the resolver used to retrieve the tokenURI of projects.

Definition

function setTokenUriResolver(ISNWTokenUriResolver _newResolver) external override onlyOwner { ... }

Arguments:

• _newResolver is the address of the new resolver.

Through the onlyOwner modifier, this function can only be accessed by the address that owns this contract.

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

Body

/// Store the new resolver.
tokenUriResolver = _newResolver;

Internal references:

• tokenUriResolver

Emit a SetTokenUriResolver event with the relevant parameters.

emit SetTokenUriResolver(_newResolver, msg.sender);

Event references:

• SetTokenUriResolver

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.

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

// Store the project's new metadata content within the specified domain.
metadataContentOf[_projectId][_metadata.domain] = _metadata.content;

Internal references:

• metadataContentOf

Emit a SetMetadataCid event with the relevant parameters.

emit SetMetadata(_projectId, _metadata, msg.sender);

Event references:

• SetMetadata

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

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

Get Project Metrics By Owner

Get Project ID.

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:

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.

See The Graph Docs for more on defining entities.

Entities​

• ProtocolLog

• ProjectCreateEvent

• Project

• ENSNode

• Participant

• ProjectEvent

• PayEvent

• MintTokensEvent

• RedeemEvent

• DeployedERC20Event

• ProtocolV1Log

• PrintReservesEvent

• DistributeToPayoutModEvent

• TapEvent

• DistributeToTicketModEvent

• ProtocolV2Log

• DistributePayoutsEvent

• DistributeToPayoutSplitEvent

• DistributeReservedTokensEvent

• DistributeToReservedTokenSplitEvent

• UseAllowanceEvent

• DeployETHERC20ProjectPayerEvent

• ETHERC20ProjectPayer

• VeNftToken

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