About Kii

A lot has transpired since Satoshi’s whitepaper announcing the arrival of Bitcoin in 2008 as Bitcoin has become the digital gold standard and is positioning itself as the reserve currency of the world. In 2013, Ethereum established itself as the leader in layer 1 infrastructure, initiating the cycle of growth among web3 businesses. Since then, over 1 million tokens have been publicly launched, each with their unique focus.

The growth of each project has a common theme within the technology: Communication. Blockchain infrastructure connects users in ways never before, eliminating a centralized counterparty needed to facilitate that connection, and instead proposes changes to the architecture enabling decentralization as the preferred means of communication. Even though this change has prompted user adoption globally, there remains gaps in the technology that adjust to specific market and cultural conditions in emerging economies.

In developing countries, the current transfer of value mechanisms that connect emerging economies to developed economies are overly centralized, slow and costly. It's determined to be why emerging economies in the last 25 years have yet to “emerge”. These transfer of value networks have failed to improve globalization and local commerce in an efficient way, connecting important economic counterparts in order to create uniformity in how they communicate.

Although economically a very large industry, emerging markets don't just thrive on remittances from users aboard. Their economies are normally derived from production locally. Whether its natural resources and commodities, exports of goods, imports for raw materials for production of those goods, the necessity for a dedicated, open-sourced, unified liquidity layer is clear given that the B2B market is 10x+ the size of consumer remittances with higher average volumes and transactions. Faster fiat settlements, safer FX solutions, and access to international credit terms are only a few of the current existing pain-points.

KiiChain is unwaveringly committed to delivering high-performance, interconnected, and ultra-secure blockchain solutions as a driver in economic development in emerging markets in an effort to improve communication and globalization. At the heart of our technological prowess is the CometBFT mechanism, a solution for problems that exist in the economy, particularly emerging economies and Latin America. However, more than just a blockchain, Kii Global has built an infrastructure ecosystem of solutions designed to unify blockchain liquidity and its participants, in an effort to directly solve some of the biggest economic challenges in the region.

FX settlement layer for Stablecoins and tokenized Real-World Assets

KiiChain is a supercharged unified liquidity network for international trade, finance and payments – specifically built for emerging markets. It seamlessly melds with prevailing payment infrastructures, aiming to alleviate the exorbitant costs and reduce barriers in global economic transactions. Unlike other monolithic blockchain layers, KiiChain is purpose-built for emerging markets and “last mile” integrations into local economies, breathing life into previously liquidity-constrained sectors that cannot financially communicate with the rest of the world.

The blockchain rides on the back of the CometBFT consensus mechanism built with the Cosmos SDK - a testament to its decentralization and commitment to achieve lightning-fast finality and minuscule network fees. Primarily, its design suits the daily exigencies of emerging economies, taking into account the wealth imbalances that exist. KiiChain’s Comet consensus mechanism boasts supercar-fast validators that produce blocks in seconds, allowing for instantaneous cross-chain settlement times and a fee on the network less than one peso.

The Kii blueprint saw expansion within its product and app suite, incorporating custom on-chain protocols and modules to allow any user, builder or business to connect directly to the network. KiiChains flagship native app, KIIEX, is a hybrid centralized-decentralized exchange specifically conceptualized for liquidity assimilations in RWA and payment settlement. KiiChain is amplified by a series of protocols and modules that provide interconnectivity between Ethereum, Solana, Cosmos and more – providing unified access to tradeable assets across ecosystems on one network.

The product suite provides institutional infrastructure and liquidity, connecting global players to local operators. KiiChain is EVM compatible and supports smart contracts in both Solidity and Rust. It’s a permissionless ecosystem for open finance, where web2 and web3 developers can build a wide variety of dApps and protocols.

1. KIIEX Benefits: KII holders will have reduced trading fees and cash-in/cash-out rates within the ecosystem. Users who remit funds in KII will have priority to liquidity and rates, especially within our ecosystem of partners.

2. KIIEX Incentives: KII will be used to create incentives for on-chain PayFi liquidity pools, designed specially to incentivize stablecoin liquidity when creating pools on the less demanded side of the trade. (ie: USDT / COP – higher need for COP liquidity than USDT liquidity, therefore those that create COP liquidity pools will receive KII incentives and greater spreads).

3. Payment for the use of the KiiChain RWA protocol: Payment for use of the RWA protocol and “unified liquidity” swaps to over 100+ networks will be in KII token relative to bps on total AUM of for permissioned tokens. Example: 10bps of the nominal asset value paid in KII from the liquidity sourced from an RWA purchase.

4. Pricing of Assets on KIIEX: Tokenized commodities and products can be priced in KII to create instant/easier liquidity in our hybrid CEX/DEX from native liquidity pools.

5. Collateral: KII will be used as a collateral on DeFi apps, liquid staking, lending, and futures settlement.

6. Staking: KII is required for validators and delegators to participate in the network. KII is the only token eligible for validating and delegating in KiiChain.

7. Rewards: KII is rewarded to validators and delegators for their service to the network.

8. Gas fees: KII is used for transaction fees. All transactions such as deployment of new smart contracts, creation of user accounts, or token transfer, require the payer to pay transaction fees in KII.

9. Governance: KII will be used for voting on future protocol and ecosystem development once the blockchain migrates to open governance.

Kii Global believes in a true non-inflationary environment for Kiichain that does not mint or burn tokens. However, in common PoS blockchains, minting features are popular to be able to cover the staking pool and its rewards.

In order to compensate for this, Kiichain has instituted an "evergreen" model where 5% of the cash flow of Kii Global's overall activity will be diverted to purchase coins in the market to replenish the rewards pool.

This is possible because Kii Global's real world use business model is already functioning, producing positive cash flow as an organization. This feature will be implemented 90 days after launching the token publicly, where earnings from the first 90 days will be sent to the lead market-maker in order to execute the trade and replenish KII into the staking pool.

Explorer App (best option for builders)

Connect your Keplr or MetaMask wallet to the explorer app to stake KII into a validator or to help launch a full node/validator.

Web Wallets

Connect to our web wallet using Keplr or Metamask.

Mobile Wallets

Download and set up our Kii Mobile wallet from the App Store or Google Play. Mobile apps allow users to send and receive KII and stake their KII to a validator of their choice.

Stablecoin FX powerhouse

Traditional FX operations are hindered by TradFi banking hours (often times 8am to 1pm local). Essentially, only 25% of the day, on business banking days, can businesses or users engage in FX operations. Users can now engage in compliant, fast and affordable FX transactions on KiiChain and receive their funds real-time.

Unified Liquidity for Trading and Payments

Liquidity is often fragmented among several different blockchain ecosystems. This causes headaches for users who need to manage different balances and wallets among different ecosystems. Direct bridging from each network can be slow, costly and difficult for users who don’t understand web3 architecture. KiiChain partners with protocols to create an interoperable liquidity layer that can deliver seamless cross-chain experiences to users of all types.

Tokenization of Commodities (RWA)

Commodities are among the most valuable and traded goods in the world with major reserves being mined and developed in emerging countries. Local companies can now tokenize their commodities and contracts, pricing them in Kii or a native asset to their project, and create instant liquidity on a global scale.

Tokenization of Products (RWA)

Imported and exported goods are one of the major drivers of GDP within Latin America and emerging economies. Many multinational companies in the region struggle to process funds and manage liquidity reserves. These products can be tokenized and transacted on the blockchain for users to transact with these goods, and for companies to better manage their reserves.

Tokenization of Real Estate (RWA)

Asset fractionalization and ownership is becoming more imperative than ever before in markets with wealth fragmentation, high inflation and high interest rates. Real estate and asset infrastructure fractionalization allows users to own yield bearing, inflation protected, assets that cannot be owned by these users in whole. By democratizing the ownership process, liquidity can extend to other markets and users who would not otherwise have access prior.

Tokenization of Debt and Equities (RWA)

Public equities, debt instruments, or exchange traded funds that are trading on traditional exchanges can be tokenized to expand, democratize and fractionalize their access cross-border, to individuals who do not have access to these opportunities.

DeFi Lending and Borrowing for Open Credit System

Credit is a huge issue in developing countries with strict underwriting standards, toxic level interest rates and lack of available capital. DeFi lending will provide secure ways for users in developed countries to extend safe credit terms to participants in emerging markets.

Payment Finance

Businesses and users in developing countries lack formal communication with payment processors abroad. Payment finance is a model that allows local businesses to bring their economic activity on-chain and receive financing that supports their core businesses, primary payment services activities.

Credit Finance

Emerging markets suffer from a multi-trillion dollar credit gap. When businesses can bring their economic activity on-chain, they open themselves up to the world of lending and competitive interest rates. Businesses or users who could not previously receive credit from local institutions, can now communicate with lenders abroad.

Spot and Forward Settlement

The B2B remittance market transacts over hundreds of billions USD annually. These importers and exporters either win or lose on spot or forward contract settlements. By each counterparty posting liquidity via a smart contract on the blockchain, users can eliminate losses by sharing in any FX swings.

Start building with KiiEx 👷🏻‍♂️💻 — explore powerful trading and account APIs to integrate and automate your crypto operations. 💰💸

What is a Kii validator?

KiiChain is a Cosmos-based blockchain powered by CometBFT that relies on a set of validators to secure the network. The role of validators is to run a full node and participate in consensus by broadcasting votes that contain cryptographic signatures signed by the validator's private key. Validators commit new blocks in the blockchain and receive revenue in exchange for their work. Validators must also participate in governance by voting on proposals. Validators are weighted according to their total stake.

Validator minimum: 10,000 KII

What is a full node?

A full node is a server running a chain's binary (its software) that fully validates transactions and blocks of a blockchain and keeps a full record of all historic activity. A full node is distinct from a pruned node that processes only block headers and a small subset of transactions. Running a full node requires more resources than a pruned node. Validators can decide to run either a full node or a pruned node, but they need to make sure they retain enough blocks to be able to validate new blocks.

Of course, it is possible and encouraged for users to run full nodes even if they do not plan to be validators.

2022:

Inception. Internal building. OTC trading.

2023:

Q1: KiiChain Dev Net.

Q2: KIIEX build started from our OTC operation to scalable technology ().

Q3: KIIEX Beta was launched, testing trading and payments in mainnet in a whitelisted environment (over $50m in total volume). Achieved positive EBIDTA and net margin.

Q4: Kii Mobile wallet was developed for version 1 of testnet ().

2024:

Q1: KiiChain Testnet V1 was developed and launched with the cosmos SDK ().

Q2: KIIEX left beta and launched mainnet with multi-varied APIs and a suite of other features. KIIEX onboarded over 200 enterprise clients with access to over 200k in users.

Q3: KiiChain Testnet V2 upgrades featuring an EVM module and other tools ).

Q4: Started KiiChain Testnet V3 upgrades with new EVM module, RWA protocol, Oracle and Payfi modules. This is the last version and repo that will be continuously evolving into mainnet ().

2025:

Q1 & Q2:

• Incentivized testnet, XP and Oro rewards, featuring on-chain tasks and partnerships ().

• Public sale, listing and mainnet.

• PayFi module integration with mainnet.

• KIIEX version 2.0 will be released with new UI/UX and third party ramp features.

• KIIDEX integration into KIIEX with listing of RWA products.

• DASP license in El Salvador for both KIIEX and KiiChain.

• IBC and Wasm upgrades.

• ICS module with dual staking.

Q3:

• PayFi module fiat rail integrations and expansions. Connect to local payment gateways in target markets.

• Kii RWA protocol dApp that lets users manage cross-chain transfers of their RWA tokens.

• KIIEX API integrations for 30+ countries.

• KIIEX Debit and Credit cards (with lend-borrow financing).

Q4:

• Payfi financing protocol (ecosystem partnership) integrated with the Payfi module register profiles to extend credit to web2 and web3 companies and users.

• On-chain invoice factoring and financing.

• SVM module.

What is KIIEX

KIIEX is an on-chain FX desk powering global payments, trading and finance solutions in an easy to use platform designed for everyone. Users, businesses or builders can use KIIEX by signing up for an account or connecting to APIs. KIIEX differs from other traditional platforms by its hybrid approach of sourcing liquidity and maintaining balances on-chain exposed to local currencies. KIIEX supports fiat swaps and payins/payouts via the pricing of local, non-dollar stablecoins and other tokenized real-world assets.

Hybrid Matching Engine

At the core of KIIEX is a hybrid matching engine that is able to source on-chain liquidity across any blockchain ecosystem while using centralized pricing to hedge and rebalance on-chain positions. The result is a ultra-liquid layer that can operate 24/7 on certain pairs that only have liquidity during traditional business hours.

Ramps

KIIEX has a full suite of on and off ramps enabling instant payins and payouts from its system. These ramps are both UI and API enabled with the ability to disperse directly or to third-pary accounts while remaining 100% compliant.

Connect to APIs

KIIEX has developed a suite of APIs that embed all centralized and decentralized functionalities into a single set of APIs that any application can use. For more informaiton on the APIs, visit:

