Risk

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

See also Security and Audits.

Smart contract dangers

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

Project owner risk

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

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

Limiting distribution and dividing payouts

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

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

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

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

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

Establishing an overflow reserve

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

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

🟢This may be used effectively to control discretionary expenditure.

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

Allowing token production

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

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

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

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

Setting the weight of the financing cycle

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

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

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

Permitting the exchange of project tokens

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

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

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

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

Halt payments, pause distributions, pause redemptions, pause burn

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

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

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

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

Customized treasury add-ons

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

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

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

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

Add or subtract payment terminals

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

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

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

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

Configuring the controller

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

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

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

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

Transferring money between terminals

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

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

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

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

Undistributed risk of reserve rate

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

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

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

Price oracle risk

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

Large number risk

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