Concept
Foreign tokens can can significantly impact the network's economy if they are stolen or originate from a compromised network (i.e. Luna). For instance, should a token experience sudden supply exploitation, it could pose a serious risk to the network's spam protection mechanism if used for fee payments. To mitigate this risk, the KIRA governance has the ability to create and manage blacklist and whitelist filters for foreign token transfers. These filters can be enabled or disabled through the enable_token_whitelist and enable_token_blacklist network properties, and their contents are curated through dedicated governance proposals. In the event that a foreign network becomes compromised and its tokens are deposited into KIRA, these filters can be used to recover funds through a planned hard fork. This process is similar to funds recovery in other Proof-of-Stake (PoS) and Proof-of-Work (PoW) chains, but offers on-chain signaling of the network governance's intentions.
Governance
The contents of the whitelist and blacklist are curated through dedicated governance proposals. Accounts must possess permission 24 to propose additions or removals of tokens from the list. Similarly, for voting on any of these proposals, an account must have permission 25. Once a proposal is passed and executed, the whitelist or blacklist will be updated accordingly, and subsequent transactions will be subject to the updated filters.
Parameters
Filters mechanism
When the enable_token_whitelist network property is set to true, SEKAI will check whether a given token is whitelisted before allowing it to be transferred. Similarly, when the enable_token_blacklist network property is set to true, SEKAI will check whether a given token is blacklisted before allowing it to be transferred. These checks are performed during the AnteHandler phase of transaction processing.
If a token is not on the whitelist (in the case of enable_token_whitelist being set to true) or is on the blacklist (in the case of enable_token_blacklist being set to true), then the transaction will fail validation during the AnteHandler phase, and the transaction will not be broadcasted to the network or included in any block.
CLI functions description
x/tokens
proposal-update-tokens-blackwhite - Create a proposal to add or update a whitelisted or blacklisted token
query/tokens
token-black-whites - List all whitelisted and blacklisted tokens
Syntax & Examples
Each CLI command and proposal process in KIRA requires specific permissions. These permissions must be added to the account's whitelist or obtained as sudo permissions for direct changes. Refer to the Roles & Permissions documentation for more details. $SIGNER represents the transaction signer's account name or address. For instructions on setting common flags as environment variables, such as $FLAGS_TX and $FLAGS_QR, see the CLI flags configuration section
Whitelisting/Blacklisting Token Transfers
The proposal-update-tokens-blackwhite CLI can be used by accounts with permission 24 to create a proposal for adding or modifying whitelist or blacklist tokens. To vote on the proposal, an account must have permission 25 . The --is_add flag specifies whether the token should be added (true) or removed (false) from the list, while the --is_blacklist flag specifies which list to update (true for blacklist, false for whitelist).
Bash
Copy
sekaid tx tokens proposal-update-tokens-blackwhite \
--from=$SIGNER $FLAGS_TX \
--title=$TITLE --description=$DESCRIPTION \
--is_add=$ISADD --is_blacklist=$ISBLACKLIST --tokens=$TOKENS
Query
Query lists of blacklisted/whitelisted tokens
Bash
Copy
sekaid query tokens token-black-whites $FLAGS_QR | jq