FIPs describe proposed changes to the FIO Protocol.
| 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 | Final |
| FIP-17b | FIO Domain Wrapping | Final |
| 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 | Final |
| FIP-37 | Lift limit on number of FIO Public Keys in account's permissions | Final |
| FIP-38 | Add ability to create FIO Chain Account | Final |
| FIP-39 | Support alternate FIO Public Key for encryption of New Funds Request/Record OBT content blob | Final |
| FIP-40 | Enable specified accounts to register FIO Addresses on private FIO Domains | Final |
| FIP-41 | Enable token locking to existing accounts | Final |
| FIP-42 | Enable FIO Address and Domain registration in a single transaction | Final |
| FIP-43 | Made FIO Address optional for actions which do not require a FIO Address | Final |
| FIP-44 | Allow FIO Domains to be mapped to DNS record | Draft |
| FIP-45 | Set price of FIO Domain registration and renewal based on length | Draft |
| FIP-46 | Update Chain Plugin to increase get_table_rows timeout | Final |
| FIP-47 | Allow FIO Block Producers to update their information | Final |
Everyone is encouraged to review existing FIPs and provide feedback.
- 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.
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.
- Core - improvements requiring a consensus fork
- Functionality - adds or modifies functionality without need for consensus fork
- Standard - documents standards used in FIO Protocol
- 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.
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
---
A short (~200 word) description of the technical issue being addressed.
An explanation of why the existing protocol specification is inadequate to address the problem that the FIP solves.
Detailed definition of what is being changed, e.g. actions, API end-points, processing logic, exception handling, fees, etc.
The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made.
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.
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.
This section may include proposals for how the new functionality could be enhanced in the future.
Provide a link(s) to where this FIP is being discussed.