​
Furya Improvement Proposal Framework

​
References

​
Summary

The Furyan Council is comprised of all FURY holders who have staked either directly or via delegation, as well as the FURY tokens that are vesting on the Furya Protocol.

Note that all Furya holders can cast a vote, however their voting power will be 0 in the event they haven’t delegated or staked. Furya builders are not permitted to stake or delegate any tokens that have yet to vest, but can cast votes and have a voting power that is non zero.

Governance proposals can be submitted to the Furyan council by any FURY token holder. The entire process first requires any individual to compose a governance proposal and later publish it on the Furya forum. An on-chain governance vote is required to determine whether such a proposal may be implemented. Such a proposal must be submitted in accordance with the Furya governance protocol standards and criteria (which includes an upfront (liquid i.e. unstaked) Furya deposit requirement–see below).

Governance proposals may cover any topic related to Furya Blockchain; however, the exact nature of these proposals–and the consequences of an approval or rejection–will vary depending on the category and topic of the proposal.

The Furyan Council only has binding governance power over the configurable parameters of Furya Chain, the Furya Hub and to some extent, Furya Sovereign Chains. Both the Furya Chain and the Furya Hub are directly responsive to the governance decisions of the Furyan Council, and therefore are under the Furyan Council’s direct control. This includes control of whether, when and how to spend $Fury that remain in the community pool and the setting of caps on the Furya Hub, governance parameters such as quorum and approval thresholds, etc.

However, the Furyan Council can also express its preferences on a broader range of Furya-related topics relating to further development of the Furya Protocol, which future Sovereign Chains should be developed or deployed, Furya website feature changes, etc. As these dimensions of the Furya community are not under the direct control of the Furyan Council, the governance proposals on these topics should be regarded as signaling the Furyan Council’s preferences–i.e. governance proposals on these topics are non-binding and require the assistance of off-chain actors and processes.

In summary, there are two main categories of governance proposals:

  1. Binding proposals: Are proposals to make changes to the configurable aspects of the Furya Chain and/or the Furya Hub; because the Furyan Council controls these pieces of infrastructure, the Furyan Council’s vote is both necessary and sufficient to approve these changes.
  2. Signaling proposals: Are all other governance proposals made to the Furyan Council–for example, signaling a preference for certain code or functions to be added to Furya or the Furya blockchain website. Signaling proposals (including this proposal) are voted upon on-chain in the same way as binding proposals. However, because these proposals require off-chain implementation actions by extrinsic parties–such as a website operator, a smart contract developer, or others–the Furyan Council’s approval is neither necessary nor sufficient to cause these proposals to be implemented. Therefore, these proposals merely signal the Furyan Council’s support for or opposition to the proposed outcome.

Furthermore, there are four main governance proposal topic categories:

  1. Technical Proposals: Certain proposals for changes to certain configurable aspects of Furya Hub and/or the Furya Outposts (binding), which can be modified directly by on-chain votes, or code changes to the Furya Protocol (signaling), which require upgrading the protocol.
  2. Roto Asset Listing Proposals: Proposals to add or remove support for one or more assets within the Roto (typically binding). farming (binding or non-binding, depending on whether code is ready and deployed on chain at time of proposal).
  3. General Proposals: All other proposals impacting areas such as the treasury, governance, and tokenomics (mix of binding and non-binding).

All proposals should follow the following steps:

  1. Post a Furya Request for Comment (FRC) on the Furya Protocol Forum. Note that formal requests for comment should follow the naming convention proposed here: FRC-#: [Title of FRC]. Submitters should replace the “#” with the number of the FRC based on the order in which it was submitted and the title should match the content of the request.
  2. Submit a formalized Furya Improvement Proposal (FIP) that adheres to the specifications below for on-chain voting.
  3. If approved, the FIP will be implemented (binding FIPs) or may be implemented (signaling FIPs).

The following timeline shows the proposed flow for protocol modifications:

​
Abstract

The Furya Improvement Proposals (FIPs) Framework defines all subsequent FIPs to utilize, provides the necessary templates, processes, and guidelines for working within the framework, and defines the key roles required for the operation of the FIPs Process.

​
Motivation

For Furya to successfully operate as a fully decentralized and self-sustainable user-governed ecosystem, a formalized process of decision-making is required. In a permissionless protocol, everyone should be able to propose changes and improvements.

The FIP Framework serves to empower each member of the Furyan Council by giving them a standardized way of conducting voting regarding Furya issues.

​
Specification