KYC / AML

KIIEX is fully compliant within each jurisdiction. Users must adhere to KYC and AML standards and requirements.

What is KiiChain?

KiiChain is a layer 1 blockchain built with the Cosmos SDK. It is an AppChain built as an abstraction layer for utility and liquidity for stablecoins and RWAs. It blends EVM compatibility with multi-chain connectivity to create a network that is highly interoperable, scalable and easy to use. Its design purpose is to onboard the next generation of developers in emerging markets who are building the best use-cases for real-world users.

KiiChain Powers KIIEX

KIIEX is a cross-border payment and trading platform bringing institutional liquidity and immediate settlement to the most popular FX and RWA pairs using non-dollar stablecoins.

Cosmos SDK

The Cosmos SDK is an open-source framework for building multi-asset public Proof-of-Stake (PoS) blockchains, like the Cosmos Hub.The goal of the Cosmos SDK is to allow developers to easily create custom blockchains from scratch that can natively interoperate with other blockchains. We envision the Cosmos SDK as the npm-like framework to build secure blockchain applications on top of CometBFT. SDK-based blockchains are built out of composable modules, most of which are open-source and readily available for any developers to use. The Cosmos SDK is a capabilities-based system that allows developers to better reason about the security of interactions between modules. Learn more about Cosmos .

Comet BFT & Tendermint Core

Comet BFT (Byzantine Fault Tolerant) is the upgraded version of Tendermint Core, the Interchain's consensus mechanism that powers Cosmos SDK blockchain systems. Comet BFT has a modular architecture that separates the consensus engine from the application layer, allowing developers to build custom blockchain applications easily. It offers fast transaction finality and high throughput, making it ideal for applications that require quick and reliable performance. Learn more about Comet BFT .

Proof-of-Stake

KiiChain is a Proof-of-Stake blockchain. PoS selects validators based on the number of tokens they hold and are willing to "stake" as collateral for servicing and securing the network. Delegators, or individual "stakers", can delegate their tokens to any specific validator that meets the requirements.

Kii RWA Protocol

The Kii RWA Protocol sets standardization of Real World Asset (RWA) tokenization through the T-REX (Token for Regulated EXchanges) protocol using CosmWasm smart contracts on KiiChain that are simultaneously mirrored to ERC tokens. The T-REX protocol is designed for compliant issuance and management of security tokens on blockchain networks. Apart from token standards, the protocol defines on-chain KYC, KYB and asset verification. The Kii RWA protocol on KiiChain is creating an interoperable unified liquidity layer for RWA tokens.

Kii Payfi Module

The Kii PayFi Module is a gas-optimized payment system for merchant transactions with specialized fee handling along with a Paymaster System to grant gas funds for DeFi actions via protocols. The module is developed for both web3 and web2 companies to incentivize the migration of their revenue and payment models to on-chain functions. Included in the module, is a Defi protocol that sets standards for TVL based loans, collateral management, interest models, and liquidity systems. Advanced features include revenue lending, invoicing financing, payment scheduling and TVL based credit card financing through community Payfi pools. This module is still in development and will be deployed in the coming weeks.

EVM Module

The EVM module allows for mirrored EVM compatibility and for smart contracts to be deployed in Solidity to the network. This means it can run all existing Ethereum dApps and smart contracts without needing any changes. It achieves this with a high-performance Ethereum Virtual Machine (EVM) that is optimized for speed and reliability. Thanks to its modular, plugin-based design, it allows any host blockchain to execute Ethereum transactions and smart contracts.

IBC

Inter-Blockchain Communication is a protocol that allows for cross chain communication and data transfers. It connects different blockchain networks to promote high levels of interoperability, scalability and communication. IBC can be implemented to any blockchain network as long as it conforms to its protocol guidelines. Currently, there are over 100 networks integrated into IBC. Read more about IBC .

Endpoints for user authentication.

Testnets

Testnet Oro is our public testnet that is currently active.

Testnet Oro is the permanent testnet with smart contract functionality and EVM compatibility. All Hackathons, Builds, Airdrops, and test deployments should be done on this network. You can find more information such as endpoints, chain data, and general guides here:

Developer Tools

If you are a developer we also have our official SKDs for development:

Protocols

Kii protocols can be found at these links:

Endpoints

Generally, our chains (testnets and mainnet) follow the same set of endpoints. More information about our endpoints can be found here:

KiiChain Discord Server

If you would like to connect directly with the community and ask questions related to building on the network, join the discord server where our internal developers are ready to field any questions you have.

System-level endpoints used by trading and operator roles.

Coin Details

No minting or burning.

About the Faucet

Testnet participation is a great way to signal to the community that you are ready and able to operate a validator.

Important to create your web wallet first and then link to the explorer app.

• Testnet explorer app

Testnet KII can be found in the faucet in Discord and on our Explorer App. It can be called on every 24 hours.

• Discord Kiichain Invitation

Discord Faucet Commands

Request tokens:

$request {address}

Example EVM:

$request Ox12345abcde…

Example CW:

$request kii12345abcde…

List of Commands:

See all available commands:

$help

Request tokens:

$request [kii address]

Query an address balance:

$balance [kii address]

Query a transaction:

$tx_info [transaction hash ID]

Query the faucet and node status:

$faucet_status [chain ID]

Query the faucet address:

$faucet_address [chain ID]

If you're interested in delegating (staking) your KII to a validator or masternode, the following information is important to review.

In Kiichain, delegation is the act of allocating one's tokens to Validators that have already met the minimum stake requirement. This option is particularly advantageous for individuals who either lack the technical know-how or sufficient tokens to run a Validator themselves. Delegators earn rewards from their staked tokens, though a portion, currently 10% referred to as the “Operator take-rate,” is deducted by the node operator to offset their operational costs and risks.

Delegators are obliged to stake at least 1 KII and face no upper limit on the amount they can stake. However, they must commit their tokens and choose a Validator operator for delegation before an epoch starts. After the epoch commences, the delegation remains fixed until the next epoch. It's important to note that the choice of node for running or delegation does not influence the reward amount; rather, it's the quantity of staked tokens that determines this.

With the upcoming Kiichain upgrade, wallet key handling is changing to support Ethereum-compatible tooling and address formats. This guide explains what's changing and how to recover your old wallets safely.

What’s Changing?

1. New Key Type

• Old Type: secp256k1

• New Type: eth_secp256k1

This enables Ethereum-compatible signatures (e.g., MetaMask, Keplr EVM support).

2. New Coin Type

• Old Coin Type: 118 (standard Cosmos)

• New Coin Type: 60 (Ethereum standard)

This changes the way addresses are derived from your mnemonic.

Recovering Existing Wallets

To recover old wallets (e.g., validator rewards wallets or delegator accounts) that were created before the upgrade:

kiichaind keys add <key_name> \
  --keyring-backend test \
  --recover \
  --coin-type 118 \
  --key-type secp256k1

• Replace <key_name> with your desired key name.

• Input your existing mnemonic when prompted.

Need to Check What Type a Key Was Created With?

Unfortunately, kiichaind keys list does not show the coin type. You’ll need to recall which mnemonic was created with which derivation path. To avoid confusion:

• Use clear key names like validator_old, wallet_eth.

• Document the coin type and key type when generating keys.

To motivate validators on the Kii network to prioritize the network's best interest, they must stake a minimum amount of KII tokens for a set period, typically an epoch. Each epoch is 21 days. This requirement aligns with the proof-of-stake principle, ensuring validators have a vested interest in maintaining the network's integrity.

A node that adheres to the network's rules receives KII tokens as a reward every epoch. However, non-compliance risks a partial or total loss of their stake, a process known as slashing. This policy encourages proper behavior, enhancing overall network security. Currently, there's no upper limit to how much a node can stake. Yet, failure to meet the minimum stake requirement results in exclusion from the upcoming epoch and forfeiture of rewards.

Delegator / Staker - No minimum

Full Node / Validator - 10,000 KII

MasterNode - 150,000 KII

Block rewards are distributed proportionally to all validators relative to their voting power. This means that even though each validator gains KII with each reward, all validators maintain equal weight over time.

For example, 10 validators have equal voting power and a commission rate of 1%. For this example, the reward for a block is 1000 KII and each validator has 20% of self-bonded KII. These tokens do not go directly to the proposer. Instead, the tokens are evenly spread among validators. So now each validator's pool has 100 KII. These 100 KII are distributed according to each participant's stake:

• Commission: 100*80%*1% = 0.8 KII

• Validator gets: 100\*20% + Commission = 20.8 KII

• All delegators get: 100\*80% - Commission = 79.2 KII

Then, each delegator can claim their part of the 79.2 KII in proportion to their stake in the validator's staking pool.

Introduction

Kiichain is a cosmos based blockchain that relies on a set of validators that are responsible for committing new blocks in the blockchain. These validators participate in the consensus protocol by broadcasting votes that contain cryptographic signatures signed by each validator's private key.

Validator candidates can bond their own KII and have KII "delegated", or staked, to them by token holders. Kiichain has an open set of 100 validators who reviews rewards, but over time the number of validators can be increased with governance proposals. The validators are determined by the total number of KII tokens delegated to them — the top 100 validator candidates with the most voting power are the current Kii validators.

Validators and their delegators earn KII as block provisions and tokens as transaction fees through execution of the Tendermint consensus protocol. Note that validators can set a commission percentage on the fees their delegators receive as additional incentive.

If validators double sign or are offline for an extended period, their staked KII (including KII of users that delegated to them) can be slashed. The penalty depends on the severity of the violation.

Hardware

For validator key management, validators must set up a physical operation that is secured with restricted access. A good starting place, for example, would be co-locating in secure data centers.

Validators are expected to equip their datacenter location with redundant power, connectivity, and storage backups. Expect to have several redundant networking boxes for fiber, firewall, and switching and then small servers with redundant hard drive and failover.

As the network grows, bandwidth, CPU, and memory requirements rise. Large hard drives are recommended for storing years of blockchain history, as well as significant RAM to process the increasing amount of transactions.

Create a Validator Website

To get started as a validator, create your dedicated validator website and signal your intention to become a validator in the Kii Discord validator channel. Posting your validator website is essential because delegators want to have information about the entity who is receiving their delegated KII.

Seek Legal and Tax Advice

As always, do your own research and seek legal advice if you intend to run a validator node.

Community

Discuss the finer details of being a validator on our community Discord. Follow Kii Global on all socials and sign up for the Kii newsletter to get regular updates.

How to become a validator?

Any participant in the network can signal that they want to become a validator by sending a create-validator transaction, where they must fill out the following parameters:

• Validator's Pubkey: The private key associated with this Tendermint PubKey is used to sign prevotes and precommits.

• Validator's Address: Application level address that is used to publicly identify your validator. The private key associated with this address is used to delegate, unbond, claim rewards, and participate in governance.

• Validator's name

• Validator's website (Optional)

• Validator's description (Optional)

• Initial commission rate: The commission rate on block rewards and fees charged to delegators.

• Maximum commission: The maximum commission rate that this validator can charge. This parameter is fixed and cannot be changed after the create-validator transaction is processed.

• Commission max change rate: The maximum daily increase of the validator commission. This parameter is fixed cannot be changed after the create-validator transaction is processed.

After a validator is created, KII holders can delegate KII to them, effectively adding stake to the validator's pool. The total stake of an address is the combination of KII bonded by delegators and KII self-bonded by the validator.

From all validator candidates that signaled themselves, the 100 validators with the most total stake are the designated validators. If a validator's total stake falls below the top 100, then that validator loses its validator privileges. The validator cannot participate in consensus or generate rewards until the stake is high enough to be in the top 100. Over time, the maximum number of validators may be increased via on-chain governance proposal.

Delegating = Staking

People who cannot or do not want to operate Validators (full nodes) can still participate in the staking process as delegators. Indeed, validators are not chosen based on their self-delegated stake but based on their total stake, which is the sum of their self-delegated stake and of the stake that is delegated to them. This is an important property, as it makes delegators a safeguard against validators who exhibit bad behavior. If a validator misbehaves, their delegators will move their KIIs away from them, thereby reducing their stake. Eventually, if a validator's stake falls under the top 100 addresses with the highest stake, they will exit the validator set.

Delegators share the revenue of their validators, but they also share the risks. In terms of revenue, validators, and delegators differ in that validators can apply a commission on the revenue that goes to their delegator before it is distributed. This commission is known to delegators beforehand and can only change according to predefined constraints (see section below). In terms of risk, delegators' KIIs can be slashed if their validator misbehaves.

To become delegators, KII holders need to send a "Delegate transaction" where they specify how many KIIs they want to bond and to which validator. A list of validator candidates will be displayed in KII Explorer. Later, if a delegator wants to unbond part or all of their stake, they needs to send an "Unbond transaction". From there, the delegator will have to wait 21 days to retrieve their KIIs. Delegators can also send a "Rebond Transaction" to switch from one validator to another, without having to go through the 3-week waiting period.

