Bank
cosmos.sdk/x/bank
diff --git a/04e8b755-d259-40f9-b66c-ddf5223c66fa/index.html b/04e8b755-d259-40f9-b66c-ddf5223c66fa/index.html deleted file mode 100644 index 3ccd68c..0000000 --- a/04e8b755-d259-40f9-b66c-ddf5223c66fa/index.html +++ /dev/null @@ -1,13 +0,0 @@ - - -
- - -cosmos.sdk/x/bank
Securing digital assets is no longer a luxury, but a necessity. To answer this need, our Custody Module offers a collaborative custody model, secret-protected transfers, and controlled withdrawals via whitelisting. This approach provides users with enhanced protection, tailored to their specific needs
-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's approach replaces the conventional "gas" system with a governance-driven structure. Here, transaction fees are predefined for each type of transaction and uniformly denominated in ukex
, simplifying and stabilizing the fee calculation. Additionally, the governance is tasked with setting failure fees for each transaction type and determining a specific timeout period for transactions. Complementing this streamlined fee structure, KIRA's Token Rates Registrar allows fees to be paid in other whitelisted tokens at a fee_rate
defined by the governance. This mechanism ensures a clear and efficient conversion between ukex
and other tokens, enhancing the network's flexibility and user accessibility.
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 approach serves two purposes:
min_tx_fee
sets a lower boundary, acting as a deterrent against spam transactions, thus maintaining the network's integrity by preventing it from being overloaded with low-value or malicious transactions.max_tx_fee
acts as an upper limit, safeguarding users from inadvertently incurring excessive fees. This is particularly important in preventing significant fund losses that might occur due to mistakenly high fee inputs during transaction submission.NAME | TYPE | EXAMPLE | DESCRIPTION |
---|---|---|---|
transaction_type | string | submit-proposal | The specific transaction type the following parameters apply to. All existing types can be found here. |
execution_fee | uint64 | 100 | The required fee for users to successfully execute this particular transaction type. |
failure_fee | uint64 | 50 | The fee users must pay in case the transaction execution is unsuccessful. |
timeout | uint64 | 300 | The time duration (in seconds) after which the transaction execution will be considered as failed if not completed. |
default_parameters | uint64 | 42 | The default input values that the corresponding transaction function will utilize before execution. |
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 section
set-execution-fee | Update execution fee parameters for different transaction types. |
---|
The set-execution-fee
CLI command allows accounts with sudo permission 7 to modify execution fee parameters for different transaction types.
Flags
$TX_TYPE
: The type of transaction for which the fees are being updated.$
EXECUTION_FEE
: The fee for successful execution of the transaction.$FAILURE_FEE
: The fee for failed execution of the transaction.$TX_TIMEOUT
: The timeout duration for the transaction.sekaid tx customgov set-execution-fee \
--from=$SIGNER $FLAGS_TX \
--transaction_type=$TX_TYPE \
--execution_fee=$EXECUTION_FEE \
--failure_fee=$FAILURE_FEE \
--timeout=$TX_TIMEOUT
execution-fee | Retrieve execution fee parameters for a specified transaction type. |
---|
The execution-fee
CLI command is used to retrieve the execution fee parameters for a specified transaction type.
Args
$TRANSACTION_TYPE
: The type of transaction for which to query the execution fees.sekaid query customgov execution-fee $TRANSACTION_TYPE $FLAGS_QR | jq
The Data Registry is a curated data reference storage under governance. Its primary role is to sidestep the constraints of on-chain storage by providing references to external data resources, like those found on IPFS or GitHub. By doing so, the Data Registry ensures that large files or extended data sequences aren't directly stored on-chain. Instead, it archives external URLs, metalinks, and various distributed references. A pivotal aspect of the Data Registry is its ability to vouch for the authenticity and integrity of the external data. This is achieved via on-chain checksums, bolstering trustworthiness by verifying the consistency of hosted data. Furthermore, the Data Registry enriches the stored references by supplying supplementary information, including file size and encoding. Akin to how the Identity Registrar assures the legitimacy and uniqueness of user identities, the Data Registry offers a secure, reliable bridge between the on-chain network and the vast external data world.
-An integral property of the Data Registry is the code_of_conduct
. This can be perceived as the Service-layer Agreement bridging network governance and its users. This off-chain text serves as a guiding beacon, delineating the expected conduct of network participants. In essence, it acts as the network's constitution, providing insights and guidelines to users and incoming governance members alike.
NAME | TYPE | EXAMPLE | DESCRIPTION |
---|---|---|---|
key | string | doc1 | The identifier for the stored property. |
reference | string | ipfs://QmYw... | The URL or metalink directing to the externally hosted file. |
encoding | string | markdown | Specifies the file's encoding type. |
hash | string | e3b0c442... | The SHA256 checksum, ensuring the file's authenticity. |
size | uint64 | 1024 | Denotes the file size in Bytes. |
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 section
There is no transactions other than the governance proposals for this sub-module
data-registry-keys | Retrieve a list of all keys in the Data Registry. |
---|---|
data-registry | Retrieve data associated with a specific key. |
Retrieve a list of all keys in the Data Registry using the data-registry-keys
command.
sekaid query customgov data-registry-keys --page-key=100000 $FLAGS_QR | jq ".keys"
Retrieve data associated with a specific key using the data-registry
command.
Args
$
KEY
: The key whose data is to be queried.sekaid query customgov data-registry $KEY $FLAGS_QR | jq
upsert-data-registry | Create a proposal for adding or updating a key in the Data Registry. |
---|
The CLI command, upsert-data-registry
, is utilized to create a proposal for adding or updating a key in the Data Registry. The command accepts the following arguments and flags:
Args
$KEY
: The key intended to be upserted in the Data Registry.$CHECKSUM
: The checksum corresponding to the data associated with the key.$VALUE
: The value tied to the key.$FILETYPE
: Specifies the type of the file or data that's related to the key.$SIZE
: The size of the file or data linked to the key.Flags
$TITLE
: The title of the proposal. Typically in the form "Upserting Data Registry key '$KEY'".$DESCRIPTION
: The description of the proposal, often described as "Assign value 'KEY'".sekaid tx customgov proposal upsert-data-registry \
--from=$SIGNER $FLAGS_TX \
--title=$TITLE --description=$DESCRIPTION \
"$KEY" "$CHECKSUM" "$VALUE" "$FILETYPE" "$SIZE"