​
Definitions of the Furya Improvement Proposal Framework

  • Furya Improvement Proposals (FIPs): FIPs are standardized proposals to the Furyan Council to either re-parameterise the Furya Chain or the Furya Hub or signal support for certain off-chain initiatives (such as further development of the Furya Protocol codebase). FIPs can be added, amended, replaced, and removed as required after they are initially published on the Furya Forum.
  • FIP Types: FIPs can be one of four types: Technical proposals that impact smart contract code, Roto asset listing proposals, credit line extension proposals or general proposals. General FIPs are sub-categorized as treasury, UI, governance, and tokenomics.
  • Minimum Feedback Period: The minimum amount of time within which the community can give feedback in response to a proposed FRC before it can advance to an on-chain vote and becomes known as a FIP.
  • Minimum Frozen Period: The minimum amount of time during which an FRC must remain unchanged before it can advance to an on-chain vote as a FIP.
  • FIP Editor(s): FIP Editors enforce the administrative and editorial aspects of the overall FIPs process. Note: FIP Editors’ approval is not required for a proposal to be valid–running FIPs past the editors is merely suggested as a good practice for having consistent, high-quality, community-recognized proposals.

​
Core Principles

  1. Specificity: A FIP must define and address a specific behavior or single responsibility.
  2. Completeness: A FIP must be thorough. Relevant, specific particulars must not be left undefined or unreferenced.
  3. Avoid overlap: Multiple FIPs must not implement the same type of behavior independently. For instance, there should not be two separate, interchangeable ways to integrate new apps on Furya.
  4. Clarity: A FIP must not have equally valid conflicting interpretations. A FIP must be as clear and easy to understand as possible.
  5. Brevity: A FIP must be as short as possible, including only what is essential given the other core principles.

​
FIP Proposal Type Categories

There are two main categories of Furyan Council governance proposals:

  1. Binding proposals: Are proposals to make changes to the configurable aspects of the Furya Chain; because the Furyan Council controls this code, the Furyan Council’s vote is both necessary and sufficient to approve these changes.
  2. Signaling proposals: Are all other governance proposals made to the Furyan Council–for example, signaling a preference for certain code or functions to be added to Furya. Signaling proposals (including this proposal) are voted upon on-chain in the same way as binding proposals. However, because these proposals require off-chain implementation actions by extrinsic parties–such as a website operator, a smart contract developer, or others–the Furyan Council’s approval is neither necessary nor sufficient to cause these proposals to be implemented. Therefore, these proposals merely signal the Furyan Council’s support for or opposition to the proposed outcome.

​
FIP Topic Categories Categories

There are four potential categories for FIPs:

  • Technical FIPs
  • Roto Asset Listing FIPs
  • General FIPs

Each category has specific considerations and requirements as detailed below.

Technical FIPs

Certain proposals for changes to certain configurable aspects of the Furya Blockchain, which can be modified directly by on-chain votes, or code changes to the Furya Protocol (signaling), which require upgrading the protocol. Technical FIPs should be formatted per the Technical FIP Template.

Roto Asset Listing FIPs

Proposals to add support for one or more new assets within the Roto Protocol. Proposals should meet the specifications in the Furya Risk Framework and should be formatted as per the Roto Asset Listing FIP Template.

General FIPs

A general category for proposals that do not fall under the above categories. General proposals can be sub-categorized in accordance with their various topics and should be formatted per the General FIP Template.

​
The FIP Lifecycle

​
FIP Lifecycle Breakdown

  1. Conception: A FIP Author posts a FRC proposal on the Furya Chain forum under the appropriate category. From this point on, FIP Editors will be available to assist the FIP Author.
  2. **Approved by FIP Editor(s):**A FIP Editor verifies that the posted FRC proposal:
  • Follows the appropriate format of the FIP Template for its type.
  • Is either an original FIP or a replacement for an older FIP.
  • Has been submitted to the FIP GitHub repository with a Pull Request by either the FIP Author or a FIP Editor.
  1. If the verification is successful, the FIP Editor:
  • Approves the FIP and assigns it a formal FIP number.
  • Merges in the PR.
  • Furya Request for Comments (FRC): A period of reviewing by the community and attendant redrafting begins. The minimum duration of this period is determined by two variables:
    • Feedback Period: 5 days.
    • Frozen Period: 2 days.

Please note that in the case of UI MRCs, there is no need for a Frozen Period.

  1. Fulfilled Feedback Period Requirements: After the FIP has fulfilled the FRC phase, it is ready for on-chain submission.
  2. On-Chain Submission: At this point, the FIP Author has two options: submit an on-chain FIP vote referencing the associated FRC and then notify the Furya community on the forum or request help from a FIP Editor to submit the on-chain vote. Proposals can only be submitted via the CLI using the Furya Daemon Furyaprotocol.io.
  3. Accepted/Rejected: The FIP is voted on and users may opt for either of the four options i) Yes ii) No iii) Veto iv) Abstain. In the event 33.40% of the votes are for option iii) ‘Veto’, then the proposal is vetoed and the deposit is donated to the community pool. In the event the proposal passes the voting threshold, If it passes, it is officially accepted and is given the Accepted status. If not, the FIP is rejected.

​
On-Chain Submission

The following steps must be completed to submit a proposal on chain and take it to a vote.

On-chain Submission

​
Resubmission

A FIP can be resubmitted for an on-chain vote up to 3 times without having to go through phases 1-4 again if it failed to pass due to legitimate external reasons (e.g., potential low governance participation that did not meet the minimum on-chain quorum)

