New FIO Chain version (1.9/3.5/2.9)
New version of FIO SDK, FIO Core and FIO Contracts has been released.
Overview
New versions
| Stack | New version |
|---|---|
| FIO SDK | 1.9 |
| FIO Core | 3.5 |
| FIO Contracts | 2.9 |
TL;DR
- If your application sends FIO Requests or FIO Data, you must upgrade to version 1.9.1 of FIO SDK! There is no deadline to upgrade, but it is recommended an upgrade is performed within 30 days to limit the risk of potential encryption/decryption issues. See below for additional information.
- If you are running an API node, consider upgrading to version 3.5 of FIO Core. There is no deadline to upgrade as there are no breaking changes. Until you upgrade, your node may not be able to take advantage of new functionality below.
- New features have been added, which you may implement if you wish.
- FIO Handle and FIO Domain can now be registered in a single transaction.
- New FIO-specific permission scheme was introduced to let private domain owners define which accounts can register FIO Handles on their domains.
- FIO Chain Account can now be created explicitly with more robust permission scheme.
- FIO Public Key mapped to FIO Handle can now be changed without impacting encryption.
- Variety of bugs have been fixed and overall performance improved.
Release Details
FIPs
FIP-36
This FIP adds a new getter which returns FIO Public Key which hashes to supplied account.
Why should you care?
This is a convenience method that let's you easily fetch FIO Public Key for supplied account. This may be helpful if you want to allow users to send FIO Tokens to an account instead of FIO Public Key. Most integrators will not have a need for this functionality, as FIO typically uses FIO Public Key as destination for sending FIO Tokens.
New getters
| End-point | Description |
|---|---|
| /get_account_fio_public_key | Returns FIO Public Key which hashes to supplied account. |
Details
FIP-37
This FIP modifies onchain validation to allow multiple FIO Public Keys to be specified in updateauth.
Why should you care?
This only applies to you if you allow users to customize account permissions. Most integrators will not have a need for this. Most integrators will not have a need for this functionality.
Modified actions
| Action | Description |
|---|---|
| updateauth | Modifies onchain validation to allow multiple FIO Public Keys in keys parameter. |
Details
FIP-38
This FIP adds ability to create a new FIO Chain Account with custom permission in one action.
Why should you care?
Historically, accounts on FIO Chain were only created automatically when FIO Tokens were send to a FIO Public Key or FIO Handle or Domain was registered to a FIO Public Key. Now it is possible to create an "empty" account. Most integrators will not have a need for this functionality.
New actions
| Action | Description |
|---|---|
| newfioacc | Creates a new FIO Chain Account. |
Details
FIP-39
This FIP adds ability supply FIO Public Key, different from FIO Public Key for receiving tokens, to use for encryption of New Funds Request/Record OBT content blob.
Why should you care?
FIO Requests and FIO Data contain an encrypted blob which uses Diffie-Hellman key exchange scheme. This scheme requires the FIO Public Key of the other party during the encryption process. Historically this key was fetched using /get_pub_address, which returns the same key as used for sending FIO Tokens. This created complications when the user wanted to change the public key for receiving tokens, but not for data encryption.
For this reason, it is now possible to set an encrypt key which is different from the FIO Public Key used for sending and receiving FIO Tokens. A new updcryptkey action has been added to set the encrypt key to something different than the original FIO Public Key. A new /get_encrypt_key getter has been added to fetch the FIO Public Key to be used during encryption.
Action may be required
If your application sends FIO Requests or FIO Data:
- If you use the Typescript SDK, you should upgrade to version 1.9.1 of the Typescript SDK, which handles the new encrypt key.
- If you have implemented your own encryption or are using legacy SDKs, update it to fetch other party's FIO Public Key using /get_encrypt_key getter instead of /get_pub_address.
Failure to upgrade, may cause FIO Requests or FIO Data send by your application to not be decryptable by the receiving wallet, but only if the receiving user has changed their encrypt key.
With this FIP you may now offer your users the ability to map their FIO Handle to a different FIO Public Key than the one which owns the handle. This may be useful, for example, when a user wants to map their handle to a FIO Public Key for a private key held in cold storage. If you choose to implement this, make sure you set the encrypt public key using the new updcryptkey action and that it matches the private key controlled by the wallet.
New getters
| End-point | Description |
|---|---|
| /get_encrypt_key | Returns the FIO Public Key to use for encryption of New Funds Request/Record OBT content blob. |
New actions
| Action | Description |
|---|---|
| updcryptkey | Updates the FIO Public Key to use for encryption of New Funds Request/Record OBT content blob. |
Details
FIP-40
This FIP implements the ability to let domain owners allow specific accounts to register FIO Addresses on specific domains and pay corresponding registration fee.
Why should you care?
This is relevant for you if you are registering FIO Handles on private FIO Domains. Historically, only the owner of the domain could register a FIO Handle on it. Permissions could be granted to another account, but the owner was still the account which was paying the registration fee.
With this FIP, FIO Domain owner can grant permission to another account to register FIO Handles on private domain it owns and pay the registration fee.
New getters
| End-point | Description |
|---|---|
| /get_grantee_permissions | Returns all domain permissions for supplied grantee_account. |
| /get_grantor_permissions | Returns all domain permissions for supplied account. |
| /get_object_permissions | Returns all permissions for supplied object. |
New actions
Details
FIP-42
This FIP introduces a new action which registers both the FIO Domain and FIO Address in a single action. It also allows the user to specify, in the same action, if the domain should be public or private.
Why should you care?
This is relevant to you, if you enable users to register FIO Handles on new custom domains. Historically, a new FIO Handle on new custom FIO Domain had to be registered using two transactions, regdomain and then regaddress. The challenge, was that only the owner of the domain could run the second transaction. Now this can be accomplished in single transaction.
New actions
| Action | Description |
|---|---|
| regdomadd | Registers FIO Domain and FIO Handle. |
Details
FIP-43
This FIP updates /get_fee to properly return a token fee for actions which are bundle-eligible, but do not require a FIO Address.
Why should you care?
No action is required from most integrators.
Details
FIP-46
This FIP proposes an update to FIO chain_plugin to increase the timeout placed on get_table_rows queries.
Why should you care?
No action is required from most integrators.
Details
FIP-47
This FIP extends FIO Protocol functionality to enable FIO Block Producers to use regproducer to update their producer information.
Why should you care?
This FIO is only relevant to Block Producers.
Details
Bug Fixes
There were several bug fixes included in this release. For more information see 3.5 and 2.9 Release Notes.