What is staking?

Kiichain is a public Proof-Of-Stake (PoS) blockchain, meaning that the weight of validators is determined by the amount of staking tokens (KII) bonded as collateral. These KII tokens can be self-delegated directly by the validator or delegated to the validator by other KII holders.

Any user in the system can declare their intention to become a validator by sending a create-validator transaction to become validator candidates.

The weight (i.e. voting power) of a validator determines whether they are an active validator.

Due to the fluctuating characteristics of the rewards formula, it's challenging to forecast a precise weekly or annual return for an individual staker or delegator. Entities interested in understanding potential earnings should apply the formula for some illustrative calculations. However, the actual rewards hinge on the total network stake, a figure that only becomes clear at the start of the epoch during which staking or delegation occurs.

An overview of developer tools, SDKs and resources for accessing the network.

Prerequisites

• Have a KIIEX User and upgrade verification level to 1.

Step by step

1. To be able to swap, you first need to have funds, and you can get them in two ways:

   1. The first one is creating a Deposit.

   2. The second one is getting credit. To do so, you need to contact our support team.

   To create a deposit ticket, navigate to Deposit and use the QR or wallet address to deposit any cryptocurrency.

1. Once the deposit is complete, you will see the new balance available in your account and can start swapping on the SWAP page.

   1. On the screen, you will see the cryptocurrency you are going to exchange as options; You can choose which one you want to exchange it for, and the exchange rate.

   Click on confirm, and confirm your swap

You’ll see a confirmation message on your screen, and your balance in the crypto you swapped will be updated.

Now that you have a balance, go to the Deposit/Withdraw page, select 'Withdraw', and choose the cryptocurrency you want to withdraw — in this case, COPM

Fill out the form with the details of the bank account you own and where you want to receive the COPM as COP

Click on confirm, you'll see a confirmation message on top of the page

You'll receive a withdraw confirmation e-mail, click on accept withdrawal ticket

Once you confirm your withdrawal, the payment will be processed. After the money is sent to your bank account, you’ll receive an email confirming the completion of your withdrawal cycle, and your balance will be updated both in your bank account and within the exchange

Withdraw to Wallet account

To make an on-chain withdrawal to a wallet, select the 'Wallet' option.

If the wallet is new, you need to add it to the whitelist by filling out the form.

If it already exists, just select it and confirm the operation.

Congrats 🥳✨

Your withdrawal was successful! The funds have been sent to your wallet, and you’ll receive a confirmation email shortly.

Requirements:

• Already have a KIIEX account verified on level 1, the KYC verification needs to be done by the legal representative

EN Form Link

ES Form Link

Endpoints related to user actions.

In order to choose their validators, delegators have access to a range of information directly in the Kii block explorer, where all the validators in the active set will be shown.

• Validator's moniker: Name of the validator candidate.

• Validator's description: Description provided by the validator operator.

• Validator's website: Link to the validator's website.

• Initial commission rate: The commission rate on revenue charged to any delegator by the validator (see below for more detail).

• Commission max change rate: The maximum daily increase of the validator's commission. This parameter cannot be changed by the validator operator.

• Maximum commission: The maximum commission rate this validator candidate can charge. This parameter cannot be changed by the validator operator.

• Validator self-bond amount: A validator with a high amount of self-delegated KIIs has more skin-in-the-game than a validator with a low amount.

This information can be found at app.kiiglobal.io

Step 1: Make sure you have installed the MetaMask or Keplr browser extension.

Go to Metamask.io and download and install the web extension browser. Make sure the web extension is from MetaMask or Keplr. During testnet, if you do not have MetaMask installed first, you will receive this error.

Step 2: Launch the Explorer App and Connect your Wallet to Testnet Oro.

Go to https://explorer.kiichain.io and make sure you are connected to the "Testnet Oro" network by selecting the dropdown in the top right.

For setting up a web wallet, see "Set Up a Web Wallett". Once your wallet has been created, you can link it to the explorer app by clicking the wallet icon in the top right corner.

If you have the MetaMask extension installed in your web browser, it should automatically connect the RPC endpoints.

It will then ask for approval to switch the network from Ethereum (default) to Kiichain Testnet. Click the "Switch Network" button.

Following, it will ask to link with your new wallet address. Click "Next".

Lastly, it will ask for wallet permissions. Click on "Confirm".

Awesome! Your wallet is now connected to the explorer app! Deposit testnet tokens in your address to delegate to the validator.

Step 3: Get testnet tokens.

Testnet tokens can be found on the faucet page in the explorer or requested in the discord. For more information, see here: Testnet Faucet Commands.

Note: This project is still under development, so future changes will be made.

Kiijs-SDK

KiiJS is a monorepo that contains multiple NPM libraries for writing applications that interact with KiiChain. Apart from the built SDK, the chain matches a lot of operability from cosmjs.

Documentation

Each package has its own documentation under its readme file.

Packages

KiiJS consists of smaller NPM packages within the @kiichain namespace. For more detailed documentation on each package, please refer to the table below.

Contributing

All contributions are very welcome! Remember, contribution is not only PRs and code, but any help with docs or helping other developers solve their issues are very appreciated!

Read below to learn how you can take part in the KiiPy project.

Code of Conduct

Please be sure to read and follow our Code of Conduct. By participating, you are expected to uphold this code.

Contribution Guidelines

Read our contribution guidelines to learn about our issue and pull request submission processes, coding rules, and more.

Issues, Questions and Discussions

We use GitHub Issues for tracking requests and bugs, for general questions and discussion.

License

The KiiPy project is licensed under Apache License 2.0.

Step by step

1. Create your user API Key and add permissions

2. Create a Signature

3. Authenticate via API

Create API KEY

Navigate through the admin UI to your user profile.

Click on the API KEYS option.

Click on 'Create your API KEY'. You will see the following:

Depending on how you plan to use your API KEY, please choose from the available options. If you want to restrict usage by IP address, you can add the allowed IP in the designated field. Remember, you can always modify this later.

When you click on 'Create API Key', you will see your API KEY, API SECRET, and NONCE displayed on screen only once. You can download them using the 'Export to JSON' button. It's very important to store them in a safe place, as you will need them later.

To save, click the button confirming that you've securely stored your credentials, then close the modal. Your new API KEY will now appear in the list, and you can edit or delete it as needed.

Create a Signature

To generate a signature, you will need the API Secret, Nonce, User ID, and API Key, which are all generated, You can generate a signature by using a tool such as The algorithm will be SHA256, the Key will be the API Secret, and the plain text message will be composed of a combination the Nonce, User ID, and API key, in that exact order with no spaces. An example is listed below.

Authenticate via API

Follow the example in the image, add the APIKEY, Signature, UserId, and Nonce to the request headers, and call the AuthenticateUser endpoint. This will successfully authenticate you.

In the response, you will receive a session token. Use it in all subsequent requests by including it in the headers as the value of aptoken.

Click here and go to KiiEx:

Fill up the Signup form and create your user:

Check your e-mail and do your email verification

Log In to your account

At the start your user will be level 0, and to Deposit and Withdraw you'll need to upgrade to level 1, the way to do it it

Configuration -> KYC -> Choose the level 1

Note: For enterprise users, you will also need first the be level 1, the legal representative needs to pass our KYC verification, after that you'll need to fill up one of our forms depending on your needs choose a level, our compliance team will contact you soon

Once you finish, your verification level will be 1 and you'll be able to Deposit and Withdraw

🥳✨ Congrats now you can trade, swap, deposit and withdraw on KIIEX ❤️

Step 1: Install MetaMask Extension

Go to Metamask.io and download and install the web extension browser. Make sure the web extension is from .

Step 2: Create your wallet

Once the download has been completed, a prompt will appear, click "Create a new wallet" to begin.

Create a password that will control access to your account via the extension.

Create, record, and properly store your wallet secret phrase. This step is very important as these 12 words are your secret keys to your wallet.

Awesome, nice work! Your wallet has been created. Make sure you store your keys in a safe place!

Step 3: Link your wallet to the KiiChain Testnet.

Wallets like MetaMask and Keplr can be manually connected to various testnets. MetaMask supports EVM-compatible blockchains, and at default, is set to the Ethereum network. You will need to manually connect to the KiiChain network.

The link can be done though multiple sources:

Manually setting the wallet

Click the "Ethereum Mainnet" dropdown bar on the top left and then click "Add Network" on the pop-up box.

Manually add the following testnet chain ID to add the network.

Upon saving and completion, you should be connected to the testnet network!

Now, get some testnet tokens by following the instructions: .

KiiChain Testnet Oro

Oro Testnet is the final upgraded testnet before mainnet. Users and builders can interact and build with this testnet's latest features. Oro testnet will also run incentivization programs.

For on-chain activities, activations, airdrops and more, join our open testnet here:

• Testnet Oro

Get a wallet in Testnet

Testnet Oro supports wallet connections with EVM and Cosmos based wallets like MetaMask and Keplr . To set up a wallet, make sure you have the MetaMask or Keplr wallet extension downloaded in your web browser. MetaMask supports extension downloads for the following web browsers: Chrome, Firefox, Brave, Edge and Opera. Kelpr supports wallets in Chrome, Firefox and Edge.

For further explanation of how to set up your wallet, follow the steps here or connect your testnet wallet to our explorer app automatically by following the steps here.

Get Testnet tokens

Testnet Oro tokens are available in our Discord faucet or in the Explorer App. Once you have created a wallet, you can automatically request and receive 2,500 tokens within a 24 hour period. For any developers who would like more tokens, please request a bulk amount in our Discord channels. \

The command for requesting tokens in our Discord faucet channel is:

$request {address}

Example EVM:

$request Ox12345abcde…

Example Cosmos Address:

$request kii12345abcde…

The full list of commands are:

List commands:

$help

Request tokens:

$request [kii address]

Query an address balance:

$balance [kii address]

Query a transaction:

$tx_info [transaction hash ID]

Query the faucet and node status:

$faucet_status

Query the faucet address:

$faucet_address

How to stake your tokens

Tokens can be staked in the Explorer App by connecting your wallet and delegating to an active validator. Make sure the wallet you have connected to the Explorer App is funded with tokens.

Connect wallet to Explorer App

The Explorer App can be automatically connected to MetaMask or Keplr via the RPC endpoints. Once you have installed the MetaMask extension, follow the steps here to connect your wallet and begin delegating.

Developer resources

If you’re a developer and are interested in building with KiiChain, a good place to start is reviewing the introduction information here.

Quick start links:

• Launch a node/full node/validator

• Blockchain endpoints

• Deploy a smart contract

• dApp development

• Testnet faucet

Chat with us on Discord

We’re active on our Discord. Whether you have questions regarding a hackathon or airdrop competition, or simply would just like to chat and build with us, join our discord here.

General customer service and developer support are available in our channel. Get to know us.

You can find us on Discord:

• Invitation link

How to earn airdrops and rewards

We’re constantly running localized airdrops, hackathons, and competitions in our community.

Follow our X account and stay up to date with all announcements. For additional communities, visit our communities at Galxe, Zealy, TaskOn, and QuestN.

• X Link

KiiChain is a peer-to-peer decentralized EVM-compatible network built with the Cosmos SDK. The public testnet is called KiiChain Testnet Oro.

Testnet Oro is the permanent testnet with smart contract functionality and EVM compatibility. All Hackathons, Builds, Airdrops, and test deployments should be done on this network.

Source code

The source code for the Testnet Oro can be found at:

• Kiichain

Endpoints

Testnet Oro has the following endpoints open for development purposes:

Sentry #1:

• RPC: https://rpc.uno.sentry.testnet.v3.kiivalidator.com/

• Rest (LCD): https://lcd.uno.sentry.testnet.v3.kiivalidator.com/

• GRPC: grpc.uno.sentry.testnet.v3.kiivalidator.com:443

• JSON-RPC (EVM): https://json-rpc.uno.sentry.testnet.v3.kiivalidator.com/

• Peer: 5b6aa55124c0fd28e47d7da091a69973964a9fe1@uno.sentry.testnet.v3.kiivalidator.com:26656

Sentry #2:

• RPC: https://rpc.dos.sentry.testnet.v3.kiivalidator.com/

• Rest (LCD): https://lcd.dos.sentry.testnet.v3.kiivalidator.com/

• GRPC: grpc.dos.sentry.testnet.v3.kiivalidator.com:443

• JSON-RPC (EVM): https://json-rpc.dos.sentry.testnet.v3.kiivalidator.com/

• Peer: 5e6b283c8879e8d1b0866bda20949f9886aff967@dos.sentry.testnet.v3.kiivalidator.com:26656

Currently, there are no seed nodes or persistent peers available to the public.

Chain information

Here you can find further information about Testnet Oro:

• Chain ID: oro_1336-1

• Total Supply: 1.8b Kii

• Token Denom: akii

• EVM Chain ID: 1336

• Bench32 Prefix: kii

How to chain the network

Instructions on how to join the network can be found at:

• Step-by-Step Guide

