Skip to content

Latest commit

 

History

History
107 lines (85 loc) · 6.13 KB

fip-0041.md

File metadata and controls

107 lines (85 loc) · 6.13 KB
fip title status type author created updated
41
Enable token locking to existing accounts
Final
Functionality
Pawel Mastalerz <[email protected]>
2022-02-09
2022-10-19

Abstract

This FIP removes the restriction that transfer_locked_tokens can only transfer tokens to a FIO Public Key which has not yet been established as an account.

Modified actions

Contract Action Endpoint Description
fio.token trnsloctoks /transfer_locked_tokens Allow transferring of locked tokens to existing accounts.
multiple Token transfer or payment of fee multiple Clear lockedtoken table entries for matured locks.

Motivation

When FIP-6: Transfer locked tokens functionality was built, a decision was made to only allow locked token transfers to brand new accounts. This was done to simplify the implementation and satisfied the use case requirements at that time.

Since then, FIP-21: FIO Staking has rearchitected the locked token functionality and made it much easier to support transfers of locked tokens to existing accounts.

A new use case (recurring compensation with locked tokens) has also elevated the requirement to support this feature.

Specification

Modified actions

Transfer locked tokens

Allow transferring of locked tokens to existing accounts.

Contract: fio.token

Action: trnsloctoks

End point: /transfer_locked_tokens

Request

Unchanged

Processing

Modify the logic so that:

  • transfer_locked_tokens with can_vote:0 can only transfer tokens:

    • To a FIO Public Key which has not yet been established as an account
    • To an account which has a lock entry with can_vote:0

  • transfer_locked_tokens with can_vote:1 can only transfer tokens:

    • To a FIO Public Key which has not yet been established as an account
    • To an existing account with no lock entries
    • To an account which has a lock entry with can_vote:1

Remove the following exceptions handling:

Error condition Trigger Type fields:name fields:value Error message
Account already exist Account hashed down from Public Key alreday exists. 400 "payee_public_key" Value sent in "Locked tokens can only be transferred to new account."

Add the following exception handling:

Error condition Trigger Type fields:name fields:value Error message
Transfer can_vote:0 locked tokens to existing account can_vote is set to 0 and target account already exists on chain 400 "can_vote" Value sent in, e.g. "0" “can_vote:0 locked tokens cannot be transferred to an account that already exists”
Transfer can_vote:0 locked tokens to account with existing can_vote:1 locks can_vote is set to 0 and target account has a lock entry with can_vote:1 400 "can_vote" Value sent in, e.g. "0" "can_vote:0 locked tokens cannot be transferred to an account that contains can_vote:1 locked tokens"
Transfer can_vote:1 locked tokens to account with existing can_vote:0 locks can_vote is set to 1 and target account has a lock entry with can_vote:0 400 "can_vote" Value sent in, e.g. "1" "can_vote:1 locked tokens cannot be transferred to an account that contains can_vote:0 locked tokens"

Response

Unchanged

Token transfer or payment of fee

Clear lockedtoken table entries for matured locks.

Contract: multiple

Action: multiple

End point: multiple

Request

Unchanged

Processing

Modify the logic so that:

  • Lock table entry for account is cleared if all locks have matured, meaning 100% of all locked tokens are now unlocked.

Response

Unchanged

Rationale

Multiple locked token transfers and can_vote parameter

can_vote allows the sender of locked tokens to specify if the locked tokens can be voted before they unlock. The functionality was part of the original FIP-6 which was designed to established the locks on account creation and assumed the locks would not be modified in the future. As a result, there is only one lock entry per account and one of its parameters is can_vote, which applies to all tokens locked in that account.

FIP-21 introduced the ability to add new periods to existing lock entry but failed to properly consider the impact of the can_vote parameter on tokens locked as a result of unstake. This causes the following behavior to exist on Mainnet:

  • Alice uses trnsloctoks to send Bob 100 FIO tokens and specifies can_vote:0
  • Bob acquires 1000 FIO tokens and stakes them
  • Bob unstakes 1000 FIO tokens which causes a new period be inserted into the lock table. However, because can_vote applies to all tokens locked and was previously set to 0, Bob's unstaked tokens are not votable until the unstake lock expires (7 days). This is not what was intended, but is deemed acceptable.

To avoid further exacerbating the problem, transferring of locked tokens with voting restriction remains restricted to new accounts only.

Implementation

For project level information and status please refer to the wiki, the FIP-41 project has sub documents for each project artifact for FIP-41. Also there is a link here to the jira epic and all stories for the project:

FIP-41 Wiki

Please refer to the Development Specification for this project located here FIP-41 Development Specification

Release information

The following changes were included in fio.contracts v2.8.0

  • Contract action trnsloctoks was modified

The following changes were included in fio v3.4.0

  • API endpoint /transfer_locked_tokens was modified

Backwards Compatibility

No changes to requests/responses in existing actions or getters.

Future considerations

None

Discussion link

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