​
Other FIP Statuses

  • Withdrawn: Assigned when an FIP Author withdraws their FIP proposal. A FIP may be withdrawn at any point before it enters an on-chain vote. Note that a withdrawn proposal can be taken over from the original Author with a simple transition facilitated by a FIP Editor and the respective parties. If the original FIP Author ceases to be available, a FIP Editor may proceed with the transfer of authorship.
  • Deferred: Assigned when a proposal has been deemed as not ready or not a priority but can be re-proposed at a later date. This status can be assigned during FRC or by a rejecting forum poll.
  • Obsolete: Assigned when:
    • A FIP has been superseded or deprecated.
    • A FIP has been deferred for over six months.
    • A FIP Author has abandoned the proposal and no person has communicated willingness to take over the responsibility of an FIP Author.

​
FIP Status Change Process

If a FIP Author requests a status change for a FIP, a FIP Editor will review it. If the status change is warranted, the FIP Editor will change the status. Otherwise, the FIP Editor will revert and highlight issues for the FIP Author to fix before requesting another status change.

​
FIP Replacement Process

A FIP can define one or more replacement targets in its preamble. If the FIP is given the Accepted status, the replacement target(s) FIPs receive the Obsolete status and effectively become inactive. The replaced FIP will record the number of the FIP that replaced it. FIPs that depend on the replaced FIP will instead interact with the new FIP.

Since dependencies carry over, a FIP with defined replacement target must strictly adhere to dependency requirements and interface correctly with FIPs that depend on the replaced FIP.

​
Supporting Materials

FIPs can optionally refer to external materials. External materials must be added to the FIPs GitHub in the same folder as the FIP which references them.

Externally referenced materials are not FIP content and are not ratified when a FIP becomes Accepted unless it is explicitly stated otherwise in an FIP Component specification.

​
FIP Templates

​
Technical FIP Template

  • The Technical FIP Template should be used for FIPs for changes to certain configurable aspects of Furya Hub and the Furya Outposts (binding), which can be modified directly by on-chain votes, or code changes to the Furya Protocol (signaling), which require upgrading the protocol.
  • The Technical FIP Template is located at https://github.com/furya-network/fips/blob/main/Technical-FIP-Template.md.

​
Roto Asset Listing FIP Template

​
General FIP Template

​
FIP Editors

The FIP Framework depends on FIP Editors.

​
FIP Editor

FIP Editors enforce the administrative and editorial aspects of the overall FIPs process and program.

Specific authority of the FIP Editor(s) in FIP0 processes

  • FIP Editors control phase 2 of the FIP lifecycle and can assign FIP numbers.
  • FIP Editors are admins on the FIPs GitHub repository.
  • FIP Editors moderate the relevant MRCs categories in the forum.
  • FIP Editors are responsible for updating the status of FIPs.

​
Editor Responsibilities

A FIP Editor’s responsibilities include:

  • Providing feedback in the FIP sections of the Furya Forum.
  • Assign formal number labels to FIPs.
  • Make sure that titles, FIP statuses, category placements all track the actual FIPs.
  • Confirm there is a (real) dedicated FIP author, coordinator, funder and/or sponsor, etc.
  • Correspond with FIP authors/coordinators.
  • Review FIPs for obvious defects in the language.
  • Make sure that FIPs follow the style guide (template).
  • Work and communicate with FIP authors to help them submit an FRC for on-chain voting as a FIP.

FIP Editors can correct issues themselves, but they are not required to.

Disclaimers/Disclosures

This proposal is being made by Fantasy Terra LLC, a US company. Fantasy Terra engages in incubation, investment, research and development relevant to multiple ecosystems and protocols, including the Furya Protocol. Fantasy Terra and certain of its service providers and equity holders own Furya tokens and have financial interests related to this proposal. Additionally, Fantasy Terra is one of several entities associated with one another under the “Furya” brand. Fantasy Terra’s associated entities and/or equityholders or service providers of such entities may hold Furya and may have financial interests related to this proposal. All such entities, service providers, equity holders and other related persons may also have financial interests in complementary or competing projects or ecosystems, entities or tokens, including Kujira/KUJI. These statements are intended to disclose relevant facts and to help identify potential conflicts of interest, and should not be misconstrued as a complete description of all relevant interests or conflicts of interests; nor should they be construed as a recommendation to purchase or acquire any token or security.

This proposal is also subject to and qualified by the Furya Disclaimers/Disclosures. Fantasy Terra may lack access to all relevant facts or may have failed to give appropriate weighting to available facts. Fantasy Terra is not making any representation, warranty or guarantee regarding the accuracy or completeness of the statements herein, and Fantasy Terra shall have no liability in the event of losses or damages ensuing from approval or rejection or other handling of the proposal. Each user and voter should undertake their own research and make their own independent interpretation and analysis of all relevant facts and issues to arrive at their own personal determinations of how to vote on the proposal.

Copyright and related rights waived via CC0 1.

Was this page helpful?

GovernanceOn-chain submission