Faucet

You can get tokens to our Testnet Oro by using our Explorer app:

• KiiChain Explorer Faucet

Our through our Discord channel:

• Discord Kiichain Invitation

More information about how to use our discord Faucet can be found at:

• Testnet Faucet

Explorer

The testnet Oro also has its own Explorer, it can be found here:

• Testnet Oro Explorer

Developer Tools

You can find guides to the testnet at our Developer Tools:

• RWA Protocol

• Deploying a smart contract

• Deploying a dApp

Endpoints

Rest endpoints for the testnet Oro can be found here:

• Endpoints

EVM / CW Addresses

KiiChain Testnet Oro features a mirrored EVM - CW smart contract module that replicates EVM compatibility. CW addresses are structured in Bech32 format with a distinctive "kii" prefix, characteristic of Cosmos-based chains. EVM addresses are structured with the hexadecimal format akin to Ethereum addresses. This alteration reflects a strategic adaptation to streamline interoperability with Ethereum-based tools and infrastructure, facilitating a seamless transition for developers and users alike.

// CosmWasm based addresses
kii123abc...

// EVM based addresses
0x123abc...

Tokens

KII serves as the primary utility token within the KiiChain ecosystem, facilitating transactions and powering network operations, notably through the payment of gas fees. Distinguished by its fungibility and interoperability, KII can be seamlessly transferred and utilized across various wallet providers, including popular EVM rpc-based options like MetaMask & Coinbase wallet and cosmos-based wallets like Keplr and Leap. By leveraging KII, users can engage in a diverse array of interactions within the KiiChain network, ranging from simple transactions to more complex smart contract executions, thereby driving the adoption and utility of the native token within the broader blockchain landscape.

List of precompiles and their addresses

KiiChain supports both EVM JSON-RPC and Cosmos RPC interfaces. In order to easily interact with certain Cosmos modules, KiiChain has a set of precompiled contracts that can be called from the EVM.

Interacting with precompiles

You can utilize direct json-rpc connections to those addresses. We also have a TS/JS library to help interact with them.

Fifty percent (50%) of the total supply of Kiichain is allocated as rewards to encourage participation from validators and delegators. While the total reward amount for each epoch is fixed, individual staking rewards vary based on several factors.

A validator's income is determined by their proportional share of the total staked amount within their specific role within the open set of Validators. In essence, each participant earns a percentage of the epoch's total rewards, corresponding to their stake relative to the total amount staked by all users in the open set. The open set on compensated Validators is 100. It is important to delegate your coins to a Validator who participates in the open set.

Delegator rewards follow the same calculation principle as those for Validator operators. However, from a delegator's epoch rewards, 10% is deducted as a protocol layer fee and given to the delegated node operator, uniformly applied across all node operators.

First, staked KIIs are locked up, and retrieving them requires a 3 week (21 days) waiting period called the “unbonding period”. Additionally, if a validator misbehaves, a portion of their total stake can be slashed (i.e. destroyed). This includes the stake of their delegators.

There is one main slashing condition:

Double signing: If someone reports that a validator signed two different blocks with the same chain ID at the same height, this validator will get slashed.

This is why KII holders should perform careful due diligence on validators before delegating. It is also important that delegators actively monitor the activity of their validators. If a validator behaves suspiciously or is too often offline, delegators can choose to unbond from them or switch to another validator. Delegators can also mitigate risk by distributing their stake across multiple validators.

Disclaimer

Please note that this is highly experimental software. In these early days, we can expect to have issues, updates, and bugs. The existing tools require advanced technical skills and involve risks which are outside of the control of Kii Global, or anything published by Cosmos or the Interchain Foundation. Kii Global does not keep a copy of your keys and cannot safeguard your digital assets. Any use of this open source software is done at your own risk and on a "AS IS" basis, without warranties or conditions of any kind, and any and all liability of Kii Global or any of its affiliates or subsidiaries.

There are three type of important network participants in Kiichain.

1. MasterNodes: Kii Global will run its own proprietary validators for its corporate partners. Users who commit 150,000 KII as a minimum to these validators will receive the highest tear of rewards compensation.

2. Validators (full nodes): Validators are the heart of Kiichain that build the blocks and approve transactions. The higher amount of KII staked in the validators, the higher percentage of rewards earned from the rewards pool during each epoch.

3. Delegators (stakers): Individuals who commit KII to validators in order to participate in staking and earn rewards.

What is the Kii Oracle?

The Kii Oracle is a decentralized price feed system that provides secure and reliable real-world market data (primarily cryptocurrency prices and tokenized assets) to the KiiChain blockchain. Unlike simple data oracles, it implements a robust validator-based consensus mechanism where:

• Trusted validators independently fetch prices from multiple exchanges

