Concept
Traditional Layer 1 blockchain networks like Ethereum use a complex, dynamic fee market determined by opcode prices and the computational "gas" consumed during transaction execution. In such a system, calculating the exact transaction cost can be cumbersome and time-consuming. Additionally, these opcode prices are deeply embedded within the protocol, typically requiring a network upgrade or hard fork for changes.
KIRA, however, streamlines this process significantly. Transaction fees are predefined per transaction type and denominated in ukex. Moreover, thanks to KIRA's 
Token Rates Registrar, these fees can also be paid in other whitelisted tokens, at a fee_rate defined by the governance. This rate creates a straightforward conversion mechanism between ukex and other tokens, further simplifying transaction costs. While KIRA does have a fee market, it operates within a bounded range set by the min_tx_fee and max_tx_fee parameters. This design makes the pricing simple, predictable, and easily updatable through on-chain governance.
Token Rates Registrar, these fees can also be paid in other whitelisted tokens, at a fee_rate defined by the governance. This rate creates a straightforward conversion mechanism between ukex and other tokens, further simplifying transaction costs. While KIRA does have a fee market, it operates within a bounded range set by the min_tx_fee and max_tx_fee parameters. This design makes the pricing simple, predictable, and easily updatable through on-chain governance.This approach serves two primary purposes:
Spam Prevention: KIRA's bounded fee market acts as a first line of defense against spam, ensuring the network remains unburdened by frivolous transactions.
User Protection: The min_tx_fee and max_tx_fee parameters not only guard the network against transaction spam but also protect users from unexpected spikes in transaction costs.
By offering a bounded fee market and the flexibility to pay fees in multiple tokens, KIRA effectively balances the needs for predictable transaction costs and network responsiveness, making it more adaptable for real-world applications, including high-frequency financial transactions.
Parameters
CLI 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
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 sectionGovernance
To change the execution fee parameters of any existing transaction type, a sudo permission 
7 is required.
7 is required.Transactions
Updating Execution Fees
Bash
Copy
# Updating Execution fees via proposal
# CLI
# TBD
# KM
# TBD
# Updating Execution fees as sudo
# CLI
sekaid tx customgov set-execution-fee --execution_fee="$EXECUTION_FEE" --failure_fee="$FAILURE_FEE" --transaction_type="$TX_TYPE" --timeout="$TX_TIMEOUT" \
--from "$ACCOUNT" --chain-id=$NETWORK_NAME --keyring-backend=test --fees=100ukex --yes --log_format=json --broadcast-mode=async --output=json | jq
# KM
# e.g: setExecutionFee <account> <tx-type> <execution-fee> <failure-fee> <tx-timeout>
setExecutionFee $ACCOUNT $TX_TYPE 100 200 60
Query Execution Fees
Bash
Copy
# CLI
sekaid query customgov execution-fee "$TRANSACTION_TYPE" --output=json --home=$SEKAID_HOME
# KM
showExecutionFee "$TRANSACTION_TYPE"