Skip to content

fioprotocol/fips

master
Switch branches/tags
Code

Latest commit

 

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

FIO Improvements Proposals (FIPs)

FIPs describe proposed changes to the FIO Protocol.

FIPs

FIP Title Status
FIP-1 FIO Domain/FIO Address transfer and data purge Final
FIP-2 Improvements to paging via API Final
FIP-3 Provide ability to cancel a request for funds Final
FIP-4 Provide ability to remove pub address from the FIO protocol for a user Final
FIP-5 Enhanced privacy Draft
FIP-6 Transfer locked tokens Final
FIP-7 Provide ability to burn FIO Address Final
FIP-8 Public Address Request Draft
FIP-9 Allow voting and proxying without a FIO Address Final
FIP-10 Redesign Fee Computations Final
FIP-11 Add ability to purchase bundled transactions Final
FIP-12 Move action whitelisting into state Final
FIP-13 Ability to retrive all public addresses for a FIO Address Final
FIP-14 Ensuring API response data integrity Draft
FIP-15 Chain and token code standard Final
FIP-16 CLIO Enhancements Final
FIP-17a FIO Token Wrapping Accepted
FIP-17b FIO Domain Wrapping Accepted
FIP-18 Chain-level public address Final
FIP-19 Add ability to retrieve all received FIO Requests Final
FIP-20 FIO Co-op Deferred
FIP-21 FIO Staking Final
FIP-22 Retire FIO Tokens Final
FIP-23 Temporary adjustment of Block Producers Reserves Final
FIP-24 Secure messsage standard Draft
FIP-25 Return bundle transaction count in get_fio_names Final
FIP-26 FIO Domain Marketplace Final
FIP-27 NFT Signatures Final
FIP-28 Delay FIO Address burning after expiration Final
FIP-29 Temporarily disable Transfer of locked tokens Deferred
FIP-30 pNetwork Support Deferred
FIP-31 Eliminate FIO Address Expiration Final
FIP-32 Allow unlimited size of content parameter in New Funds Request Final
FIP-33 Allow $ in token codes Final
FIP-34 Allow unlimited size of content parameter in Record OBT Data Final
FIP-35 Increase max size of token_id in addnft Final
FIP-36 Add ability to fetch FIO Public Key for an account Accepted
FIP-37 Lift limit on number of FIO Public Keys in account's permissions Accepted
FIP-38 Add ability to create FIO Chain Account Accepted
FIP-39 Support alternate FIO Public Key for encryption of New Funds Request/Record OBT content blob Accepted
FIP-40 Enable specified accounts to register FIO Addresses on private FIO Domains Accepted
FIP-41 Enable token locking to existing accounts Accepted
FIP-42 Enable FIO Address and Domain registration in a single transaction Accepted
FIP-43 Made FIO Address optional for actions which do not require a FIO Address Accepted

Contributing

Review FIPs

Everyone is encouraged to review existing FIPs and provide feedback.

New FIP Process

  • If you're not yet sure if your idea should a FIP, start by opening a Github issue and create your FIP draft there first to ask for feedback from the community.
  • To propose a FIP, fork this repository and create a pull request for your FIP with status Draft. The FIP number can remain undetermined at this stage. Use the fip-TEMPLATE.md file as your starting point and see Successful FIP includes for what a FIP should contain. Also, use existing FIPs as examples.
  • Repo custodians will review the FIP PR and comment. Once comments have been addressed, the FIP will be merged to Master with the status Draft.
  • Reach out to the community and solicit feedback on your FIP.
  • Continue to update your FIP based on community feedback and submit pull requests as needed. Once you feel the community has contributed and the FIP is ready, creare a pull request to update the status to Accepted.
  • Once repo custodians accept your FIP, you can code your solution and submit pull requests to the relevant repo.
  • After the code has been merged and deployed to Mainnet, the status will be changed to Final.

Discussing a FIP

Create an issue describing the FIP or section of a FIP you would like to open up for discussion. Assign it to the author of that FIP.

FIP Type

  • Core - improvements requiring a consensus fork
  • Functionality - adds or modifies functionality without need for consensus fork
  • Standard - documents standards used in FIO Protocol

FIP Status

  • Draft - a FIP that is open for consideration.
  • Accepted - a FIP that is planned for immediate adoption. Changes may still be made as required by development.
  • Final - a FIP that has been adopted, coded, merged, and deployed by the block producers on FIO mainnet.
  • Deferred - a FIP that is not being considered for immediate adoption. May be reconsidered in the future.

Successful FIP includes

Preamble

Each FIP must begin with an RFC 822 style header preamble, preceded and followed by three hyphens (---). This header is also termed “front matter” by Jekyll. The headers must appear in the following order. All other headers are required.

---
fip: FIP number
title: FIP title
status: FIP status
type: FIP type
author: a list of the author’s or authors’ name(s) and/or username(s), or name(s) and email(s)
created: FIP create date
updated: FIP update date
---

Abstract

A short (~200 word) description of the technical issue being addressed.

Motivation

An explanation of why the existing protocol specification is inadequate to address the problem that the FIP solves.

Specification

Detailed definition of what is being changed, e.g. actions, API end-points, processing logic, exception handling, fees, etc.

Rationale

The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made.

Implementation

Initially this section should include technical implementation strategy, such how this change made (contracts, core, etc.), how will the specification be accomplished in code, how will the code be tested/deployed. Before development beings, create a master ticket in the fio repo to track progress on development towards this FIP.

Backwards Compatibility

All FIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The FIP must explain how the author proposes to deal with these incompatibilities.

Future considerations

This section may include proposals for how the new functionality could be enhanced in the future.

Discussion link

Provide a link(s) to where this FIP is being discussed.

About

FIO Improvements Proposals

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published