• Submitted prices are aggregated using a weighted median (where voting power corresponds to a validator's stake)

• Votes that deviate beyond predefined standard deviation thresholds are automatically rejected, preventing price manipulation

• The final agreed-upon price is recorded on-chain through on-chain Oracle module

This dual-layer system (off-chain data collection + on-chain consensus) ensures DeFi applications like stablecoins and lending protocols receive tamper-resistant price data while maintaining full decentralization.

What kind of information does the Kii Oracle store?

The Kii Oracle stores and manages:

• Cryptocurrency price pairs (e.g., BTC/USDT, ETH/USDT) with:

  • Chain-denominated values (e.g., ubtc, uusdt for KiiChain assets).

  • Deviation thresholds to prevent volatile or manipulated data.

  • Provider lists (e.g., Binance, Coinbase) for data aggregation.

• Validator-submitted prices, aggregated into a consensus value.

The data is stored on-chain in the Oracle module’s state and updated periodically by the price-feeder to ensure accuracy.

What is the Purpose of an Oracle in Kiichain?

An Oracle in Kiichain serves as the essential bridge between blockchain-based financial applications and real-world market data. It provides secure, decentralized, and tamper-proof price feeds that enable smart contracts to interact with external economic information and empowers developers to build financial tools with key requirements such as open, fair, and resilient.

Being a delegator is not a passive task. Here are the main points of consideration of a delegator:

1. Perform careful due diligence on validators before delegating. If a validator misbehaves, part of their total stake, which includes the stake of their delegators, can be slashed. Delegators should therefore carefully select validators they think will behave correctly.

2. Actively monitor their validator after having delegated. Delegators should ensure that the validators they delegate to behave correctly, meaning that they have good uptime, do not double sign or get compromised, and participate in governance. They should also monitor the commission rate that is applied. If a delegator is not satisfied with its validator, they can unbond or switch to another validator (Note: Delegators do not have to wait for the unbonding period to switch validators. Rebonding takes effect immediately).

3. Participate in governance. Delegators can and are expected to actively participate in governance. A delegator's voting power is proportional to the size of their bonded stake. If a delegator does not vote, they will inherit the vote of their validator(s). If they do vote, they override the vote of their validator(s). Delegators therefore act as a counterbalance to their validators.

Introduction

Social engineering has existed for about as long as human beings have been on the planet, and in the technical era, it usually takes in the form of phishing or spearphishing. Both of these attacks are wildly successful forms of trickery that are responsible for over 95% of account security breaches, and they don't just happen via email: these days, opportunistic and targeted phishing attempts take place anywhere that you have an inbox. It doesn't matter if you're using Signal, Telegram, SMS, Twitter, or just checking your DMs on forums or social networks, attackers have a plethora of opportunities to gain foothold in your digital life in effort to separate you from valuable information and assets that you most definitely don't want to lose. If an opportunity pops up that sounds too good to be true, or a message shows up asking for information that should never, ever be shared with someone else, you can always verify it before engaging with it by navigating to our official website or an official Kii Global communication channel on your own.

Be skeptical of unexpected attachments, or emails that ask you to visit a suspicious or unfamiliar website in the context of blockchains or cryptocurrency. An attacker may attempt to lure you to a compromised site designed to steal sensitive information from your computer.

Do your due diligence before purchasing KII. Neither the Kii Global team nor KIIEX will be selling KII at launch, so if you see social media posts or emails advertising a token sale from us, they're not real and should be dismissed immediately. If you're on the hunt for KII, make sure that you've researched the seller or exchange to confirm that the tokens are coming from a trustworthy source.

No one from Kii Global or KIIEX will ever send an email that asks for you to share any kind of account credentials or your 12 words with us, and we will always use our official Twitter, Discord, Telegram, Instagram, and Github accounts to communicate important news directly to the Kii Global community.

If you receive an email or tweet that sounds too good to be true, it is likely to be a scam.

Keys management

The best way to minimize the risk of theft or loss of KII is to have a strong storage and backup strategy for your private keys. The safest way to store your keys is offline, either in a cryptocurrency wallet or on a device that you never connect to the internet. The best backup strategy for your keys is to ensure that you have multiple copies of them stored in safe places, and to take specific measures to protect at least one copy of your keys from any kind of natural disaster that is a likely possibility in your part of the world.

To protect your KII, do not share your 24 words with anyone. The only person who should ever need to know them is you. You do not need to share your private keys if you're delegating KII to a validator on the network or to use custodial services. If anyone asks for your key material, it is most likely a scam.

Software Vulnerabilities

To protect yourself and ensure you're using the safest code is to use the latest version of software available, and to update immediately (or as soon as you can) after a security advisory is released. This is important for your laptops, mobile devices, cryptocurrency wallets, and anything else that may be linked to your identity or your cryptocurrency.

To protect your KII, you should only download software directly from official sources, and make sure that you're always using the latest, most secure versions of Kii Global applications when you're doing anything that involves your 24 words. If you’re building on Kiichain, Cosmos, gaiad, or connecting to the Cosmos Hub, the latest versions of software will always be available from official Github repositories.

No one from Kii Global, Cosmos, the Tendermint team, the Interchain Foundation, or any affiliated blockchains in Cosmos will ever send an email that asks for you to download a software attachment after sending out a security advisory or making a patch available.

Verifying Transactions

Be skeptical of technical advice, especially advice that comes from people you do not know in forums and on group chat channels. Familiarize yourself with important commands, especially those that will help you carry out high-risk actions, and consult our official documentation to make sure that you're not being tricked into doing something that will harm you or your validator.

When sending transactions or doing anything that may spend coins, you should always verify those transactions before hitting send. While address strings are long, it is important to visually comparing them in blocks of 4 characters at a time to ensure that you are sending them to the right place rather than into oblivion.

If need be, send smaller “test” transaction amounts before sending larger amounts.

Account Security

One of the most important things you can do to protect your cryptocurrency and eliminate risk is to harden all of your critical online accounts. Attackers will try to gain a foothold wherever they can, and will use that foothold to pivot from one place to another. Unprotected accounts like email, social media, your Github account, and anything in between could give an attacker an opportunity to gain a foothold in your online life.

For people who hold cryptocurrency, there are two specific account security actions that can be taken to eliminate specific risks that come with being part of the blockchain world.

First, it is important to enable 2-factor authentication everywhere you can (including the Kii Wallet and KIIEX), and to make sure that you are using a code generator or U2F hardware key as a second factor.

Second, be mindful of account recovery methods used to regain access to your most important accounts and make sure that you do not use SMS as a recovery method. If you haven't done so yet, start using an authenticator app or a hardware key immediately for your personal email account and wherever else you manage your tokens, especially if you use online exchanges.

Attacks

Whether you're buying a hardware or a hardware wallet, it is important to purchase whatever you need directly from the supplier or from a trusted source. This is the only way to completely eliminate the risk of a compromised device or chip from stealing your private keys, especially since there are reports of compromised wallets being sold on Amazon and through other popular online marketplaces.

Revenue

Validators and delegators earn revenue in exchange for their services. This revenue is given in two forms:

1. Block provisions (KIIs): They are paid in newly created KIIs. Block provisions exist to incentivize KII holders to validate and stake the network.

2. Transaction fees (KIIs): Each transfer on Kiichain comes with transaction fees. These fees can be paid in any currency that is whitelisted by the Hub's governance. Fees are distributed to bonded KII holders in proportion to their stake.

Each validator receives revenue based on their total stake. Before this revenue is distributed to delegators, the validator can apply a commission. In other words, delegators have to pay a commission to their validators on the revenue they earn. Let us look at a concrete example:

We consider a validator whose stake (i.e. self-delegated stake + delegated stake) is 10% of the total stake of all validators. This validator has 20% self-delegated stake and applies a commission of 10%. Now let us consider a block with the following revenue.

Validator Commission

We can see the validator commission with the following example:

• 990 KIIs will be rewarded in block provisions

• 10 KIIs will be rewarded in transaction fees

• This amounts to a total of 1000 KIIs in rewards

Our validator's staking pool represents 10% of the total stake, which means the pool obtains 100 KIIs. Now let us look at the internal distribution of revenue:

• Commission = 10% * 80% * 100 KIIs = 8 KIIs

• Validator's revenue = 20% * 100 KIIs + Commission = 28 KIIs

• Delegators' total revenue = 80% * 100 KIIs - Commission = 72 KIIs

Then, each delegator in the staking pool can claim their portion of the delegators' total revenue.

Requirements to be able to trade stablecoins on KIIEX, via dashboard or API:

• Have a user

• Have an account level 1 at least (to upgrade from level 0 to level 1, you need to complete our KYC verification inside your user settings)

• Have balances on any stablecoin

Endpoints

Staging URL :

https://apstage.proxy.kiiex.io/ap

Prod URL :

https://alphaprod.proxy.kiiex.io/ap

Swap Workflow example

For this example will assume a goal and specify what to do in order, also we'll provide you with all the endpoints related to each step. The goal is:

• Swap USDT → COPM using a market order.

Prerequisites

These are the prerequisites for the step-by-step guide.

1. Create your KIIEX account:

   1. Go to https://kiiex.io/ and click on login, and create your user

      1. You can also follow our guide on Set up your KIIEX Account

2. Update your account from level 0 to level 1 by following our KYC flow to be able to swap

3. Create your trader API Key on our panel to follow the next steps

Step-by-step

These are the steps to fully create a swap and withdraw it:

1. Authenticate your user via api

   1. Authenticate your User via API

2. Create a USDT deposit. If you have already created a deposit, check your current balance

   1. Create Deposit

   2. POST /GetAccountPositions

3. Get the current COPM/USDT rate

   1. Get Current Rate

4. Create market order (buy COPM)

   1. Create a SWAP

5. Verify order was filled

   1. Get SWAP status

6. Get trade details (swap info)

   1. POST /GetTradesHistory

7. Confirm the new COPM balance using the get account positions endpoint

   1. Get Account Balances

8. Create a COPM withdrawal, it could be to another wallet or to your bank account

   1. Create a Withdrawal

9. Check your COPM withdrawal status

   1. Check Withdrawal status

How do I perform the swap workflow using the API?

API endpoints

Authenticate your User via API

Create Deposit

Get Account Balances

Get Current Rate

Create a SWAP

Get SWAP status

Create a Withdrawal

Check Withdrawal status

What does it mean to become a KiiAmbassador?

Welcome to the KiiAmbassadors Program, our exclusive initiative to spotlight and reward the most committed voices in the KiiChain community.

This is not just a title — it's a role of influence and responsibility, for those who believe in our vision and want to help us grow the project both on-chain and online.

All information, tasks, and rewards are shared through the Private Ambassadors Channel on our official Discord.

You can apply to join the Ambassadors Program through the official KiiChain Discord (Official Links Channel):

KiiAmbassadors are selected community members who:

• Amplify our core messages on Twitter and other platforms.

• Stay active and helpful in Discord.

• Help bring new users to the chain and nurture the community spirit.

• Represent the KiiChain brand publicly, respectfully and consistently.

To be accepted into the program, you must:

• Have a good follower base and engagement level on social media.

• Follow KiiChain on X and be registered on the ORO Testnet.

Your core responsibilities

To maintain your role, we expect:

• Engage weekly in the Kii Discord, especially in public channels.

• React, share, and comment on KiiChain’s official posts on X.

• Participate in the weekly tasks, shared in the Ambassadors Channel.

• Help grow the community by inviting new users or explaining Kii to newcomers.

• Suggest strong candidates who could join the program in the future.

Participation perks

Ambassadors who complete tasks consistently and with high quality may receive:

• Rewards in $ORO and $KII.

• Monthly raffles for top ambassadors with USDT prizes.

• Shoutouts on our official socials and Discord.

• Access to exclusive giveaways.

• Special Q&A sessions with the KiiChain Core Team.

• Early access to new features, tools, and campaigns.

Points system and performance

To ensure fairness and reward real contribution, we have created a Points System to track all ambassador activities. Each action, such as retweeting, commenting, participating in Discord, creating original content, or attending events, will earn you points.

At the end of each month, top-performing ambassadors will be rewarded based on their accumulated points.

Our mod team will also share a weekly form where you can submit proof of your participation and activities, ensuring your points are correctly assigned.

In the table below, you can see how the points system is structured.

Rewards

Monthly Reward

• 2,000 USDT in Rewards for the Top Contributors of the Month. Climb the leaderboard and secure your reward.

• Every active ambassador is eligible to receive $300 USD worth of $KII per month, subject to the following conditions:

  • Publish at least 1 original post per week (e.g., thread, infographic, video).

  • Engage (like, retweet, and comment) with every official Kii post shared in the ambassador group.

  • Be active in public Discord channels with at least 3 helpful messages per week.

  • Complete and submit weekly tasks through our tracking system

Rewards are vested with a 3-month cliff followed by 18-month linear vesting, and are based on a $100M fully diluted valuation (FDV) for $KII.

Ambassador Incentives & Referral-Based Role System

The KiiAmbassadors program rewards not only consistency and engagement, but also your ability to grow the community by bringing in other qualified contributors.

We’ve created a referral-based role progression system, designed to reward ambassadors who actively expand the program with high-quality participants.

Role Progression Based on Referrals

For every 3 new KOLs (Key Opinion Leaders) you refer who are accepted into the program, your role is upgraded and you receive a bonus of $200 USD worth of $KII. This structure incentivizes high-quality referrals and gives ambassadors recognition as they grow the program. All bonuses follow the same vesting schedule as the base incentive (3-month cliff, 18-month linear vesting).

To remain active in the program, ambassadors are also required to publish at least 4 pieces of original content per month.

How to Qualify a Referral

To count as a valid referral:

• The referred KOL must follow KiiChain on X.

• They must join and be approved into the official Ambassador Discord server.

• The referral must be reported and verified by the Kii team.

How to lose the role

We reserve the right to revoke the role if:

• You spread FUD or attack the KiiChain project or team.

• You share scam links or break Discord’s rules.

• You leak confidential information or early announcements.

• You remain inactive without justification for a prolonged period.

• You repeatedly ignore or skip assigned tasks.

Evaluation process

Every 30 days, the KiiChain team will evaluate ambassador activity based on:

• Task completion

• Quality of participation

• Alignment with community values

Members who don’t meet the standards may be removed from the program to make room for new voices.

This program will evolve over time with new challenges, perks and surprises. Stay active, stay curious, and keep pushing KiiChain to new frontiers.

What are hardware requirements?

A modest level of hardware specifications is initially required and rises as network use increases. Participating in the testnet is the best way to learn more.

Validators are recommended to set up sentry nodes to protect your validator node from DDoS attacks.

What are software requirements?

Validators are expected to implement monitoring, alerting, and management solutions. There are several tools that you can use.

What are bandwidth requirements?

Kiichain has the capacity for very high throughput relative to chains like Dash, Ethereum or Bitcoin.

We recommend that the data center nodes connect only to trusted full nodes in the cloud or other validators that know each other socially. This connection strategy relieves the data center node from the burden of mitigating denial-of-service attacks.

Ultimately, as the network becomes more heavily used, multi-gigabyte per day bandwidth is very realistic.

How to handle key management?

Validators are expected to run an HSM that supports ed25519 keys. Here are potential options:

• YubiHSM 2

• Ledger Nano S

• Ledger BOLOS SGX enclave

• Thales nShield support

Kii Global nor the Interchain Foundation does not recommend one solution above the other. The community is encouraged to bolster the effort to improve HSMs and the security of key management.

What can validators expect in terms of operations?

Running an effective operation is key to avoiding unexpected unbonding or slashing. Operations must be able to respond to attacks and outages, as well as maintain security and isolation in the data center.

What are the maintenance requirements?

Validators are expected to perform regular software updates to accommodate chain upgrades and bug fixes. It is suggested to consider using to partially automate this process.

During an chain upgrade, progress is discussed in a private channel in the Kii Discord. If your validator is in the active set we encourage you to request access to that channel by contacting a moderator.

How can validators protect themselves from denial-of-service attacks?

Denial-of-service attacks occur when an attacker sends a flood of internet traffic to an IP address to prevent the server at the IP address from connecting to the internet.

An attacker scans the network, tries to learn the IP address of various validator nodes, and disconnects them from communication by flooding them with traffic.

One recommended way to mitigate these risks is for validators to carefully structure their network topology using a sentry node architecture.

Validator nodes are expected to connect only to full nodes they trust because they operate the full nodes themselves or the trust full nodes are run by other validators they know socially. A validator node is typically run in a data center. Most data centers provide direct links to the networks of major cloud providers. The validator can use those links to connect to sentry nodes in the cloud. This mitigation shifts the burden of denial-of-service from the validator's node directly to its sentry nodes, and can require that new sentry nodes are spun up or activated to mitigate attacks on existing ones.

Sentry nodes can be quickly spun up or change their IP addresses. Because the links to the sentry nodes are in private IP space, an internet-based attack cannot disturb them directly. This strategy ensures that validator block proposals and votes have a much higher chance to make it to the rest of the network.

For more sentry node details, see the or the on the forum.

Kiichain supports natively supports both CosmWasm and EVM smart contracts. Developers can choose between any of the two to create amazing dApps.

Working with Cosmwasm

Prerequisites

• Install Rust and CosmWasm toolchain:

• Create a new CosmWasm contract:

• Compile the contract:

Upload and Instantiate the Contract

1. Store the Contract

2. Instantiate the Contract

3. Execute the Contract

Working with EVM

Prerequisites

• Install Node.js and Hardhat:

• Install dependencies:

Write and Compile the Smart Contract

1. Create a Solidity file (MyContract.sol) in contracts/:

2. Compile the contract:

Deploy the Smart Contract

1. Create a deployment script (scripts/deploy.js):

2. Deploy to Kiichain:

Interact with the Deployed Contract

• Using Hardhat Console:

References

• CosmWasm Documentation:

• Ethereum Hardhat Guide:

Each validator candidate is encouraged to run its operations independently, as diverse setups increase the resilience of the network. Validator candidates should commence their setup phase now in order to be on time for launch.

Key Management - HSM

It is mission critical that an attacker cannot steal a validator's key. If this is possible, it puts the entire stake delegated to the compromised validator at risk. Hardware security modules are an important strategy for mitigating this risk.

HSM modules must support ed25519 signatures for the hub. The YubiHSM2 supports ed25519 and . The YubiHSM can protect a private key but cannot ensure in a secure setting that it won't sign the same block twice.

Sentry Nodes (DDOS Protection)

Validators are responsible for ensuring that the network can sustain denial of service attacks.

One recommended way to mitigate these risks is for validators to carefully structure their network topology in a so-called sentry node architecture.

Validator nodes should only connect to full-nodes they trust because they operate them themselves or are run by other validators they know socially. A validator node will typically run in a data center. Most data centers provide direct links to the networks of major cloud providers. The validator can use those links to connect to sentry nodes in the cloud. This shifts the burden of denial-of-service from the validator's node directly to its sentry nodes, and may require new sentry nodes be spun up or activated to mitigate attacks on existing ones.

Sentry nodes can be quickly spun up or change their IP addresses. Because the links to the sentry nodes are in private IP space, an internet-based attack cannot disturb them directly. This will ensure validator block proposals and votes always make it to the rest of the network.

To setup your sentry node architecture you can follow the instructions below:

Validators nodes should edit their config.toml:

Sentry Nodes should edit their config.toml:

Environment Variables

By default, uppercase environment variables with the following prefixes will replace lowercase command-line flags:

• GA (for Gaia flags)

• TM (for Tendermint/CometBFT flags)

• BC (for democli or basecli flags)

For example, the environment variable GA_CHAIN_ID will map to the command line flag --chain-id. Note that while explicit command-line flags will take precedence over environment variables, environment variables will take precedence over any of your configuration files. For this reason, it's imperative that you lock down your environment such that any critical parameters are defined as flags on the CLI or prevent modification of any environment variables.

@kiichain/kiijs-utils

Typescript library containing general utility functions for interacting with Kiichain.

Installation

Bech32 conversion

The package has utils to easen up conversion between hex and bech32 addresses. They can be used like this:

ETHSECP signer

Some wallets do not recognize the ETHSECP256-1 PubKey signatures. We made a couple helpers to utilize it without problems.

Signing a transaction

1. Create the SigningStargateClient with the correct type

The signing client must use a custom account parser to handle the ethsecp256k1 public key format. This is crucial for correctly signing transactions.

1. Sign the transaction with a custom pubkey

1. Broadcast the signed transaction

The EVM Module enables full Ethereum Virtual Machine compatibility within Kiichain, allowing developers to deploy and interact with Ethereum smart contracts using familiar tools like MetaMask, Remix, Hardhat, and Web3 libraries.

This module is built on top of the Cosmos EVM implementation.

Overview

The evm module provides:

• EVM Execution Environment within Cosmos-SDK

• Support for Ethereum JSON-RPC APIs

• Full Solidity smart contract compatibility

Available Messages and Transactions

The EVM module provides several messages and transactions that users and developers can utilize:​

Ethereum Transactions

• Submit Ethereum Transactions: Users can submit Ethereum-formatted transactions (MsgEthereumTx) to Kiichain, which are processed by the EVM module.​

CLI Commands

Kiichain offers command-line interface (CLI) commands for interacting with the EVM module:​

• Query Smart Contract Code:

kiichaind query evm code [address]
# Example:
kiichaind query evm code 0x7bf7b17da59880d9bcca24915679668db75f9397

• Query Storage:

kiichaind query evm storage [address] [key] [flags]
# Example:
kiichaind query evm storage 0x0f54f47bf9b8e317b214ccd6a7c3e38b893cd7f0 0 --height 0

• Submit Raw Ethereum Transaction:

kiichaind tx evm raw [tx_hex]
# Example:
kiichaind tx evm raw 0xf9ff74c86aefeb5f6019d77280bbb44fb695b4d45cfe97e6eed7acd62905f4a85034d5c68ed25a2e7a8eeb9baf1b84

JSON-RPC Support

Kiichain's EVM module exposes standard Ethereum JSON-RPC endpoints, allowing developers to interact with the blockchain using familiar methods:​

• eth_sendTransaction: Send a transaction

• eth_call: Call a smart contract function without making a state-changing transaction

• eth_estimateGas: Estimate the gas required for a transaction

• debug_traceTransaction: Trace the execution of a transaction for debugging purposes

And other general EVM JSON-RPC calls.

FeeMarket Module

The x/feemarket module implements a dynamic fee mechanism inspired by Ethereum's EIP-1559, enhancing transaction fee predictability and network efficiency.​

Key Concepts

• Base Fee: A global, per-block fee that adjusts based on network demand. It increases when blocks are above the gas target and decreases when below. Unlike Ethereum, where the base fee is burned, Kiichain allocates it for regular Cosmos SDK fee distribution.​

• Priority Tip: An optional fee that users can include to prioritize their transactions. While Cosmos SDK v0.46 lacks native transaction prioritization, this tip can still influence transaction inclusion.

• Effective Gas Price: Determined by the minimum of (baseFee + priorityTip) and gasFeeCap, ensuring users don't overpay for transactions.

• Minimum Gas Prices: Validators can set local minimum gas prices, and a global minimum can be established via governance. Transactions below these thresholds are discarded, mitigating spam

This module ensures a more stable and predictable fee structure, benefiting both users and validators.

ERC20

The x/erc20 module facilitates seamless, trustless conversion between Cosmos-native tokens and ERC-20 tokens, bridging the gap between the Cosmos and Ethereum ecosystems.

Key Concepts

• Bidirectional Conversion: Users can convert native Cosmos sdk.Coins to ERC-20 tokens and vice versa, enabling interoperability between different blockchain applications.

• Token Pair Registration: Mappings between Cosmos denominations and ERC-20 contract addresses, known as TokenPairs, are managed via governance proposals. This ensures controlled and secure token conversions.

• Use Cases

  • Utilize Cosmos assets (e.g., ATOM, OSMO) in Ethereum-based DeFi protocols.

  • Transfer ERC-20 tokens to Kiichain for use within the Cosmos ecosystem.

  • Enable applications that require ERC-20 standard tokens while leveraging Cosmos SDK features.

By supporting ERC-20 token standards, Kiichain enhances its interoperability, allowing for a broader range of decentralized applications and services.​

Token Factory

The tokenfactory module allows any account to create a new token with the name factory/{creator address}/{subdenom}. Because tokens are namespaced by creator address, this allows token minting to be permissionless, due to not needing to resolve name collisions. A single account can create multiple denoms, by providing a unique subdenom for each created denom. Once a denom is created, the original creator is given "admin" privileges over the asset.

This allows them to:

• Mint their denom to any account

• Burn their denom from any account

• Create a transfer of their denom between any two accounts

• Change the admin. In the future, more admin capabilities may be added. Admins can choose to share admin privileges with other accounts using the authz module. The ChangeAdmin functionality, allows changing the master admin account, or even setting it to "", meaning no account has admin privileges for the asset.

Messages

CreateDenom

Creates a denom factory/{creator address}/{subdenom} given the denom creator address and the subdenom. Subdenoms can contain [a-zA-Z0-9./].

message MsgCreateDenom {
  string sender = 1 [ (gogoproto.moretags) = "yaml:\"sender\"" ];
  string subdenom = 2 [ (gogoproto.moretags) = "yaml:\"subdenom\"" ];
}

State Modifications:

• Fund the community pool with the denom creation fee from the creator address, set in Params.

• Set DenomMetaData via the bank keeper.

• Set AuthorityMetadata for the given denom to store the admin for the created denom factory/{creator address}/{subdenom}. Admin is automatically set as the Msg sender.

• Add denom to the CreatorPrefixStore, where a state of denoms created per creator is kept.

Mint

Minting of a specific denom is only allowed for the current admin. Note, the current admin is defaulted to the creator of the denom.

message MsgMint {
  string sender = 1 [ (gogoproto.moretags) = "yaml:\"sender\"" ];
  cosmos.base.v1beta1.Coin amount = 2 [
    (gogoproto.moretags) = "yaml:\"amount\"",
    (gogoproto.nullable) = false
  ];
}

State Modifications:

• Safety check the following

  • Check that the denom minting is created via tokenfactory module

  • Check that the sender of the message is the admin of the denom

• Mint a designated amount of tokens for the denom via bank module

Burn

Burning of a specific denom is only allowed for the current admin. Note, the current admin is defaulted to the creator of the denom.

message MsgBurn {
  string sender = 1 [ (gogoproto.moretags) = "yaml:\"sender\"" ];
  cosmos.base.v1beta1.Coin amount = 2 [
    (gogoproto.moretags) = "yaml:\"amount\"",
    (gogoproto.nullable) = false
  ];
}

State Modifications:

• Safety check the following

  • Check that the denom minting is created via tokenfactory module

  • Check that the sender of the message is the admin of the denom

• Burn a designated amount of tokens for the denom via bank module

ChangeAdmin

Change the admin of a denom. Note, this is only allowed to be called by the current admin of the denom.

message MsgChangeAdmin {
  string sender = 1 [ (gogoproto.moretags) = "yaml:\"sender\"" ];
  string denom = 2 [ (gogoproto.moretags) = "yaml:\"denom\"" ];
  string newAdmin = 3 [ (gogoproto.moretags) = "yaml:\"new_admin\"" ];
}

SetDenomMetadata

Setting of metadata for a specific denom is only allowed for the admin of the denom. It allows the overwriting of the denom metadata in the bank module.

message MsgChangeAdmin {
  string sender = 1 [ (gogoproto.moretags) = "yaml:\"sender\"" ];
  cosmos.bank.v1beta1.Metadata metadata = 2 [ (gogoproto.moretags) = "yaml:\"metadata\"", (gogoproto.nullable)   = false ];
}

State Modifications:

• Check that the sender of the message is the admin of the denom

• Modify AuthorityMetadata state entry to change the admin of the denom

This will guide you through basic operations on how to maintain a validator.

What is a validator?

Validators are the ones responsible for committing blocks. Due to this responsibility, validators must run their own nodes and will be slashed if they become unavailable or sign blocks at the same height. Validators will also receive rewards for each block signed from fees.

Creating a validator

1. Key creation

To create a validator, you first must have a key available for transactions. A new key can be created with:

kiichaind keys add $VALIDATOR_KEY_NAME

You will get an output such as:

- address: kii105xft78q4wm565sn62chq4dxxvzq6uhqu0dawp
  name: "1234"
  pubkey: '{"@type":"/cosmos.evm.crypto.v1.ethsecp256k1.PubKey","key":"AxA37KswOGRQJ7R4JsDMbglhqh0TcPoiPEq/GCNZ1AJx"}'
  type: local


**Important** write this mnemonic phrase in a safe place.
It is the only way to recover your account if you ever forget your password.

mom half sting horn fashion pizza citizen lonely random february knee miss vibrant peasant among pool suffer street alert eager notable net leave wrestle

1. Transfer funds

Ensure your account has sufficient funds for fees and self-delegation.

1. Create the validator

A validator will be created based on your consensus public key. You can check your current public key using:

kiichaind tendermint show-validator

To create a validator you can use the following command:

# Basic chain information
CHAIN_ID="oro_1336-1"

# Define the validator information
MONIKER=<my-moniker>
AMOUNT=1000000000000000000000akii # 1000 kii as self delegation
COMMISSION_MAX_CHANGE_RATE=0.1
COMMISSION_MAX_RATE=0.1
COMMISSION_RATE=0.1
MIN_SELF_DELEGATION_AMOUNT=1000000000000000000

kiichaind tx staking create-validator \
  --amount=$AMOUNT \
  --pubkey=$(kiichaind tendermint show-validator) \
  --moniker=$MONIKER \
  --chain-id=$CHAIN_ID \
  --commission-rate=$COMMISSION_RATE \
  --commission-max-rate=$COMMISSION_MAX_RATE \
  --commission-max-change-rate=$COMMISSION_MAX_CHANGE_RATE \
  --min-self-delegation=$MIN_SELF_DELEGATION_AMOUNT \
  --gas="auto" \
  --gas-adjustment 1.3 \
  --gas-prices="1000000000akii" \
  --from=$VALIDATOR_KEY_NAME

Further instructions on how to run a validator can be found at Running a Validator.

Edit validator description

At any moment, you can update your validator public description. This description is public and is what will be shown on block explorers.

To update your delegator information you can use:

kiichaind tx staking edit-validator
  --moniker="Any moniker" \
  --website="https://kii.network" \
  --identity=6A0D65E29A4CBC8E \
  --details="Delegate on my awesome kii validator!" \
  --chain-id=<chain_id> \
  --gas="auto" \
  --gas-adjustment 1.3 \
  --gas-prices="1000000000akii" \
  --from=<key_name> \
  --commission-rate="0.10"

Where:

• --from must be the operator of the validator

• --identity can be used as to verify identity with systems like Keybase or UPort

• --commission-ratemust follow these rules:

  • Must be between 0 and the validator's commission-max-rate

  • Must not exceed the validator's commission-max-change-rate which is maximum % point change rate per day.

Unjail Validator

Your validator may get jailed for downtime. To unjail your validator you must use the following transaction:

kiichaind tx slashing unjail \
 --from=<key_name> \
 --chain-id=<chain_id>
 --gas="auto" \
 --gas-prices="1000000000akii"

Halting Your Validator

You may want to halt your validator for maintenance or a coordinated upgrade. You can gracefully halt your validator by setting it halt-heightto the height you want to pause your validator. The node will shutdown with a zero exit code at that given height after committing the block.

Note: This project is still under development so future changes will be made.

Important Links

• Github RWA Repo

• Rust SDK Repo

KiiChain RWA SDK

The RWA (Real World Asset) SDK is a Rust library for interacting with tokenized real-world assets on Cosmos-based blockchains. It provides functionality for token operations, identity management, and compliance handling.

Features

• Token transfers and balance checks

• Identity registration and management

• Compliance module integration

• Blockchain interaction via RPC

Usage Example

use rwa_sdk::RwaClient;
use cosmrs::crypto::secp256k1::SigningKey;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    // Initialize the client
    let client = RwaClient::new(
        "http://rpc.example.com:26657",
        "my-chain-id",
        "cosmos1token...",
        "cosmos1identity...",
        "cosmos1compliance...",
        "sei",
        "gas_price"

    )?;

    // Perform a token transfer
    let signer = SigningKey::from_slice(&[/* your private key */])?;
    let transfer_result = client.transfer(TransferMessageRequest {
        from: "cosmos1sender...".to_string(),
        to: "cosmos1recipient...".to_string(),
        amount: 100,
        signer,
        gas_limit
    }).await?;
    println!("Transfer hash: {}", transfer_result.hash);

    // Check a balance
    let balance = client.balance(TokenInfoRequest {
        address: "cosmos1address...".to_string(),
    }).await?;
    println!("Balance: {}", balance.balance);

    Ok(())
}

