Governance-regulated Foreign Token Transfers

Overview

Foreign tokens 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, KIRA’s 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 and Proof-of-Work chains, but offers on-chain signaling of the network governance's intentions.

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.

Parameters

Incoming

CLI Syntax & Examples

note

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.

note

$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 Guide page.

Transactions

Transactions

There is no transactions other than the governance proposals for this sub-module.

Queries

Queries

token-black-whites	Query lists of blacklisted/whitelisted tokens.

List Blacklisted & Whitelisted Tokens

The following command is used to lists all blacklisted and whitelisted tokens.

sekaid query tokens token-black-whites $FLAGS_QR | jq

Governance

Governance

proposal-update-tokens-blackwhite	Create a proposal for whitelisting/blacklisting tokens.

Whitelist And/or Blacklist Token Transfers Proposal

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).

Flags

• $TITLE: The title of the proposal.
• $DESCRIPTION: The description of the proposal, which can be a URL, text, etc.
• $TOKENS: A token or a comma-separated list of tokens (e.g., ATOM, KEX, BTC).
• $ISBLACKLIST: Boolean value; true to add/modify blacklist, false for whitelist.
• $ISADD: Boolean value; true to add, false to remove from the list.

sekaid tx tokens proposal-update-tokens-blackwhite \
--from=$SIGNER $FLAGS_TX \
--title=$TITLE --description=$DESCRIPTION \
--is_add=$ISADD --is_blacklist=$ISBLACKLIST --tokens=$TOKENS