Background

Today a FIO Address is valid for a period of 1 year from registration. If not renewed it gets burned 90 days later. This can be problematic for a few reasons:

• It’s up to the integrating wallet to notify the user to renew, which may be challenging for wallets which do not collect contact information from their users.

• Users may not be using their wallets often enough to notice the need to renew.

• As discovered in a recent Usability Study some users will abandon FIO Protocol if they have to pay an annual fee or due to the fear that expiring FIO Address may compromise their security (someone else re-registers).

• As of 6/25/2021 only 316 FIO Address renewal calls have been executed.

FIO Protocol already includes the notion of bundled transactions. Every FIO Address comes with 100 bundled transactions which are used up when the user uses the protocol. They have to purchase new bundles at a rate that is reflective of their usage rather than time.

Via FIP-28 burning of FIO Addresses has been changed from 90 days after expiration to 365 days, which means FIO Addresses will start being burned in March of 2022, if no changes are made.

Elimination of FIO Address expiration or burning

Option 1 - Selected for FIP

This proposal is to eliminate the notion of expiration date for FIO Addresses altogether. FIO Addresses will never expire and will be owned by the owner permanently until transferred, voluntarily burned, or burned due to expiring domain.

• There will still be a fee to register a FIO Address for the first time.

• User will still need to purchase bundled transactions or pay-per-call to continue to call actions on the FIO Address, such as add_pub_address.

• There will still be a fee to register and renew a FIO Domain.

• The FIO Address will still be burned once its FIO Domain is burned.

Option 2

This proposal is to eliminate burning of FIO Addresses permanently, but retaining the notion of expiration date.

• FIO Addresses will still expire and will have limited functionality until renewed, but would never be burned.

• FIO Addresses will be owned by the owner permanently until transferred, voluntarily burned, or burned due to expiring domain.

• Burning of content associated with the FIO Address in state, should be considered as part of https://fioprotocol.atlassian.net/browse/WP-119

Initiative link

https://fioprotocol.atlassian.net/browse/WP-402

2021-07-02 discussion call

During a call on Jul 2, 2021 with the Steering Committee:

• It was decided to create a FIP with Option 1 and gather community feedback. Rationale:

  • Makes user experience much better as users doesn’t have to worry about expiring addresses.

  • Best aligns with the strategy of aggressively growing user base.

  • It’s akin to the Fremium model used by many SAAS companies which offers basic features (FIO Address and send using FIO Address) available for free while charging for more advance features (changing mappings, FIO Requests, FIO Data, FIO Domains).

• It was acknowledged that elimination of renewal fees on FIO Addresses may reduce income to the chain, but it is also believed that improved user experience would grow the user base faster and therefore increased income from other fees may offset that reduction. If it doesn’t:

  • In the future BPs may elect to charge fees for hosting API nodes

  • https://fioprotocol.atlassian.net/browse/WP-119 may remove significant amount of content from state anyway which would reduce hosting fees.

• In the future the following may also be considered:

  • Staking for bundled transactions. A user could stake tokens and elect rewards to be redirected to “buy” new bundled transactions making FIO Address free even for more advance use.

2021-05-17 discussion call

During a call on May 17, 2021 with the Steering Committee:

• Discussed:

  • A need to communicate expiration dates with users via:

    • Improved wallet integrations

    • FIP-24

  • We may not yet have adequate information to come up with ideal solution.

  • Security risk of other re-registering expired FIO Address is a concern.

  • A desired approach may be to:

    • Never expire FIO Address itself, but burn any content once it expires

    • Consider using bundled transactions to extend validity of the FIO Address

  • It was discovered that after expiration date, get_pub_address does not return mappings, which was not intended during design. KB was updated.

• Decided:

  • A new FIP will be proposed to change the time after which the FIO Address is burned from 90 days to 365 days

  • Work will continue on this initiative to identify a desired solution.