This example demonstrates how to initialize the RwaClient, perform a token transfer, and check an account balance. Error handling and proper setup of the signing key are crucial for production use.

For more detailed information on each function and module, please refer to their respective documentation.

What is the incentive to stake?

Each member of a validator's staking pool earns different types of revenue:

• Block rewards: Native tokens of applications (eg. KII) run by validators are inflated to produce block provisions. These provisions exist to incentivize KII holders to bond their stake. Non-bonded KII are diluted over time.

• Transaction fees: The only fee token of Kiichain is the KII.

This total revenue is divided among validators' staking pools according to each validator's weight. Then, within each validator's staking pool the revenue is divided among delegators in proportion to each delegator's stake. A commission on delegators' revenue is applied by the validator before it is distributed.

What is a validator commission?

Revenue received by a validator's pool is split between the validator and their delegators. The validator can apply a commission on the part of the revenue that goes to their delegators. This commission is set as a percentage. Each validator is free to set their initial commission, maximum daily commission change rate, and maximum commission. Kii Global enforces the parameter that each validator sets. The maximum commission rate is fixed and cannot be changed. However, the commission rate itself can be changed after the validator is created as long as it does not exceed the maximum commission.

What is the incentive to run a validator?

Validators earn proportionally more revenue than their delegators because of the commission they take on the staking rewards from their delegators.

