Skip to content

Releases: fioprotocol/fio.contracts

Release Candidate - FIO Contracts v2.5.0-rc2

06 Oct 20:06
0c5d52c
Compare
Choose a tag to compare

Enhancements and Updates

(#146) FIP-27 NFT Signatures. Extends FIO Protocol to enable NFTs to be mapped to a FIO Address. It will allow anyone to see which FIO Address has mapped ("signed") a particular NFT and if it is a FIO Address they trust, they can also trust the NFT.

(#177) FIP-31 Eliminate FIO Address Expiration. Eliminates the concept of expiration of FIO Addresses. FIO Addresses will now be valid and functional indefinitely and will never be burned. Users will still need to purchase bundled transactions or pay-per-call to continue to call actions on the FIO Address.

(#183) burnnfts admin endpoint. Enables the burning of large numbers of NFTs. When a FIO Address is burned, it is added to a queue. burnnfts accesses this queue to determine which NFTs to burn. While this call can be made by any user, it is expected that FIO block producers will regularly call it to ensure the NFT burn queue remains empty.

Bug Fixes

(#174) Burnexpired not burning expired domains. Fixes bug that was preventing burnexpired from burning domains when there were large blocks of expired and non-expired domains.

(#192) Removal of binary extensions from the fio.address contract.

Release Candidate - FIO Contracts v2.5.0-rc1

29 Sep 15:58
bf17af3
Compare
Choose a tag to compare

Enhancements and Updates

(#146) FIP-27 NFT Signatures. Extends FIO Protocol to enable NFTs to be mapped to a FIO Address. It will allow anyone to see which FIO Address has mapped ("signed") a particular NFT and if it is a FIO Address they trust, they can also trust the NFT.

(#177) FIP-31 Eliminate FIO Address Expiration. Eliminates the concept of expiration of FIO Addresses. FIO Addresses will now be valid and functional indefinitely and will never be burned. Users will still need to purchase bundled transactions or pay-per-call to continue to call actions on the FIO Address.

(#183) burnnfts admin endpoint. Enables the burning of large numbers of NFTs. When a FIO Address is burned, it is added to a queue. burnnfts accesses this queue to determine which NFTs to burn. While this call can be made by any user, it is expected that FIO block producers will regularly call it to ensure the NFT burn queue remains empty.

Bug Fixes

(#174) Burnexpired not burning expired domains. Fixes bug that was preventing burnexpired from burning domains when there were large blocks of expired and non-expired domains.

Release - FIO Contracts v2.4.1

19 Jul 16:40
67b6866
Compare
Choose a tag to compare

Bug Fix

(#149) Fixes issue with voting power after unlock period 3 for Type 1 Genesis locks. The voting power logic was returning account balance instead of remaining locked balance.

Release Candidate - FIO Contracts v2.4.1-rc1

12 Jul 15:10
60f65f6
Compare
Choose a tag to compare

Bug Fix

(#149) Fixes issue with voting power after unlock period 3 for Type 1 Genesis locks. The voting power logic was returning account balance instead of remaining locked balance.

Release - FIO Contracts v2.4.0

29 Jun 17:41
2df2d15
Compare
Choose a tag to compare

(#112) Adds functionality of removing old data from the request and obt index tables. Top block producers can call migrtrx and remove up to 25 records during a single transaction. Added functionality also allows for the API endpoints use of the new data structure introduced in step 1.

(#74) FIP-1.b Allow for xferaddress to be called for all registered and non-expired FIO Addresses, including accounts with OBT Records and FIO Requests.

Release Candidate - FIO Contracts v2.4.0-rc1

15 Jun 21:45
5634ce5
Compare
Choose a tag to compare

(#112) Adds functionality of removing old data from the request and obt index tables. Top block producers can call migrtrx and remove up to 25 records during a single transaction. Added functionality also allows for the API endpoints use of the new data structure introduced in step 1.

(#74) FIP-1.b Allow for xferaddress to be called for all registered and non-expired FIO Addresses, including accounts with OBT Records and FIO Requests.

Release - FIO Contracts v2.3.5

27 May 20:48
0295e80
Compare
Choose a tag to compare

(#142) This PR increases the delay of FIO Address burning after their expiration.

Bug Fix

(#142) Change to the timestamp on rejected and canceled requests when modifying the new transaction table. This will fix a bug that was going to require another round of status migrations prior to the deletion of old records.

(#132) Fixes multiple issues related to the migration of request and obt records, including:

  • Iteration bug causing mainnet to timeout due to large gaps in status updates needing to be migrated.
  • Status timestamps were originally stored incorrectly. This caused trailing 0s that needed to be removed.
  • req_timestamp data needed to be transferred to obt_timestamp on statuses with obt_action
  • req_content data needed to be transferred to obt_contenton statuses with obt_action
  • Corrections to recordobt to store these values in the future correctly.

(#134 ) Scope migration iteration into smaller sets for more optimized indexing

  • This is a series of optimizations that will benefit the migration process for large data sets where iteration limits might cause timeouts.

Local Build notes

⚠️ This contract release should not be used for testing in local development environments as the contract requires data to be present in both the initial Request tables and the new Request table.

Release Candidate - FIO Contracts v2.3.5-rc1

24 May 20:14
83b0c3c
Compare
Choose a tag to compare

(#142) This PR increases the delay of FIO Address burning after their expiration.

Bug Fix

(#142) Change to the timestamp on rejected and canceled requests when modifying the new transaction table. This will fix a bug that was going to require another round of status migrations prior to the deletion of old records.

(#132) Fixes multiple issues related to the migration of request and obt records, including:

  • Iteration bug causing mainnet to timeout due to large gaps in status updates needing to be migrated.
  • Status timestamps were originally stored incorrectly. This caused trailing 0s that needed to be removed.
  • req_timestamp data needed to be transferred to obt_timestamp on statuses with obt_action
  • req_content data needed to be transferred to obt_contenton statuses with obt_action
  • Corrections to recordobt to store these values in the future correctly.

(#134 ) Scope migration iteration into smaller sets for more optimized indexing

  • This is a series of optimizations that will benefit the migration process for large data sets where iteration limits might cause timeouts.

Local Build notes

⚠️ This contract release should not be used for testing in local development environments as the contract requires data to be present in both the initial Request tables and the new Request table.

Release Candidate - FIO Contracts v2.3.4-rc2

18 May 02:41
c3a4ac2
Compare
Choose a tag to compare

Bug Fixes

(#134 ) Scope migration iteration into smaller sets for more optimized indexing

This is a series of optimizations that will benefit the migration process for large data sets where iteration limits might cause timeouts.

Local Build notes

⚠️ This contract release should not be used for testing in local development environments as the contract requires data to be present in both the initial Request tables and the new Request table.

Release Candidate - FIO Contracts v2.3.4-rc1

11 May 15:08
d51dcb4
Compare
Choose a tag to compare

Bug Fixes

(#132) Fixes multiple issues related to the migration of request and obt records, including:

  • Iteration bug causing mainnet to timeout due to large gaps in status updates needing to be migrated.
  • Status timestamps were originally stored incorrectly. This caused trailing 0s that needed to be removed.
  • req_timestamp data needed to be transferred to obt_timestamp on statuses with obt_action
  • req_content data needed to be transferred to obt_contenton statuses with obt_action
  • Corrections to recordobt to store these values in the future correctly.

Local Build notes

⚠️ This contract release should not be used for testing in local development environments as the contract requires data to be present in both the initial Request tables and the new Request table.