Validators also play a major role in governance. If a delegator does not vote, they inherit the vote from their validator. This voting inheritance gives validators a major responsibility in the ecosystem. Kiichain will migrate to open governance after launch.

How are block rewards distributed?

Block rewards are distributed proportionally to all validators relative to their voting power. This means that even though each validator gains ATOM with each reward, all validators maintain equal weight over time.

For example, 10 validators have equal voting power and a commission rate of 1%. For this example, the reward for a block is 1000 KII and each validator has 20% of self-bonded KII. These tokens do not go directly to the proposer. Instead, the tokens are evenly spread among validators. So now each validator's pool has 100 KII. These 100 KII are distributed according to each participant's stake:

• Commission: 100*80%*1% = 0.8 KII

• Validator gets: 100\*20% + Commission = 20.8 KII

• All delegators get: 100\*80% - Commission = 79.2 KII

Then, each delegator can claim their part of the 79.2 KII in proportion to their stake in the validator's staking pool.

How are fees distributed?

Fees are similarly distributed with the exception that the block proposer can get a bonus on the fees of the block they propose if the proposer includes more than the strict minimum of required precommits.

When a validator is selected to propose the next block, the validator must include at least 2/3 precommits of the previous block. However, an incentive to include more than 2/3 precommits is a bonus. The bonus is linear: it ranges from 1% if the proposer includes 2/3rd precommits (minimum for the block to be valid) to 5% if the proposer includes 100% precommits. Of course the proposer must not wait too long or other validators may timeout and move on to the next proposer. As such, validators have to find a balance between wait-time to get the most signatures and risk of losing out on proposing the next block. This mechanism aims to incentivize non-empty block proposals, better networking between validators, and mitigates censorship.

For a concrete example to illustrate the aforementioned concept, there are 10 validators with equal stake. Each validator applies a 1% commission rate and has 20% of self-delegated KII. Now comes a successful block that collects a total of 1025.51020408 KII in fees.

First, a 2% tax is applied. The corresponding KII go to the reserve pool. The reserve pool's funds can be allocated through governance to fund bounties and upgrades.

• 2% * 1025.51020408 = 20.51020408 KII go to the reserve pool.

1005 KII now remain. For this example, the proposer included 100% of the signatures in its block so the proposer obtains the full bonus of 5%.

To solve this simple equation to find the reward R for each validator:

9*R + R + R*5% = 1005 ⇔ R = 1005/10.05 = 100

• For the proposer validator:

  • The pool obtains R + R * 5%: 105 KII

  • Commission: 105 * 80% * 1% = 0.84 KII

  • Validator's reward: 105 * 20% + Commission = 21.84 KII

  • Delegators' rewards: 105 * 80% - Commission = 83.16 KII (each delegator is able to claim its portion of these rewards in proportion to their stake)

• For each non-proposer validator:

  • The pool obtains R: 100 KII

  • Commission: 100 * 80% * 1% = 0.8 KII

  • Validator's reward: 100 * 20% + Commission = 20.8 KII

  • Delegators' rewards: 100 * 80% - Commission = 79.2 KII (each delegator is able to claim their portion of these rewards in proportion to their stake)

What are the slashing conditions?

If a validator misbehaves, their delegated stake is partially slashed. Two faults can result in slashing of funds for a validator and their delegators:

• Double signing: If someone reports on chain A that a validator signed two blocks at the same height on chain A and chain B, and if chain A and chain B share a common ancestor, then this validator gets slashed by 5% on chain A.

• Downtime: If a validator misses more than 95% of the last 10,000 blocks (roughly ~19 hours), they are slashed by 0.01%.

Are validators required to self-delegate KII?

No, they do not need to self-delegate. Even though there is no obligation for validators to self-delegate, delegators may want their validator to have self-delegated KII in their staking pool. In other words, validators share the risk.

Note however that it's possible that some validators decide to self-delegate via a different address for security reasons.

How to prevent concentration of stake in the hands of a few top validators?

The community is expected to behave in a smart and self-preserving way. When a mining pool in Bitcoin gets too much mining power the community usually stops contributing to that pool. Kiichain relies on the same effect. Additionally, when delegators switch to another validator, they are not subject to the unbonding period, which removes any barrier to quickly redelegating tokens in service of improving decentralization.

The configuration followed before, set your node as a full node, this page will guide you to upgrade your node into a validator.

Becoming a validator

Validators are mainly responsible

• The build must be done on top of the upgrade tag (E.g. v1.0.1, v2.0.0)

• Check the section on how to do it

Make sure that the binary has the correct version with:

To add a new upgrade you must run the following command on Cosmovisor:

Where:

• <upgrade-name> is the on-chain upgrade name

• <path-to-binary> is the full path for the binary

Example:

validating and committing blocks. The main advantages of becoming a validator are:

• Fees. Each transaction has fees, and validators are the main entry points of fee distribution. And due to his help on decentralization, part of the fee is exclusive for validators.

Creating a validator

1. Key creation

To create a validator, you first must have a key available for transactions. A new key can be created with:

You will get an output such as:

1. Transfer funds

Ensure your account has sufficient funds for fees and self-delegation.

1. Create the validator

A validator will be created based on your consensus public key. You can check your current public key using:

To create a validator, first you will need to create a JSON with your validator information.

This template can be used when creating the validator:

Where:

• pubkey : Validator's public key used for signing blocks (ed25519).

• amount: Amount of tokens to self-delegate (e.g., 1000 akii with 18 decimals).

• moniker: Validator's display name.

• identity (optional): Identity string (e.g., Keybase or UPort for verification).

• website (optional): Validator’s website URL.

• security (optional): Security contact email for incident disclosure.

• details (optional): Additional description of the validator.

• commission-rate :Initial commission rate (e.g., 0.1 = 10%).

• commission-max-rate: Maximum commission rate allowed (e.g., 20%).

• commission-max-change-rate: Max daily change in commission (e.g., 1%).

• min-self-delegation: Minimum tokens validator must always self-delegate to stay active.

To apply, you can use the following command:

Further instructions on how to run a validator can be found at .

It's always nice to see new users onboarding into the Testnet Oro.

This will guide you through the process of running your own full node, then and finally running

Install

kiichaind is the command-line interface (CLI) for interacting with the Kiichain blockchain. This section covers the installation of the necessary binaries to run a Kiichain node.

Requirements

• Golang version: v1.23.x

• Build tools: build-essential package (Linux)

Binary installation

To install Kiichain, download the pre-built binaries:

Verify the installation by checking the version of kiichaind:

Joining the Testnet

To join the Testnet Oro, you must have the daemon kiichaind installed in your machine.

Recommended configuration

For optimal performance, we recommend:

• 4 vCPU x86_64

• 8 GB RAM

• 1 TB NVME SSD

Quick bootstrap

The easiest way to prepare a node is by using our provided scripts.

• Join Testnet Oro Script: Use this script to bootstrap a full node quickly.

• Join Testnet with Cosmosvisor Script: Use this script to set up a full node with Cosmosvisor for automated upgrades

Running your node

Prepare your system by backing up and removing old configurations:

Connect to the testnet with the following commands:

(Optional but recommended): Before running the chain you can also check the SHA256:

The expected SHA256 checksum is: 2805ae1752dc8c3435afd6bdceea929b3bbd2883606f3f3589f4d62c99156d2d

Cosmosvisor

Cosmosvisor is a process manager for handling chain upgrades. It enables low maintenance and automatic updates for nodes.

• If an upgrade is scheduled, cosmosvisor has the capability of automatically downloading binaries and restarting any Kiichain processes

• This gives the node low maintenance and auto updates capabilities

A version of our node bootstrapper can install cosmosvisor for you:

More information about cosmovision can be found at .

Preparing cosmosvisor upgrade

First, you need to compile new binaries:

• A new Kiichaind binary must be compiled with the target OS in mind

• Ideally, you should compile all binaries on it’s own machines

• The build must be done on top of the upgrade tag (E.g. v1.0.1, v2.0.0)

• Check the section on how to do it

Make sure that the binary has the correct version with:

To add a new upgrade you must run the following command on Cosmovisor:

Where:

• <upgrade-name> is the on-chain upgrade name

• <path-to-binary> is the full path for the binary

Example:

Configure state sync

State sync significantly reduces the time required to synchronize a node by downloading and verifying state data from trusted peers rather than replaying every historical block. This is particularly beneficial for nodes joining the network late or recovering from a significant downtime.

Follow these steps to configure state sync for your Kiichain node:

1. Set Trust Height Delta and Fetch Block Information

Define a height delta and retrieve the latest block height and block hash from the primary RPC endpoint.

1. Enable State Sync in Configuration

Modify the config.toml file to enable state sync and set the required parameters.

Turning your node into an archival node

Newly created nodes have the pruning option configured as default. If you desire to turn your node into an archival node, the following flag must be changed:

1. Go to $NODE_HOME/config/app.tomland update the following flag:

Other options available as default for pruning are:

• default: Keep the recent 362880 blocks and prune is triggered every 10 blocks

• nothing: all historic states will be saved, and nothing will be deleted (i.e. archiving node)

• everything: all saved states will be deleted, storing only the recent 2 blocks; pruning at every block

• custom: allow pruning options to be manually specified through 'pruning-keep-recent' and 'pruning-interval'

Node Architecture for Validators

Further instructions on how to build a great node architecture can be found on:

References

Note: This project is still under development so future changes will be made.

Overview

This document outlines the detailed implementation plan for the T-REX (Token for Regulated EXchanges) protocol using CosmWasm smart contracts on KiiChain. The T-REX protocol is designed for compliant issuance and management of security tokens on blockchain networks.

Important Links

• GitHub Repo

• Rust SDK

Contracts and Their Methods

1. CW20 T-REX Token

Extends the CW20 standard with T-REX functionalities and implements permissioned transfers.

Storage

• token_info: TokenInfo

• balances: Map<Addr, Uint128>

• allowances: Map<(Addr, Addr), AllowanceInfo>

• identity_registry: Addr

• compliance: Addr

Execute

• transfer(recipient: Addr, amount: Uint128) -> Result<Response>

  • Description: Transfers tokens to a recipient if they are verified and compliant.

  • Interaction: Calls is_verified on Identity Registry and can_transfer on Modular Compliance.

• transfer_from(owner: Addr, recipient: Addr, amount: Uint128) -> Result<Response>

  • Description: Transfers tokens on behalf of the owner if the recipient is verified and compliant.

  • Interaction: Similar to transfer, but checks allowances first.

Query

• balance(address: Addr) -> BalanceResponse

• token_info() -> TokenInfoResponse

• is_verified_transfer(from: Addr, to: Addr, amount: Uint128) -> IsVerifiedTransferResponse

  • Description: Checks if a transfer would be valid without executing it.

  • Interaction: Calls Identity Registry and Modular Compliance.

2. Identity Registry

Manages investor identities and eligibility.

Storage

• identity_storage: Addr

• trusted_issuers_registry: Addr

• claim_topics_registry: Addr

• agents: Vec

Execute

• register_identity(address: Addr, identity: Addr) -> Result<Response>

  • Description: Registers a new identity for an address.

  • Interaction: Calls Identity Registry Storage to store the mapping.

• update_identity(address: Addr, identity: Addr) -> Result<Response>

  • Description: Updates an existing identity for an address.

• remove_identity(address: Addr) -> Result<Response>

  • Description: Removes an identity for an address.

Query

• is_verified(address: Addr) -> IsVerifiedResponse

  • Description: Checks if an address is verified (has required claims).

  • Interaction: Queries Identity Registry Storage, Trusted Issuers Registry, and Claim Topics Registry.

3. Identity Registry Storage

Stores the mapping of wallet addresses to identity contracts.

Storage

• identities: Map<Addr, Addr>

Execute

• add_identity(address: Addr, identity: Addr) -> Result<Response>

• remove_identity(address: Addr) -> Result<Response>

Query

• get_identity(address: Addr) -> GetIdentityResponse

4. Trusted Issuers Registry

Manages the list of trusted claim issuers.

Storage

• trusted_issuers: Map<Addr, TrustedIssuer>

Execute

• add_trusted_issuer(issuer: Addr, claim_topics: Vec<u32>) -> Result<Response>

• remove_trusted_issuer(issuer: Addr) -> Result<Response>

Query

• is_trusted_issuer(issuer: Addr) -> IsTrustedIssuerResponse

• get_trusted_issuers() -> GetTrustedIssuersResponse

5. Claim Topics Registry

Stores the required claim topics for token eligibility.

Storage

• required_claim_topics: Vec

Execute

• add_claim_topic(topic: u32) -> Result<Response>

• remove_claim_topic(topic: u32) -> Result<Response>

Query

• get_required_claim_topics() -> GetRequiredClaimTopicsResponse

6. Modular Compliance

Implements transfer restriction rules.

Storage

• modules: Vec

• bound_tokens: Vec

Execute

• add_module(module: Addr) -> Result<Response>

• remove_module(module: Addr) -> Result<Response>

• bind_token(token: Addr) -> Result<Response>

Query

• can_transfer(from: Addr, to: Addr, amount: Uint128) -> CanTransferResponse

  • Description: Checks if a transfer complies with all modules.

  • Interaction: Calls check_transfer on each compliance module.

7. ONCHAINID

Represents user identities (similar to ERC-734/735).

Storage

• keys: Map<bytes32, Key>

• claims: Map<bytes32, Claim>

Execute

• add_key(key: bytes32, purpose: u32, key_type: u32) -> Result<Response>

• remove_key(key: bytes32) -> Result<Response>

• add_claim(topic: u32, scheme: u32, issuer: Addr, signature: Vec<u8>, data: Vec<u8>, uri: String) -> Result<Response>

• remove_claim(topic: u32) -> Result<Response>

Query

• get_key(key: bytes32) -> GetKeyResponse

• get_claim(topic: u32) -> GetClaimResponse

8. T-REX Factory

Deploys and configures T-REX token suites.

Storage

• implementation_authority: Addr

• deployed_tokens: Vec

Execute

• deploy_token_suite(token_info: TokenInfo, compliance_info: ComplianceInfo, identity_info: IdentityInfo) -> Result<Response>

  • Description: Deploys a new T-REX token suite.

  • Interaction: Instantiates all necessary contracts and configures them.

Query

• get_deployed_tokens() -> GetDeployedTokensResponse

9. Implementation Authority

Manages contract upgrades and versioning.

Storage

• versions: Map<String, ContractVersion>

• current_version: String

Execute

• add_version(name: String, contracts: Vec<(String, Addr)>) -> Result<Response>

• set_current_version(name: String) -> Result<Response>

Query

• get_current_version() -> GetCurrentVersionResponse

• get_version(name: String) -> GetVersionResponse

Implementation Roadmap

1. Implement CW20 T-REX Token

2. Implement Identity Registry and Identity Registry Storage

3. Implement Trusted Issuers Registry and Claim Topics Registry

4. Implement Modular Compliance

5. Implement ONCHAINID

6. Implement T-REX Factory

7. Implement Implementation Authority

8. Integrate all contracts and perform thorough testing

9. Conduct security audit

10. Deploy to Kii-Chain testnet

11. Final testing and adjustments

12. Deploy to Kii-Chain mainnet

Testing Strategy

• Implement unit tests for each contract function

• Develop integration tests for contract interactions

• Create end-to-end scenarios to test the entire T-REX suite

• Perform fuzz testing to uncover edge cases

• Conduct governance testing to ensure proper access control

@kiichain/kiijs-evm

install

Usage

You can utilize the types to build and send messages. To query, you can utilize an RPC query client, while for transactions you will need a wallet client paired with composing a message and then broadcasting it.

RPC Clients

To create an RPC client you can import the following helper and utilize it:

Explore the types to find out what types of queries are available and how to utilized them.

Composing Messages

To compose messages, you can utilize the message composer of the respective type you want to build. For instance, tokenfactory messages can be found like this:

We have a small section with a few more examples.

Cosmos Messages

Connecting with Wallets and Signing Messages

⚡️ For web interfaces, we recommend using . Continue below to see how to manually construct signers and clients.

Here are the docs on in cosmos-kit that can be used with Keplr and other wallets.

Initializing the Stargate Client

Use getSigningKiiChainClient to get your SigningStargateClient, with the proto/amino messages full-loaded. No need to manually add amino types, just require and initialize the client:

Creating Signers

To broadcast messages, you can create signers with a variety of options:

• (recommended)

Amino Signer

Likely you'll want to use the Amino, so unless you need proto, you should use this one:

Proto Signer

WARNING: NOT RECOMMENDED TO USE PLAIN-TEXT MNEMONICS. Please take care of your security and use best practices such as AES encryption and/or methods from 12factor applications.

Broadcasting Messages

Now that you have your stargateClient, you can broadcast messages:

Converting from Hex to Bech32 and vice-versa

We have a few helper functions for converting Hex to Bech32 and vice versa on the @kiichain/kiijs-evm. We did not import them over here since the proto files are all generated.

Advanced Usage

If you want to manually construct a stargate client

The Oracle module brings up price feeds and exchange rates to Kiichain.

• It allows validators to submit price data, which can be used by other modules or smart contracts (EVM and Wasm).

• It supports multiple price feeds, allowing for a diverse set of data sources

• It provides a mechanism for price data to be aggregated and made available on-chain

Price feeder

Our official implementation for the price feeder is available at Kiichain Price Feeder.

• The price must be ran by a validator or a delegated address

• The price feeder is responsible for submitting the price data to the Oracle module

• More information can be found at the project readme

Core functionality

The Oracle module works as follows:

• Validators submit price data for arbitrary assets, which are defined in the module params

• The module aggregates the price data submitted by validators and calculates a final exchange rate for each asset

• The final exchange rate is stored on-chain and can be queried by other modules or smart contracts

The Exchange Vote is done as following:

1. A new block is created

2. Validators submit their votes for the price of each asset in the whitelist through the MsgExchangeRateVote message

• This message is feeless as long as its the first vote for the validator in the current voting period

• The vote can be submitted by the validator itself or a delegated address (feeder address)

  • By using a delegated address, validators can separate their voting actions from their staking address

1. The module aggregates the votes and calculates the final exchange rate for each asset

2. If no vote is submitted by a validator in the current voting period, the module will slash the validator's stake according to the slash_fraction parameter

3. The final exchange rate is stored on-chain and can be queried by other modules or smart contracts

State

These are the most important state types used by the Oracle module:

Params

Params stores the module wide configuration. Its defined as:

// Params defines the parameters for the module
message Params {
    option (gogoproto.equal)            = true;
    option (gogoproto.goproto_stringer) = false; // Allow custom logs

    // The number of blocks per voting
    uint64 vote_period =1 [(gogoproto.moretags) = "yaml:\"vote_period\""];

    // Minimum percentage of validators required to approve a price. For instance, if vote_threshold = "0.5" at least 50% of validators must submit votes
    // "cosmossdk.io/math.LegacyDec" = Cosmos SDK decimal data type
    string vote_threshold = 2 [
        (gogoproto.moretags) = "yaml:\"vote_threshold\"",
        (gogoproto.customtype) = "cosmossdk.io/math.LegacyDec",
        (gogoproto.nullable) = false
    ];

    // Acceptable deviation from the media price (higher and lower)
    // "cosmossdk.io/math.LegacyDec" = Cosmos SDK decimal data type
    string reward_band = 3 [
        (gogoproto.moretags) = "yaml:\"reward_band\"",
        (gogoproto.customtype) = "cosmossdk.io/math.LegacyDec",
        (gogoproto.nullable) = false
    ];

    // List of allowed assets
    // DenomList is a custom data type, defined on x/oracle/types/denom.go
    repeated Denom whitelist = 4 [
        (gogoproto.moretags) = "yaml:\"whitelist\"",
        (gogoproto.castrepeated) = "DenomList",
        (gogoproto.nullable) = false
    ];

    // How much stake is slashed if a validator fails to submit votes
    // "cosmossdk.io/math.LegacyDec" = Cosmos SDK decimal data type
    string slash_fraction = 5 [
        (gogoproto.moretags) = "yaml:\"slash_fraction\"",
        (gogoproto.customtype) = "cosmossdk.io/math.LegacyDec",
        (gogoproto.nullable) = false
    ];

    // Define the window (in blocks) to vote, if not receive penalties due to bad performance
    uint64 slash_window = 6 [(gogoproto.moretags) = "yaml:\"slash_window\""];

    // Minimum percentage of voting on windows to avoid slashing. For instance, if min_valid_per_window = 0.8, then a validator must submit votes in 80% of windows to avoid slashing
    // "cosmossdk.io/math.LegacyDec" = Cosmos SDK decimal data type
    string min_valid_per_window = 7 [
        (gogoproto.moretags) = "yaml:\"min_valid_per_window\"",
        (gogoproto.customtype) = "cosmossdk.io/math.LegacyDec",
        (gogoproto.nullable) = false
    ];

    // How far back (in blocks) the module can compute historical price metrics
    uint64 lookback_duration = 9 [(gogoproto.moretags) = "yaml:\"lookback_duration\""];
}

Exchange Rates

Exchange rates are the single entry for a price data on the chain. Its stored as a Key-Value pair in the store, where the key is the asset denom and the value is the price data.

The price data is defined as:

// Data type that stores the final calculated exchange rate after all votes were
// aggregated to that single exchange, record the last block height and timestamp when rate was updated
message OracleExchangeRate {
    option (gogoproto.equal)            = false;
    option (gogoproto.goproto_getters)  = false;
    option (gogoproto.goproto_stringer) = false;

    string exchange_rate = 1 [
        (gogoproto.moretags)   = "yaml:\"exchange_rate\"",
        (gogoproto.customtype) = "cosmossdk.io/math.LegacyDec",
        (gogoproto.nullable)   = false
    ];

    string last_update = 2 [
        (gogoproto.moretags)   = "yaml:\"last_update\"",
        (gogoproto.customtype) = "cosmossdk.io/math.Int",
        (gogoproto.nullable)   = false
    ];

    int64 last_update_timestamp = 3 [(gogoproto.moretags)   = "yaml:\"last_update_timestamp\""];
}

FeederDelegation

Feeder delegations is the correlation between a validator and a feeder address. It allows validators to use a different address to submit votes.

The FeederDelegation is defined as:

// FeederDelegation is the structure on the genesis regarding the delegation process
message FeederDelegation {
  // feeder_address is the address delegated
  string feeder_address    = 1;

  // validator_address is the validator's address who delegate its voting action
  string validator_address = 2;
}

Messages

The Oracle module expose the following messages:

AggregateExchangeRateVote

The MsgAggregateExchangeRateVote message is used by validators to submit their votes for the price of each asset in the whitelist. It contains the following fields:

// MsgAggregateExchangeRateVote represent the message to submit
// an aggregate exchange rate vote
message MsgAggregateExchangeRateVote{
  option (gogoproto.equal)           = false;
  option (gogoproto.goproto_getters) = false;

  option (cosmos.msg.v1.signer) = "feeder";
  option (amino.name) = "oracle/aggregate-exchange-rate-vote";

  string exchange_rates = 1 [(gogoproto.moretags) = "yaml:\"exchange_rates\""];
  string feeder = 2 [(gogoproto.moretags) = "yaml:\"feeder\""];
  string validator = 3 [(gogoproto.moretags) = "yaml:\"validator\""];
}

DelegateFeedConsent

The MsgDelegateFeedConsent message is used to delegate the right to submit votes to a different address. The message contains the following fields:

// MsgDelegateFeedConsent represents a message to delegate oracle voting
// rights to another address
message MsgDelegateFeedConsent{
  option (gogoproto.equal)           = false;
  option (gogoproto.goproto_getters) = false;

  option (cosmos.msg.v1.signer) = "validator_owner";
  option (amino.name) = "oracle/delegate-feed-consent";

  string validator_owner = 1 [(gogoproto.moretags) = "yaml:\"validator_owner\""];
  string delegate = 2 [(gogoproto.moretags) = "yaml:\"delegate\""];
}

UpdateParams

The MsgUpdateParams message is used to update the module parameters. Only the governance module can call the message. It contains the following fields:

// MsgUpdateParams is the Msg/UpdateParams request type
message MsgUpdateParams {
  option (cosmos.msg.v1.signer) = "authority";

  // authority is the address that controls the module (defaults to x/gov)
  string authority    = 1 [(cosmos_proto.scalar) = "cosmos.AddressString"];
  option (amino.name) = "kiichain/x/oracle/MsgUpdateParams";

  // params defines the x/oracle parameters to update
  //
  // NOTE: All parameters must be supplied.
  Params params = 2 [(gogoproto.nullable) = false, (amino.dont_omitempty) = true];
}

Begin block

On each ABCI call, the Oracle module performs the following actions:

1. Check if we are under a new slash window

2. Check the slash counters for validators and slash them if they didn't submit enough votes in the previous voting period

3. Remove the excess feeds

End block

At the end of each block, the Oracle module performs the following actions:

1. Check if we are under a new voting period

2. Iterate the votes

3. Calculate the final exchange rate for each asset in the whitelist

4. Store the final exchange rate on-chain

Ante handler

The Oracle module ignores fees from validators on their first vote in the current voting period. The following is done:

1. Check if the message is a MsgAggregateExchangeRateVote

2. Check the validator/feeder relationship

3. If the validator is voting for the first time in the current voting period, ignore the fees

Acknowledgments

Special thanks to the SEI team. Your contributions to the Cosmos SDK ecosystem are greatly appreciated. The original implementation of the Oracle module can be found in the SEI repository