Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Endpoints for Testnet Oro
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Description of all the custom modules that makes Kiichain work
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Where we've been and where we're going.
Inception. Internal building. OTC trading.
Q1: KiiChain Dev Net.
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.
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.
Q1 & Q2:
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.
Q2: KIIEX build started from our OTC operation to scalable technology ().
Q4: Kii Mobile wallet was developed for version 1 of testnet ().
Q1: KiiChain Testnet V1 was developed and launched with the cosmos SDK ().
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 ().
Incentivized testnet, XP and Oro rewards, featuring on-chain tasks and partnerships ().
Kii Global activity will be driven through its suite of revenue generating products. We make this information clear so users can better understand our vision with our evergreen staking model.
By inaugurating our proprietary centralized exchange platform, we're revolutionizing the remittance and payment experience for users. This nexus of cryptocurrency trading ensures seamless transactions, all while fostering an environment of growth and financial prosperity. KIIEX leads the market for cash-in/cash-out options in Latam.
Our homegrown multi-currency decentralized wallet offers users a secure haven for their assets. Nominal trading and transfer fees not only ensure affordability for our users but also serve as a sustainable revenue stream for the KII ecosystem. This wallet, attuned to user needs, exemplifies the blend of security, functionality, and cost-efficiency, becoming an indispensable tool for every crypto enthusiast.
Users will pay for block time in native token to run the AI models. A percentage of those fees will be collected by Kii Global.
5% of total supply is for posting liquidity to DEX operations, and after the public sale, that 5% will be matched in liquidity on the other side of the trade. These trades will produce revenue for the holding company.
Our footprint in the blockchain space hasn't gone unnoticed. By integrating KII's robust ecosystem into conventional fintech enterprises, we've forged a revenue model wherein we glean a slice of every transaction made through our infrastructural offerings.
Apart from the main revenue streams, Kii Global roadmap entails launching a suite of banking-as-a-service products like cold storage processing cards which will further produce earnings for the company.
Use cases are economy-centric, real world models currently in use. Kii is developing technological solutions to solve the current problems within each niche.
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.
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.
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.
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.
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.
High yield opportunities are plentiful in Latam, and can help generate this productive yield for yield farming aggregators to offer to lenders with liquidity.
Upon block number 1, KiiChain can process 12,000 transactions per second (TPS) and can scale within the Cosmos ecosystem with IBC. Currently the Cosmos community is collectively synced to process ~500,000 TPS, and depending on the inclusion of future layer 1s, processing can increase to an infinite number. Transaction fees in KiiChain are a fraction of a peso and settlement is instantaneous. Users can seamlessly remit funds to any wallet in the world.
The B2B remittance market transacts over $600 billion USD. 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.
KiiChain has a fixed supply 1,800,000,000 KII with no minting or burning of tokens. Therefore, the total amount can never be inflated. In fact, on the contract, 5% of cash flow from operations of Kii Global will be reverted back to purchasing Kii and replenishing the staking and rewards pool.
Additionally, KiiChain integrates cross-chain bridging software that allows dollar-denominated or alternative "inflation protection" assets and stablecoins to be deployed natively to the network.
KiiChain is the first layer 1 AppChain built for emerging markets. KiiChain empowers users, developers and businesses who are building the future of finance in emerging markets.
KiiChain is a layer 1 blockchain built with the Cosmos SDK. 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 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.
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.
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.
The Sei 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. Essentially, Sei EVM runs an Ethereum-compatible virtual machine side chain that mirrors address balances between EVM and Cosmwasm tokens. Thanks to its modular, plugin-based design, it allows any host blockchain to execute Ethereum transactions and smart contracts.
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 (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 .
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 .
The use cases are strong only if real world problems are being solved. KII is redesigning financial architecture to solve current industry problems within its geographical focus.
Emerging markets historically suffer from high inflation, high interest rates, and less access to institutional lending. Tokenization of RWA is focused on solving traditional and emerging use cases:
Accessibility via Fractional Ownership: Emerging markets often lack the infrastructure for widespread investment opportunities. Tokenization enables fractional ownership, allowing investors to buy small portions of high-value assets. This makes investing accessible to a broader range of individuals who may not have the capital to buy entire assets.
Liquidity: Traditional real estate and other asset investments in emerging markets can be illiquid, with long holding periods. Tokenization allows for easier trading of these assets on secondary markets, enhancing liquidity and increasing yield from said assets.
Asset Fractionalization: In emerging markets where large assets such as real estate or infrastructure projects are typically owned by the wealthy. Tokenization enables these assets to be divided into smaller, more manageable units that can democratize access and stimulate economic growth by broadening ownership to individuals who cannot afford to purchase an entire asset or property.
Lower Costs: Exportation of commodities suffer from saturated Intermediaries that leave the producers with low margins. Tokenization can streamline the purchase and/or investment process, reducing transaction and trade costs.
Global Access: tokenized assets can be traded globally, allowing investors from anywhere in the world to participate in emerging market opportunities. RWA dApps seek access to Latin America markets but don't have the resources to bridge to reputable parties in the region.
Transparency: tokenizing assets on the public ledger can help mitigate certain risks around unclaimed or disputed land.
Compliance and Regulation: Tokenization platforms can integrate compliance mechanisms directly into smart contracts, ensuring that transactions adhere to relevant regulations, and protect investor rights.
50% of individuals in emerging markets are underbanked and have extremely limited access to credit terms. The other 50% struggle with high banking costs and interest rates. Kii Global layer 1 with infrastructure for DeFi lending options mixed with the liquidity settlements of its centralized exchange is solving these problems.
Through bridging the capital disparities between developed and emerging economies, the Kii ecosystem will support a wide range of DeFi lending protocols tailored for emerging markets in parallel with KIIEX’s open liquidity to centralized applications.
Scaling issues exist in current blockchain infrastructure because the amount of transactions processed in seconds is limited to total processing power. For example, Ethereum 2.0 can process roughly 30 transactions per second, therefore, it has to rely on sharding and rollups to scale horizontally and keep transactions flowing at minimal costs. High gas fees on Ethereum ($5 - $20 USD nominal) have prevented wide scale adoption among emerging markets. The majority of adoption thus far has been driven to more low cost gas networks like Tron. However, these networks are becoming more and more congested and the need for a more robust, structured decentralized solution is evident.
Cosmos’ CometBFT can process roughly 10,000 transactions per second and is predesigned within the Inter-Blockchain Communication Pool (IBC). IBC works in conjunction with other layer 1s in the cosmos community to process transactions and keep gas fees minimal, forever.
Cosmos based blockchains are built to deploy smart contracts written in Rust and deployed via CosmWasm. Although Rust is an advanced language of code with its benefits, there is a lack of real world developers who understand Rust, and companies who are looking to deploy their contracts with that language.
KiiChain has coded in the popular Solidity language for building and launching smart contracts, making KiiChain EVM compatible. Users can easily deploy their smart contracts, already written in Solidity, into the KiiChain. Kii Global has built an in-house dedicated team to help deploy user’s smart contracts within the blockchain. Companies looking for assistance on how to build smart contracts can rely on Kii Global developers for support and assistance when writing and deploying code.
Mainstream remittance and payment providers, tethered to archaic banking systems like ACH and SWIFT, grapple with inefficiencies, tardiness and inflated costs. Their modern counterparts, built on decentralized ledger tech, often falter at the “last mile”, rendering their P2P solutions uneconomical.
Kii Global ecosystem offers a much better on-ramp and off-ramp than any other provider in LatAm. Typical on and off-ramp services have limits, delays, and generally are not a reliable way to onboard into crypto or to off-ramp into fiat. KIIEX is able to utilize the local financial infrastructure, because they have built relationships with the local banks, which makes their services low cost, reliable, and without long delays. A spotlight feature of the exchange is its emphasis on "last mile delivery," addressing the importance of deep liquidity pairs against local fiat and the efficient verticalization of its on/off ramp rails for less than 1% cost. This infrastructure helps onboard more web2 users into web3.
The Kii token and KiiChain gives a chance for Latam locals to participate in an ecosystem built just for them, and one they can own a piece of. Users can earn a return on their KII by staking it through validator nodes, and rewards are replenished with 5% of Kii Global cash flow. This gives every Latam person an opportunity to take part of a community and a company with a vision of equitable justice for all.
KII is not at risk of clashing with the local government and banks, because the KII team has done the hard work of educating and building relationships with top banks and government officials in Latam. While most traditional financial institutions have a stigma as well as a lack of knowledge about crypto, KII is paving the way by building the infrastructure needed to offer frictionless cash settlement services. The KII team is a shining example of what right looks like, when it comes to compliance.
KII's value is derived from its Utility rather than a speculative investment. Here are the utility use cases for KII, outlining its value in the real-world and to the network.
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.
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).
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.
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.
Collateral: KII will be used as a collateral on DeFi apps, liquid staking, lending, and futures settlement.
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.
Rewards: KII is rewarded to validators and delegators for their service to the network.
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.
Governance: KII will be used for voting on future protocol and ecosystem development once the blockchain migrates to open governance.
Our vision of what and why we are building relentlessly everyday.
While the cryptocurrency space is saturated with a myriad of options, Kii Global distinguishes itself through its profound commitment to societal betterment. Beyond the technical marvels and financial prospects, KiiChain's ethos is rooted in fostering an accessible, and inclusive financial landscape, especially for the Latino community.
Currently, 50% of citizens in developing countries are unbanked, or underbanked. The main reason: their income isn’t sufficient enough to pay for the monthly costs associated with traditional financial services. As a result, these users, and many small businesses associated, lack access to basic financial services and credit lines.
As the world rapidly pivots to a decentralized financial paradigm, Kii Global envisions itself at the forefront - not merely as a passive participant but as an active change-maker. By continually iterating on its offerings, forging meaningful partnerships, and staying attuned to the real-world needs of its users, Kii Global is not just building a blockchain; it's crafting the future of finance by combining zero-fixed cost solutions with problem-solving web3 applications.
At the heart of it all, Kii Global is more than just a blockchain company. It's a beacon of hope, a promise of a brighter financial future, and a testament to what's possible when innovation meets empathy. Our main goal: create a systemic shift in the middle class in emerging markets.
A background on why we're relentlessly building every day.
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 web2 and web3 businesses. Since then, over 10,000 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 in Latin America, users can’t adopt blockchain settlements where the gas fees are more expensive than the product or service itself, and many users and businesses fail to understand the benefits when building on blockchains abroad. 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 really “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 B2B commodity and product based settlement network 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 pain-points within the market.
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 ecosystem of solutions that include a centralized exchange streamlining institutional liquidity to an array of low cost fiat cash solutions and a robust DeFi mobile app offering an array of low cost custodial and swap solutions.
The latest version of the KiiChain Whitepaper.
Connect your wallet to the KII interactive explorer and start staking.
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.
Go to Metamask.io and download and install the web extension browser. Make sure the web extension is from or . During testnet, if you do not have MetaMask installed first, you will receive this error.
Go to 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 "". Once your wallet has been created, you can link it to the explorer app by clicking the wallet icon in the top right corner.
Testnet tokens can be found on the faucet page in the explorer or requested in the discord. For more information, see here: .
KII has designed a sustainable rewards model where network participants can reap the rewards of the Kii Global suite of products.
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.
Get a wallet for KiiChain Testnet Oro
Connect your Keplr or MetaMask wallet to the explorer app to stake KII into a validator or to help launch a full node/validator.
Connect to our web wallet using Keplr or Metamask.
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.
An introduction and important links.
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 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.
The command for requesting tokens in our Discord faucet channel is:
Example EVM:
Example Cosmos Address:
The full list of commands are:
List commands:
Request tokens:
Query an address balance:
Query a transaction:
Query the faucet and node status:
Query the faucet address:
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.
Quick start links:
General customer service and developer support are available in our channel. Get to know us.
You can find us on Discord:
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.
For further explanation of how to set up your wallet, follow the steps or connect your testnet wallet to our explorer app automatically by following the steps .
Testnet Oro tokens are available in our 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 Explorer App can be automatically connected to MetaMask or Keplr via the RPC endpoints. Once you have installed the MetaMask extension, follow the steps to connect your wallet and begin delegating.
If you’re a developer and are interested in building with KiiChain, a good place to start is reviewing the introduction information .
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 .
Set up a wallet using MetaMask or Keplr with a web wallet for Testnet Oro. Its important to use a wallet compatible to your browser.
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!
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:
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.
Network name
Kiichain Testnet Oro
New RPC URL
Chain ID
1336
Currency symbol
KII
Block explorer URL
Upon saving and completion, you should be connected to the testnet network!
Available on the App Store and Google Play
Mobile wallets are currently in deployment mode for Testnet Oro. Mobile wallets are available on the App Store and Google Play for users who would like to have access to the basic functions of the chain. Within the mobile wallet, users can login via email or manage their 24 set word keys.
In the wallet, users can send, receive, and stake their KII by selecting the validator they would like to use to perform all functions. These wallets are currently connected in Testnet and can be used for all developers, hackathons, and competitions.
Mobile wallets will be compatible with Testnet V1 and Testnet Oro.
Go to Metamask.io and download and install the web extension browser. Make sure the web extension is from .
Now, get some testnet tokens by following the instructions: .
Apple Store:
Google Play:
Everything you need to know about building on KiiChain. Your hub for connecting to the chain and building applications on the decentralized web.
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:
If you are a developer we also have our official SKDs for development:
Python SDK
Kii protocols can be found at these links:
Generally, our chains (testnets and mainnet) follow the same set of endpoints. More information about our endpoints can be found here:
Endpoints
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.
Everything you need to know about our Testnet Oro
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.
The source code for the Testnet Oro can be found at:
Testnet Oro has the following endpoints open for development purposes:
Sentry #1:
GRPC: grpc.uno.sentry.testnet.v3.kiivalidator.com:443
Peer: 5b6aa55124c0fd28e47d7da091a69973964a9fe1@uno.sentry.testnet.v3.kiivalidator.com:26656
Sentry #2:
GRPC: grpc.dos.sentry.testnet.v3.kiivalidator.com:443
Peer: 5e6b283c8879e8d1b0866bda20949f9886aff967@dos.sentry.testnet.v3.kiivalidator.com:26656
Currently, there are no seed nodes or persistent peers available to the public.
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
Instructions on how to join the network can be found at:
You can get tokens to our Testnet Oro by using our Explorer app:
Our through our Discord channel:
More information about how to use our discord Faucet can be found at:
The testnet Oro also has its own Explorer, it can be found here:
Rest endpoints for the testnet Oro can be found here:
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.
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.
RPC:
Rest (LCD):
JSON-RPC (EVM):
RPC:
Rest (LCD):
JSON-RPC (EVM):
You can find guides to the testnet at our :
Build on the ecosystem.
An overview of developer tools, SDKs and resources for accessing the network.
T-REX Protocol on KiiChain
Note: This project is still under development so future changes will be made.
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.
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.
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.
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
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
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
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.
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
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
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
Implement CW20 T-REX Token
Implement Identity Registry and Identity Registry Storage
Implement Trusted Issuers Registry and Claim Topics Registry
Implement Modular Compliance
Implement ONCHAINID
Implement T-REX Factory
Implement Implementation Authority
Integrate all contracts and perform thorough testing
Conduct security audit
Deploy to Kii-Chain testnet
Final testing and adjustments
Deploy to Kii-Chain mainnet
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
Rust SDK for the RWA Protocol on KiiChain
Note: This project is still under development so future changes will be made.
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.
Token transfers and balance checks
Identity registration and management
Compliance module integration
Blockchain interaction via RPC
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.
Validators power the network.
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
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.
A delegator is a person or entity that wants to Stake their tokens without managing a node or full node.
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.
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.
An SDK written in Javascript/Typescript for KiiChain
Note: This project is still under development so future changes will be made.
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.
Each package has it's own documentation under its readme file.
KiiJS consists of smaller NPM packages within the @kiichain namespace. For more detailed documentation on each package, please refer to the table below.
Typescript library containing helper functions for interacting with the EVM on Kiichain.
Typescript support for KiiChain protofiles, generated with Telescope
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.
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.
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.
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
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:
To broadcast messages, you can create signers with a variety of options:
Likely you'll want to use the Amino, so unless you need proto, you should use this one:
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.
Now that you have your stargateClient
, you can broadcast messages:
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.
If you want to manually construct a stargate client
Overview for deploying a smart contract with Hardhat, Remix, Foundry, and Thirdweb.
RPC URL:
Chain Id:
1336
Install the hardhat framework in your project, by typing the following command:
After installing Hardhat, create a project. You can create it using typescript or javascript in the following screen:
After creating the smart contract in the “Contracts” folder, run the following command to check your code.
After creating the ignition deploy file, let's set the blockchain information into the hardhat.config file, with the following information:
In the Workspace create the file which contains the Smart contract with the .sol extension.
After writing the smart contract, go to the Solidity Compiler section and select your compiler version, is recommended to use the most recent one.
Then press “Compile” button under the Compiler selector.
In the “Deploy and Run Transactions” section, move to the Environment and select your Metamask Provider, remember you must be connected to KiiChain Testnet
Select the smart contract to be deployed and write the Constructor parameters is Remix detects them
Finally, you can interact with the different functions in the same section above the Deploy button.
Run the following commands in your terminal in order to start the foundry’s installation.
then run the following command in another terminal or restart the current one for finishing the installation process.
After finishing the foundry’s installation let’s create a new project, run the following commands for starting the new project and then move to it’s folder:
Write your smart contract in ‘/src/smartContractName.sol’ and the script in ‘/script/smartContractName.s.sol’, here is an example of that:
This contract will be placed in the path: /src/Counter.sol
This is the script and will be placed in /script/Counter.s.sol remember to add the .s before the .sol extension.
then run the following command for build and check that everything is correct.
First, you need to run a simulation.
The simulation will be complete after that, and you can run with broadcast.
A success message should appear.
In this example, we will create a ERC721 (Non fungible token).
Storage the API key in a secure place.
A message appears
After the installation this screen should appear, select “Contract”
Select the following options:
Enter the directory and run the following command:
Open the link and fill in the fields.
In chain choose
add Custom Network
Finally, select Deploy Now and accept the transaction in your wallet.
Deploy a decentralized application on KiiChain.
In this tutorial, you will learn how to create a simple decentralized application (dApp) built on KiiChain. We will use tools such as React, TypeScript, and Ethers.js to build a basic wallet management system.
We will be using the following tools:
npx
for managing Node.js packages and running commands.
ethers
for interacting with the Ethereum blockchain and other compatible chains like KiiChain.
React
for building the user interface.
TypeScript
for adding static types to JavaScript.
First, navigate to your working directory, open a terminal, and run the following commands to create a new React project with TypeScript:
After the project is set up, open the code in your preferred editor. If you are using Visual Studio Code, you can do this with:
You should now see the following project structure:
Next, you need to install the ethers
library. Run the following command in the terminal within your project directory:
Create a new file at src/repository/kiichain.repository.ts
. The directory needs to be created.
This repository file contains functions for basic operations like creating a wallet, connecting to a wallet using a seed phrase, and getting the balance of a wallet.
In decentralized application (dApp) development, especially when interacting with blockchains like KiiChain, it's essential to understand the concepts of Provider and Signer. These components play crucial roles in communicating with and managing transactions on the blockchain.
A Provider is a component that allows your dApp to connect to and interact with the blockchain. It provides methods to read data from the blockchain, such as transaction statuses, account balances, and other network details. The provider does not have access to private keys and therefore cannot sign transactions.
A Signer is a component that represents an entity capable of making transactions on the blockchain, meaning it can sign them. A signer has access to the private keys necessary to authorize and send transactions, allowing you to modify the blockchain state, such as transferring tokens or interacting with smart contracts.
Create a new file at src/components/WalletManager.tsx
. The directory needs to be created
This component implements the functions from the repository and displays the relevant information, such as the wallet address and balance.
To check if everything is working correctly, you need to run the project. Open your terminal in the project directory and execute the following command:
If everything is set up properly, your application should start, and the following screen will appear:
Create a New Wallet: Click the "Create New Wallet" button. A new wallet will be generated, and the address along with the seed phrase will be displayed in the console.
Access the Developer Console:
Right-click anywhere on the page and select "Inspect" to open the Developer Tools.
Navigate to the "Console" tab to see the output.
Connect to the Wallet: Copy the seed phrase from the console, paste it into the input field under "Enter your seed phrase," and click "Connect Wallet via Seed Phrase."
View Wallet Balance: If connected successfully, the wallet's balance should be displayed on the screen.
By following these steps, you can confirm that the dApp is functioning as expected.
To deploy your decentralized application (dApp) using Firebase Hosting, follow these steps:
Create a Project in Firebase:
Click on "Create a project".
Name your project and disable Google Analytics (optional for this tutorial).
Click "Continue" once the project is ready.
Access Firebase Hosting:
In the left menu, go to Build → Hosting.
Click "Get started" to begin setting up Firebase Hosting.
Install Firebase CLI:
Open your terminal and install Firebase CLI globally
Login and Initialize Firebase:
Inside your project directory, run
During initialization, select the following options:
Features: Hosting: Configure files for Firebase Hosting
Project Setup: Use an existing project
Public Directory: ‘build’
Single-page App: No
Automatic Builds/Deploys: No
Build the project:
Run the following command to generate the production-ready files
Deploy to Firebase
Deploy your built project to Firebase Hosting
Once the deployment is complete, the URL of your live dApp will be shown in the terminal.
This package provides exports for easily interacting with viem, and ethers.js. You can interact with the KiiChain EVM using all the same hooks and helper functions these tools offer. Read the viem and ethers v6 documentation for more information on how to use these tools.
Ensure that your EVM wallet has the KiiChain network enabled.
The 'ethers' package is a popular library for interacting with the Ethereum blockchain. This package provides a helper function for creating an ethers provider that is connected to the KiiChain EVM.
An alternative without the popup is to directly use your private key to connect.
This package exports viem
Chains and precompile ABI's for KiiChain. The ABI used in the ethers example above is a viem ABI instance and the ARCTIC_1_VIEM_CHAIN
is a viem Chain
instance.
KiiChain v3 supports both EVM JSON-RPC and Cosmos RPC interfaces. In order to easily interact with certain Cosmos modules, KiiChain v3 has a set of precompiled contracts that can be called from the EVM.
Provides functionalities for checking balances and supply.
Facilitates conversion between hex address and bech32
Deals with reward distribution and related
Supports actions such as depositing funds into proposals, voting and interacting with proposals.
Facilitates conversion between hex address and bech32
Provides management and query options for penalties
Enables staking functionalities like delegation and undelegation or obtaining information on validators.
Precompile for interacting with wasm contracts
Each precompile has contract exports a typed 'ethers' contracts and provides the ABI and contract addresses for each precompile for usage with Wagmi and viem.
The Bank precompile contract provides functionalities for managing balances, supply, symbols, and more.
Functions
balances
acc: string
balances : [{ denom: string, amount: string }]
Retrieves the balances of a given address
supplyOf
denom: string
{ response: string }
Retrieves the total supply of tokens for the specified denomination.
totalSupply
-
balances : [{ denom: string, amount: string }]
Retrieves all the supplies from the chain
Precompile Addresses
0x000000000000000000000000000000000000080
The bech32 precompile contract provides ways to turn a hex address to bech32 and vice-versa. There is also functions in the library under the precompile to do the same without using the contract.
The Distribution precompile contract facilitates operations related to rewards withdrawal and distribution.
Functions
Here's the table representation of your Distribution ABI:
claimRewards
delegatorAddress: string
(address)
maxRetrieve: number
(uint32)
success: boolean
Claims rewards for a delegator (up to maxRetrieve)
delegationRewards
delegatorAddress: string
(address)
validatorAddress: string
rewards: [{ denom: string, amount: string, precision: number }]
Gets rewards for a specific delegation
delegationTotalRewards
delegatorAddress: string
(address)
rewards: [{ validatorAddress: string, reward: [{ denom: string, amount: string, precision: number }] }]
total: [{ denom: string, amount: string, precision: number }]
Gets all rewards for a delegator with totals
delegatorValidators
delegatorAddress: string
(address)
validators: string[]
Lists all validators a delegator is staked with
delegatorWithdrawAddress
delegatorAddress: string
(address)
withdrawAddress: string
Gets the withdrawal address for a delegator
fundCommunityPool
depositor: string
(address)
amount: string
(uint256)
success: boolean
Funds the community pool
setWithdrawAddress
delegatorAddress: string
(address)
withdrawerAddress: string
success: boolean
Sets the withdrawal address for rewards
validatorCommission
validatorAddress: string
commission: [{ denom: string, amount: string, precision: number }]
Gets commission rewards for a validator
validatorDistributionInfo
validatorAddress: string
distributionInfo: { operatorAddress: string, selfBondRewards: [{ denom: string, amount: string, precision: number }], commission: [{ denom: string, amount: string, precision: number }] }
Gets full distribution info for a validator
validatorOutstandingRewards
validatorAddress: string
rewards: [{ denom: string, amount: string, precision: number }]
Gets outstanding rewards for a validator
validatorSlashes
validatorAddress: string
startingHeight: number
(uint64)
endingHeight: number
(uint64)
pageRequest: { key: bytes, offset: number, limit: number, countTotal: boolean, reverse: boolean }
slashes: [{ validatorPeriod: number, fraction: { value: string, precision: number } }]
pageResponse: { nextKey: bytes, total: number }
Gets slash events for a validator with pagination
withdrawDelegatorRewards
delegatorAddress: string
(address)
validatorAddress: string
amount: [{ denom: string, amount: string }]
Withdraws delegator's rewards from a validator
withdrawValidatorCommission
validatorAddress: string
amount: [{ denom: string, amount: string }]
Withdraws validator's commission rewards
Precompile Addresses
0x0000000000000000000000000000000000000801
The Evidence precompile contract provides functionalities for dealing with evidences.
Functions
evidence
evidenceHash: bytes
evidence: { height: number, time: number, power: number, consensusAddress: string }
Retrieves evidence by its hash
getAllEvidence
pageRequest: { key: bytes, offset: number, limit: number, countTotal: boolean, reverse: boolean }
evidence: [{ height: number, time: number, power: number, consensusAddress: string }]
pageResponse: { nextKey: bytes, total: number }
Retrieves all evidence with pagination support
submitEvidence
evidence: { height: number, time: number, power: number, consensusAddress: string }
success: boolean
Submits new evidence of validator equivocation
Precompile Addresses
0x0000000000000000000000000000000000000807
The Governance precompile contract supports actions to deposit funds into proposals, view them and interact with them.
Functions
getDeposit
proposalId: number
(uint64)
depositor: string
(address)
deposit: { proposalId: number, depositor: string, amount: [{ denom: string, amount: string }] }
Gets a specific deposit for a proposal
getDeposits
proposalId: number
(uint64)
pagination: { key: bytes, offset: number, limit: number, countTotal: boolean, reverse: boolean }
deposits: [{ proposalId: number, depositor: string, amount: [{ denom: string, amount: string }] }]
pageResponse: { nextKey: bytes, total: number }
Gets all deposits for a proposal with pagination
getParams
-
params: { votingPeriod: number, minDeposit: [{ denom: string, amount: string }], maxDepositPeriod: number, quorum: string, threshold: string, vetoThreshold: string, ... }
Returns governance parameters
getProposal
proposalId: number
(uint64)
proposal: { id: number, messages: string[], status: number, finalTallyResult: { yes: string, abstain: string, no: string, noWithVeto: string }, submitTime: number, ... }
Gets full proposal details
getProposals
proposalStatus: number
(uint32)
voter: string
(address)
depositor: string
(address)
pagination: { ... }
proposals: [{ id: number, messages: string[], status: number, finalTallyResult: { ... }, ... }]
pageResponse: { nextKey: bytes, total: number }
Lists proposals with filters and pagination
getTallyResult
proposalId: number
(uint64)
tallyResult: { yes: string, abstain: string, no: string, noWithVeto: string }
Gets current tally results for a proposal
getVote
proposalId: number
(uint64)
voter: string
(address)
vote: { proposalId: number, voter: string, options: [{ option: number, weight: string }], metadata: string }
Gets an individual vote
getVotes
proposalId: number
(uint64)
pagination: { ... }
votes: [{ proposalId: number, voter: string, options: [{ option: number, weight: string }], metadata: string }]
pageResponse: { nextKey: bytes, total: number }
Gets all votes for a proposal with pagination
vote
voter: string
(address)
proposalId: number
(uint64)
option: number
(uint8)
metadata: string
success: boolean
Submits a vote on a proposal
voteWeighted
voter: string
(address)
proposalId: number
(uint64)
options: [{ option: number, weight: string }]
metadata: string
success: boolean
Submits a weighted vote on a proposal
Precompile Addresses
0x0000000000000000000000000000000000000805
Enables cross-chain token transfers via IBC with granular permission control over channels and denominations.
Functions
allowance
grantee: string
(address)
granter: string
(address)
allocations: [{ sourcePort: string, sourceChannel: string, spendLimit: [{ denom: string, amount: string }], allowList: string[], allowedPacketData: string[] }]
Checks granted IBC transfer permissions
approve
grantee: string
(address)
allocations: [{ sourcePort: string, sourceChannel: string, spendLimit: [{ denom: string, amount: string }], ... }]
approved: boolean
Grants IBC transfer permissions
decreaseAllowance
grantee: string
(address)
sourcePort: string
sourceChannel: string
denom: string
amount: string
(uint256)
approved: boolean
Reduces spend limit for a specific channel/denom
denomHash
trace: string
(e.g., "transfer/channel-1/uatom")
hash: string
(IBC denom hash)
Converts IBC denom trace to hash (e.g., ibc/27394FB092...
)
denomTrace
hash: string
(IBC denom hash)
denomTrace: { path: string, baseDenom: string }
Decodes IBC hash to original trace (e.g., path: "transfer/channel-1"
, baseDenom: "uatom"
)
denomTraces
pageRequest: { key: bytes, offset: number, limit: number, ... }
denomTraces: [{ path: string, baseDenom: string }]
pageResponse: { nextKey: bytes, total: number }
Lists all registered denom traces with pagination
increaseAllowance
grantee: string
(address)
sourcePort: string
sourceChannel: string
denom: string
amount: string
(uint256)
approved: boolean
Increases spend limit for a specific channel/denom
revoke
grantee: string
(address)
revoked: boolean
Revokes all IBC transfer permissions for a grantee
transfer
sourcePort: string
sourceChannel: string
denom: string
amount: string
(uint256)
sender: string
(address)
receiver: string
timeoutHeight: { revisionNumber: number, revisionHeight: number }
timeoutTimestamp: number
memo: string
nextSequence: number
(uint64)
Initiates an IBC token transfer
Precompile Addresses
0x0000000000000000000000000000000000000802
Enables query, interaction and management of validator penalties.
Functions
getParams
-
params: { signedBlocksWindow: number, minSignedPerWindow: string, downtimeJailDuration: number, slashFractionDoubleSign: string, slashFractionDowntime: string }
Returns slashing module parameters
getSigningInfo
consAddress: string
(address)
signingInfo: { validatorAddress: string, startHeight: number, indexOffset: number, jailedUntil: number, tombstoned: boolean, missedBlocksCounter: number }
Gets signing info for a validator
getSigningInfos
pagination: { key: bytes, offset: number, limit: number, countTotal: boolean, reverse: boolean }
signingInfos: [{ validatorAddress: string, startHeight: number, indexOffset: number, jailedUntil: number, tombstoned: boolean, missedBlocksCounter: number }]
pageResponse: { nextKey: bytes, total: number }
Gets all validator signing info with pagination
unjail
validatorAddress: string
(address)
success: boolean
Releases a validator from jail status
Precompile Addresses
0x0000000000000000000000000000000000000806
The Staking precompile manages validator operations, delegations, and governance permissions in a Cosmos-based blockchain with EVM compatibility.
Functions
allowance
grantee: string
(address)
granter: string
(address)
method: string
remaining: string
(uint256)
Checks remaining allowance for a grantee's staking actions
approve
grantee: string
(address)
amount: string
(uint256)
methods: string[]
approved: boolean
Grants staking permissions to another address
cancelUnbondingDelegation
delegatorAddress: string
(address)
validatorAddress: string
amount: string
(uint256)
creationHeight: string
(uint256)
success: boolean
Cancels an unbonding delegation before completion
createValidator
description: { moniker: string, identity: string, ... }
commissionRates: { rate: string, maxRate: string, ... }
minSelfDelegation: string
validatorAddress: string
(address)
pubkey: string
value: string
(uint256)
success: boolean
Registers a new validator
decreaseAllowance
grantee: string
(address)
amount: string
(uint256)
methods: string[]
approved: boolean
Reduces staking permissions for a grantee
delegate
delegatorAddress: string
(address)
validatorAddress: string
amount: string
(uint256)
success: boolean
Delegates tokens to a validator
delegation
delegatorAddress: string
(address)
validatorAddress: string
shares: string
(uint256)
balance: { denom: string, amount: string }
Returns delegation details between a delegator and validator
editValidator
description: { moniker: string, ... }
validatorAddress: string
(address)
commissionRate: number
(int256)
minSelfDelegation: number
(int256)
success: boolean
Modifies validator metadata/parameters
increaseAllowance
grantee: string
(address)
amount: string
(uint256)
methods: string[]
approved: boolean
Increases staking permissions for a grantee
redelegate
delegatorAddress: string
(address)
srcValidatorAddress: string
dstValidatorAddress: string
amount: string
(uint256)
completionTime: number
(int64)
Transfers delegation between validators (with unbonding period)
redelegation
delegatorAddress: string
(address)
srcValidatorAddress: string
dstValidatorAddress: string
redelegation: { entries: [{ creationHeight: number, completionTime: number, ... }] }
Returns redelegation details
redelegations
delegatorAddress: string
(address)
srcValidatorAddress: string
dstValidatorAddress: string
pageRequest: { key: bytes, ... }
response: [{ redelegation: { ... } }]
pageResponse: { nextKey: bytes, total: number }
Paginated redelegation history
revoke
grantee: string
(address)
methods: string[]
revoked: boolean
Revokes all staking permissions for a grantee
unbondingDelegation
delegatorAddress: string
(address)
validatorAddress: string
unbondingDelegation: { entries: [{ creationHeight: number, completionTime: number, ... }] }
Returns active unbonding delegations
undelegate
delegatorAddress: string
(address)
validatorAddress: string
amount: string
(uint256)
completionTime: number
(int64)
Initiates token unbonding from a validator
validator
validatorAddress: string
(address)
validator: { operatorAddress: string, jailed: boolean, tokens: string, ... }
Returns validator details by address
validators
status: string
pageRequest: { key: bytes, ... }
validators: [{ operatorAddress: string, jailed: boolean, ... }]
pageResponse: { ... }
Lists validators (filtered by status) with pagination
Precompile Addresses
0x0000000000000000000000000000000000000800
The wasm precompile makes wasm contracts available to being used via evm, with instantiate, query and execute.
Functions
execute
contractAddress: string
msg: bytes
(JSON-encoded)
coins: [{ denom: string, amount: string }]
success: boolean
Executes a contract method with optional token transfer
instantiate
admin: string
(address)
codeID: number
(uint64)
label: string
msg: bytes
(init msg)
coins: [{ denom: string, amount: string }]
success: boolean
Deploys a new contract instance from stored code
queryRaw
contractAddress: string
queryData: bytes
(raw query)
data: bytes
(raw response)
Low-level contract query (returns raw bytes)
querySmart
contractAddress: string
msg: bytes
(JSON-encoded query)
data: bytes
(JSON response)
Smart query (parses input/output as JSON)
Precompile Addresses
0x0000000000000000000000000000000000001001
Join the testnet, set up your wallet, and request KII tokens.
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 KII can be found in the faucet in Discord and on our Explorer App. It can be called on every 24 hours.
Request tokens:
Example EVM:
Example CW:
See all available commands:
Request tokens:
Query an address balance:
Query a transaction:
Query the faucet and node status:
Query the faucet address:
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.
Creates a denom factory/{creator address}/{subdenom}
given the denom creator address and the subdenom. Subdenoms can contain [a-zA-Z0-9./]
.
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.
Minting of a specific denom is only allowed for the current admin. Note, the current admin is defaulted to the creator of the denom.
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
Burning of a specific denom is only allowed for the current admin. Note, the current admin is defaulted to the creator of the denom.
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
Change the admin of a denom. Note, this is only allowed to be called by the current admin of the denom.
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.
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
How to deploy smart contracts
Kiichain supports natively supports both CosmWasm and EVM smart contracts. Developers can choose between any of the two to create amazing dApps.
Install Rust and CosmWasm toolchain:
Create a new CosmWasm contract:
Compile the contract:
Store the Contract
Instantiate the Contract
Execute the Contract
Install Node.js and Hardhat:
Install dependencies:
Create a Solidity file (MyContract.sol
) in contracts/
:
Compile the contract:
Create a deployment script (scripts/deploy.js
):
Deploy to Kiichain:
Using Hardhat Console:
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.
The evm
module provides:
EVM Execution Environment within Cosmos-SDK
Support for Ethereum JSON-RPC APIs
Full Solidity smart contract compatibility
The EVM module provides several messages and transactions that users and developers can utilize:
Submit Ethereum Transactions: Users can submit Ethereum-formatted transactions (MsgEthereumTx
) to Kiichain, which are processed by the EVM module.
Kiichain offers command-line interface (CLI) commands for interacting with the EVM module:
Query Smart Contract Code:
Query Storage:
Submit Raw Ethereum Transaction:
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.
The x/feemarket
module implements a dynamic fee mechanism inspired by Ethereum's EIP-1559, enhancing transaction fee predictability and network efficiency.
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.
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.
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.
Please be sure to read and follow our . By participating, you are expected to uphold this code.
Read our to learn about our issue and pull request submission processes, coding rules, and more.
We use for tracking requests and bugs, for general questions and discussion.
The KiiPy project is licensed under .
⚡️ 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.
(recommended)
Remix is a web compiler page where you can write smart contracts, scripts and deploy using your wallet from Metamask. You can enter Remix .
Create an account in thrirdweb, create an API key , and link your wallet.
Remember that you can check the smart contracts Deployed .
The version used in this tutorial is .
Visit the .
Typescript library containing helper functions for interacting with the EVM on KiiChain. The full code can be found here:
CosmWasm Documentation:
Ethereum Hardhat Guide:
This module is built on top of the .
Initial steps before announcing your entry as a validator
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.
Everyone is welcome to launch their own validator. Please review all information carefully.
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.
Legacy addresses can be recovered
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.
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.
To recover old wallets (e.g., validator rewards wallets or delegator accounts) that were created before the upgrade:
Replace <key_name>
with your desired key name.
Input your existing mnemonic when prompted.
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.
Important information for Validators.
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
Kiichain´s PoS staking model.
There are three type of important network participants in Kiichain.
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.
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.
Delegators (stakers): Individuals who commit KII to validators in order to participate in staking and earn rewards.
Incentives for validating the network.
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.
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.
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.
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.
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)
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%.
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.
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.
How to update and maintain a validator on the Kii network
This will guide you through basic operations on how to maintain 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.
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:
Transfer funds
Ensure your account has sufficient funds for fees and self-delegation.
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 you can use the following command:
The transaction must be done on the machine running the node
An additional flag --node
can be passed to point to an available RPC node
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:
Where:
--from
must be the operator of the validator
--identity
can be used as to verify identity with systems like Keybase or UPort
--commission-rate
must 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.
Neither commission-max-rate
and commission-max-change-rate
can be changed after validator creation.
Your validator may get jailed for downtime. To unjail your validator you must use the following transaction:
You may want to halt your validator for maintenance or a coordinated upgrade. You can gracefully halt your validator by setting it halt-height
to 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.
How to run your own Kiichain Validator
The configuration followed before, set your node as a full node, this page will guide you to upgrade your node into 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)
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.
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:
Transfer funds
Ensure your account has sufficient funds for fees and self-delegation.
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, you can use the following command:
The transaction must be done on the machine running the node
An additional flag --node
can be passed to point to an available RPC node
Onboarding for validators
It's always nice to see new users onboarding into the Testnet Oro.
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.
Golang version: v1.23.x
Build tools: build-essential
package (Linux)
To install Kiichain, download the pre-built binaries:
Verify the installation by checking the version of kiichaind:
To join the Testnet Oro, you must have the daemon kiichaind
installed in your machine.
For optimal performance, we recommend:
4 vCPU x86_64
8 GB RAM
1 TB NVME SSD
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
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
This configuration runs a full node. For validators, update the configuration accordingly!
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:
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)
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:
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:
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.
Enable State Sync in Configuration
Modify the config.toml
file to enable state sync and set the required parameters.
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:
Go to $NODE_HOME/config/app.toml
and 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'
Further instructions on how to build a great node architecture can be found on:
Protect your validator from malicious attacks.
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.
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.
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
:
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.
For hardware and software protocols.
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.
Validators are expected to implement monitoring, alerting, and management solutions. There are several tools that you can use.
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.
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.
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.
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.
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.
Further instructions on how to run a validator can be found at .
Check the section on how to do it
Further instructions on how to run a validator can be found at .
This will guide you through the process of running your own full node, then and finally running
More information about cosmovision can be found at .
Check the section on how to do it
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.
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.
For more sentry node details, see the or the on the forum.
Stake your KII to Validators or Masternodes and earn rewards without any hassle.
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.
For delegators / stakers.
If you're interested in delegating (staking) your KII to a validator or masternode, the following information is important to review.
Kiichain was designed with rewards in mind.
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.
Annual percentage rate
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.
Calculate rewards at the beginning of each epoch.
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.
Delegating / staking KII requires active supervision.
Being a delegator is not a passive task. Here are the main points of consideration of a delegator:
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.
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).
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.
Choosing a validator requires due diligence.
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
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.
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.
You can apply to join the Ambassadors Program through the official KiiChain Discord:
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 Twitter.
Participate in the weekly tasks, shared in this channel.
Help grow the community by inviting new users or explaining Kii to newcomers.
Report scams or malicious behavior to the mod team.
Suggest strong candidates who could join the program in the future.
Protocol for minimizing the risks of attacks.
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.
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.
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.
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.
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.
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.
Staking is not free of risk.
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.
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.
Staking rewards and validator commissions.
Validators and delegators earn revenue in exchange for their services. This revenue is given in two forms:
Block provisions (KIIs): They are paid in newly created KIIs. Block provisions exist to incentivize KII holders to validate and stake the network.
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.
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.
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.
Ambassadors who complete tasks consistently and with high quality may receive:
XP for the airdrop, redeemable for $KII at Mainnet launch
Monthly raffle for top ambassadors with prizes in USDT
GigaAmbassador role, which grants an airdrop multiplier
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
Promotional content kits (logos, graphics, memes, templates)
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.
This API covers the User-category calls in version 3.3 of the KIIEX exchange software. It includes calls required for log-in and authentication.
KIIEX is a B2B payment app and CEX within the ecosystem.
Create a relationship with the KIIEX team to open an account and start accessing institutional liquidity.
Are you a high volume trader or corporate client and would like access directly to the KIIEX white glove service?
Please send an email to "compliance@kiiglobal.io" with the following information to begin onboarding.
Email address with fully verified KIIEX account.
Corporate formation documents.
Tax ID documents.
Shareholder composition or capitalization table.
An onboarding analyst will contact you about your application and next steps.
Benefits:
Private group chat with direct access to the trading team.
Assigned private trader for executing block trades.
Tech support for building on Kii or KIIEX APIs.
More competitive spreads and fees.
Start trading and using KIIEX's payment rails in Latam
When setting up your account, it is important to confirm your email before logging in for the first time.
Once you've created your account and logged in successfully, you need to complete KYC by clicking your account profile in the top right corner -> settings -> Verification Level.
Click "Increase to Level 1" and have a government-issued ID ready before you start. Make sure your photos are clear and eligible before you submit the required documents/photos. Please wait 1 minute and let the system verify your identity before you try again.
Secure your account with 2FA by going to your profile in the top right -> Settings -> Profile & Security -> Two-Factor Authentication.
We recommend using Google Authentication to secure your account. Never share your codes with anyone. KIIEX will never ask you for your password or 2FA codes.
Set up your account at or login to an existing account at .
API Behavior Changes
Any query APIs that return these objects now have the below new fields and response value changes as listed.
AccountPosition
NotionalHoldAmount
decimal. Cross Product Amount on Hold from open orders
NotionalRate
decimal. Current notional rate from base currency
TotalDayDepositNotional
decimal. Total Calendar Day Deposit Notional
TotalMonthDepositNotional
decimal. Total Calendar Month Deposit Notional
TotalDayWithdrawNotional
decimal. Total Calendar Day Withdraw Notional
TotalMonthWithdrawNotional
decimal. Total Calendar Month Withdraw Notional
OrderTrade
CounterPartyClientUserId
int. Indicates counterparty source of trade (OMS, Remarketer, FIX)
NotionalProductId
int. Notional product the notional value was captured in
NotionalRate
decimal. Notional rate from base currency at time of trade
NotionalValue
decimal. Notional value in base currency of venue at time of trade
AccountInstrumentStatistics
NotionalProductId
int. Notional product the notional value was captured in
DailyNotionalTradeVolume
decimal. Total Calendar Day Trading Notional
MonthlyNotionalTradeVolume
decimal. Total Calendar Month Trading Notional
YearlyNotionalTradeVolume
decimal. Total Calendar Year Trading Notional
VerificationLevelInstruments
NotionalProductId
int. Notional product the notional value was captured in
DailyNotionalLimit
decimal. Total Calendar Day Trading Notional
MonthlyNotionalLimit
decimal. Total Calendar Month Trading Notional
YearlyNotionalLimit
decimal. Total Calendar Year Trading Notional
AccountStatistics
TotalDayDepositNotional
decimal. Total Calendar Day Deposit Notional
TotalMonthDepositNotional
decimal. Total Calendar Month Deposit Notional
TotalDayWithdrawNotional
decimal. Total Calendar Day Withdraw Notional
TotalMonthWithdrawNotional
decimal. Total Calendar Month Withdraw Notional
VerificationLevelProducts
DailyDepositNotionalLimit
decimal. Total Calendar Day Deposit Notional Limit
MonthlyDepositNotionalLimit
decimal. Total Calendar Month Deposit Notional Limit
DailyWithdrawNotionalLimit
decimal. Total Calendar Day Withdraw Notional Limit
MonthlyWithdrawNotionalLimit
decimal. Total Calendar Month Withdraw Notional Limit
OMSInfo
BaseNotionalProductId
int. Id of Base Product to be used in Notional Limits
Fee
FeeTier
int. Id of the Fee Tier the fee belongs to. Matches AccountInfo FeeGroupId (previously existing field)
Instrument
PriceCollarIndexDifference
decimal. The percent different from the index price that an order is allowed to execute at. Anything falling outside of the index price +/- (1 + PriceCollarIndexDifference) will be collared
PriceCollarConvertToOtcEnabled
bool. Turns on/off conversion of collared orders to block trades
PriceCollarConvertToOtcClientUserId
int. Internal System UserId to assign the collared otc orders to. Should alwaays be 1 in current implementation (default)
PriceCollarConvertToOtcAccountId
int. Account Id to assign the collared orders to. This will effectively be a liability account that will need to have working block trades managed by operator.
PriceCollarConvertToOtcThreshold
decimal. Threshold of remaining size of order to convert to block trade. If collared order does not have remaining quantity above this threshold the remainder will be cancelled.
OtcConvertSizeEnabled
bool. Turns on/off auto conversion of 'large' limit orders converted to block trade orders upon receipt by the matching engine
OtcConvertSizeThreshold
decimal. Threshold to convert limit order quantity to block trade automatically for discovery by block trade market participants
This section provides important information about the KIIEX exchange software powered by APEX.
Support for additional fields has been added to the following requests:
GetAccounts
SubmitBlockTrade
ModifyOrder
Additional fields have been added to the following responses:
GetWithdrawFormTemplateTypes
SubmitAccountLedgerEntry
GetAllLedgerEntryTickets
GetOpenWithdrawHolds
GetOrderStatus
TransferFunds
GetLevel1 / Level1UpdateEvent / SubscribeLevel1
SendOrder
Request Payload changed for Market Buy Value - if Buy order and Value (decimal) parameter is supplied, the Market order will execute up to the value specified.
GetExchangeServiceIds
Old GetExchangeServiceIDs Response An array of strings representing service ids.
New GetExchangeServiceIds Response Array hard coded with a single entry: "Matching Engine"
GetExchanges
Old GetExchangeServiceIds Response A list of exchanges within a specified exchange service id.
New GetExchangeServiceIds Response Retrieves exchanges from "THE" mathcing engine as there can only ever be one as of 3.4
Validate2FA
Behavior change, no longer has public permissions specified.
AddInstrument (DEPRECATED)
Behavior change, endpoint returns with bad request message specifying the endpoint is deprecated.
UpdateInstrument (DEPRECATED)
Behavior change, endpoint returns with bad request message specifying the endpoint is deprecated.
RemoveOperatorUser
Behavior change from “Deprecated” to “Remove Association of Operator with User"
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.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
args uses the same json format as the json rpc api.
gas_cap defines the default gas cap to be used.
proposer_address of the requested block in hex format.
chain_id is the eip155 chain id parsed from the requested block header.
args uses the same json format as the json rpc api.
gas_cap defines the default gas cap to be used.
proposer_address of the requested block in hex format.
chain_id is the eip155 chain id parsed from the requested block header.
address is the ethereum hex address to query the storage state for.
key defines the key of the storage state
tracer is a custom javascript tracer.
timeout overrides the default timeout of 5 seconds for JavaScript-based tracing calls.
reexec defines the number of blocks the tracer is willing to go back.
disable_stack switches stack capture.
disable_storage switches storage capture.
debug can be used to print output during capture end.
limit defines the maximum length of output, but zero means unlimited.
homestead_block switch (nil no fork, 0 = already homestead).
dao_fork_block corresponds to TheDAO hard-fork switch block (nil no fork).
dao_fork_support defines whether the nodes supports or opposes the DAO hard-fork.
eip150_block: EIP150 implements the Gas price changes (https://github.com/ethereum/EIPs/issues/150) EIP150 HF block (nil no fork).
eip150_hash: EIP150 HF hash (needed for header only clients as only gas pricing changed).
eip155_block: EIP155Block HF block.
eip158_block: EIP158 HF block.
byzantium_block: Byzantium switch block (nil no fork, 0 = already on byzantium).
constantinople_block: Constantinople switch block (nil no fork, 0 = already activated).
petersburg_block: Petersburg switch block (nil same as Constantinople).
istanbul_block: Istanbul switch block (nil no fork, 0 = already on istanbul).
muir_glacier_block: Eip-2384 (bomb delay) switch block (nil no fork, 0 = already activated).
berlin_block: Berlin switch block (nil = no fork, 0 = already on berlin).
london_block: London switch block (nil = no fork, 0 = already on london).
arrow_glacier_block: Eip-4345 (bomb delay) switch block (nil = no fork, 0 = already activated).
gray_glacier_block: EIP-5133 (bomb delay) switch block (nil = no fork, 0 = already activated).
merge_netsplit_block: Virtual fork after The Merge to use as a network splitter.
shanghai_block switch block (nil = no fork, 0 = already on shanghai).
cancun_block switch block (nil = no fork, 0 = already on cancun).
chain_id is the id of the chain (EIP-155).
denom is the denomination used on the EVM.
decimals is the real decimal precision of the denomination used on the EVM.
enable_memory switches memory capture.
enable_return_data switches the capture of return data.
tracer_json_config configures the tracer using a JSON string.
block_number of the traced block.
block_hash (hex) of the traced block.
block_time of the traced block.
proposer_address is the address of the requested block.
chain_id is the eip155 chain id parsed from the requested block header.
block_max_gas of the traced block.
A URL/resource name that uniquely identifies the type of the serialized
protocol buffer message. This string must contain at least
one "/" character. The last segment of the URL's path must represent
the fully qualified name of the type (as in
path/google.protobuf.Duration
). The name should be in a canonical form
(e.g., leading "." is not accepted).
In practice, teams usually precompile into the binary all types that they
expect it to use in the context of Any. However, for URLs which use the
scheme http
, https
, or no scheme, one can optionally set up a type
server that maps type URLs to message definitions as follows:
https
is assumed.Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com.
Schemes other than http
, https
(or the empty scheme) might be
used with implementation specific semantics.
Must be a valid serialized protocol buffer of the above specified type.
size is the encoded storage size of the transaction (DEPRECATED).
hash of the transaction in hex format.
from is the ethereum signer address in hex format. This address value is checked against the address derived from the signature (V, R, S) using the secp256k1 elliptic curve.
tracer is a custom javascript tracer.
timeout overrides the default timeout of 5 seconds for JavaScript-based tracing calls.
reexec defines the number of blocks the tracer is willing to go back.
disable_stack switches stack capture.
disable_storage switches storage capture.
debug can be used to print output during capture end.
limit defines the maximum length of output, but zero means unlimited.
homestead_block switch (nil no fork, 0 = already homestead).
dao_fork_block corresponds to TheDAO hard-fork switch block (nil no fork).
dao_fork_support defines whether the nodes supports or opposes the DAO hard-fork.
eip150_block: EIP150 implements the Gas price changes (https://github.com/ethereum/EIPs/issues/150) EIP150 HF block (nil no fork).
eip150_hash: EIP150 HF hash (needed for header only clients as only gas pricing changed).
eip155_block: EIP155Block HF block.
eip158_block: EIP158 HF block.
byzantium_block: Byzantium switch block (nil no fork, 0 = already on byzantium).
constantinople_block: Constantinople switch block (nil no fork, 0 = already activated).
petersburg_block: Petersburg switch block (nil same as Constantinople).
istanbul_block: Istanbul switch block (nil no fork, 0 = already on istanbul).
muir_glacier_block: Eip-2384 (bomb delay) switch block (nil no fork, 0 = already activated).
berlin_block: Berlin switch block (nil = no fork, 0 = already on berlin).
london_block: London switch block (nil = no fork, 0 = already on london).
arrow_glacier_block: Eip-4345 (bomb delay) switch block (nil = no fork, 0 = already activated).
gray_glacier_block: EIP-5133 (bomb delay) switch block (nil = no fork, 0 = already activated).
merge_netsplit_block: Virtual fork after The Merge to use as a network splitter.
shanghai_block switch block (nil = no fork, 0 = already on shanghai).
cancun_block switch block (nil = no fork, 0 = already on cancun).
chain_id is the id of the chain (EIP-155).
denom is the denomination used on the EVM.
decimals is the real decimal precision of the denomination used on the EVM.
enable_memory switches memory capture.
enable_return_data switches the capture of return data.
tracer_json_config configures the tracer using a JSON string.
block_number of requested transaction.
block_hash of requested transaction.
block_time of requested transaction.
proposer_address is the proposer of the requested block.
chain_id is the eip155 chain id parsed from the requested block header.
block_max_gas of the block of the requested transaction.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
block height at which to query.
channel unique identifier
channel port identifier
packet sequence
block height at which to query.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
Height to query at.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
unique channel identifier
unique port identifier
unique channel identifier
the relayer address to which the counterparty is registered
unique channel identifier
the relayer address to which the distribution address is registered
channel unique identifier
channel port identifier
packet sequence
channel unique identifier
channel port identifier
packet sequence
channel unique identifier
channel port identifier
packet sequence
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
block height at which to query.
channel unique identifier
port unique identifier
revision number of the consensus state
revision height of the consensus state
channel unique identifier
port unique identifier
channel unique identifier
port unique identifier
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
list of packet sequences.
channel unique identifier
port unique identifier
packet sequence
channel unique identifier
port unique identifier
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
channel unique identifier
port unique identifier
list of acknowledgement sequences
channel unique identifier
port unique identifier
list of packet sequences
channel unique identifier
port unique identifier
packet sequence
channel unique identifier
port unique identifier
packet sequence
connection unique identifier
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
connection identifier
client identifier
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
client identifier
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
client identifier
consensus state revision number
consensus state revision height
latest_height overrrides the height field and queries the latest stored ConsensusState.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
CodeHash is the hash of the code.
CreatorAddress is the address of the contract instantiator.
Salt is a hex encoded salt.
InitArgs are optional json encoded init args to be used in contract address building if provided.
address is the address of the contract to query
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
address is the address of the contract
QueryData contains the query data passed to the contract
address is the address of the contract
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
CreatorAddress is the address of contract creator
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
When called from another module, this query might consume a high amount of gas if the pagination field is incorrectly set.
Since: cosmos-sdk 0.43
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
Since: cosmos-sdk 0.46.2
Deprecated, use account_id instead
id is the account number of the address to be queried. This field should have been an uint64 (like all account numbers), and will be updated to uint64 in a future version of the auth query.
account_id is the account number of the address to be queried.
Since: cosmos-sdk 0.47
When called from another module, this query might consume a high amount of gas if the pagination field is incorrectly set.
address is the address to query balances for.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
resolve_denom is the flag to resolve the denom into a human-readable form from the metadata.
Since: cosmos-sdk 0.50
address is the address to query balances for.
denom is the coin denom to query balances for.
When called from another module, this query might consume a high amount of gas if the pagination field is incorrectly set.
Since: cosmos-sdk 0.46
denom defines the coin denomination to query all account holders for.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
Since: cosmos-sdk 0.50.3
denom defines the coin denomination to query all account holders for.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
This query only returns denominations that have specific SendEnabled settings. Any denomination that does not have a specific setting will use the default params.default_send_enabled, and will not be returned by this query.
Since: cosmos-sdk 0.47
denoms is the specific denoms you want look up. Leave empty to get all entries.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
When called from another module, this query might consume a high amount of gas if the pagination field is incorrectly set.
Since: cosmos-sdk 0.46
address is the address to query spendable balances for.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
When called from another module, this query might consume a high amount of gas if the pagination field is incorrectly set.
Since: cosmos-sdk 0.47
address is the address to query balances for.
denom is the coin denom to query balances for.
When called from another module, this query might consume a high amount of gas if the pagination field is incorrectly set.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
When called from another module, this query might consume a high amount of gas if the pagination field is incorrectly set.
denom is the coin denom to query balances for.
Since: cosmos-sdk 0.46
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
Optional, msg_type_url, when set, will query only grants matching given msg type.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
Since: cosmos-sdk 0.46
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
Since: cosmos-sdk 0.46
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
validator_address defines the validator address to query for.
delegator_address defines the delegator address to query for.
validator_address defines the validator address to query for.
validator_address defines the validator address to query for.
starting_height defines the optional starting height to query the slashes.
starting_height defines the optional ending height to query the slashes.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
hash defines the evidence hash of the requested evidence.
Since: cosmos-sdk 0.47
evidence_hash defines the hash of the requested evidence. Deprecated: Use hash, a HEX encoded string, instead.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
proposal_status defines the status of the proposals.
voter defines the voter address for the proposals.
depositor defines the deposit addresses from the proposals.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
proposal_id defines the unique id of the proposal.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
proposal_id defines the unique id of the proposal.
depositor defines the deposit addresses from the proposals.
proposal_id defines the unique id of the proposal.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
proposal_id defines the unique id of the proposal.
voter defines the voter address for the proposals.
proposal_status defines the status of the proposals.
voter defines the voter address for the proposals.
depositor defines the deposit addresses from the proposals.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
proposal_id defines the unique id of the proposal.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
proposal_id defines the unique id of the proposal.
depositor defines the deposit addresses from the proposals.
proposal_id defines the unique id of the proposal.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
proposal_id defines the unique id of the proposal.
voter defines the voter address for the proposals.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
Since: cosmos-sdk 0.46
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
granter is the address of the user granting an allowance of their funds.
grantee is the address of the user being granted an allowance of another user's funds.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
When called from another module, this query might consume a high amount of gas if the pagination field is incorrectly set.
delegator_addr defines the delegator address to query for.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
When called from another module, this query might consume a high amount of gas if the pagination field is incorrectly set.
delegator_addr defines the delegator address to query for.
src_validator_addr defines the validator address to redelegate from.
dst_validator_addr defines the validator address to redelegate to.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
When called from another module, this query might consume a high amount of gas if the pagination field is incorrectly set.
delegator_addr defines the delegator address to query for.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
When called from another module, this query might consume a high amount of gas if the pagination field is incorrectly set.
delegator_addr defines the delegator address to query for.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
delegator_addr defines the delegator address to query for.
validator_addr defines the validator address to query for.
When called from another module, this query might consume a high amount of gas if the pagination field is incorrectly set.
status enables to query for validators matching a given status.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
When called from another module, this query might consume a high amount of gas if the pagination field is incorrectly set.
validator_addr defines the validator address to query for.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
validator_addr defines the validator address to query for.
delegator_addr defines the delegator address to query for.
validator_addr defines the validator address to query for.
delegator_addr defines the delegator address to query for.
When called from another module, this query might consume a high amount of gas if the pagination field is incorrectly set.
validator_addr defines the validator address to query for.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
events is the list of transaction event type. Deprecated post v0.47.x: use query instead, which should contain a valid events query.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
page is the page number to query, starts at 1. If not provided, will default to first page.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
query defines the transaction event query that is proxied to Tendermint's TxSearch RPC method. The query must be valid.
Since cosmos-sdk 0.50
Since: cosmos-sdk 0.45.2
height is the height of the block to query.
key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set.
offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set.
limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app.
count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set.
reverse is set to true if results are to be returned in the descending order.
Since: cosmos-sdk 0.43
last height of the current chain must be sent in request as this is the height under which next consensus state is stored
Since: cosmos-sdk 0.43
module_name is a field to query a specific module consensus version from state. Leaving this empty will fetch the full list of module versions from state.
client unique identifier.
the proof to be verified by the client.
the value which is proven.
Since: cosmos-sdk 0.47
TxDecodeRequest is the request type for the Service.TxDecode RPC method.
Since: cosmos-sdk 0.47
tx_bytes is the raw transaction.
Since: cosmos-sdk 0.47
TxDecodeAminoRequest is the request type for the Service.TxDecodeAmino RPC method.
Since: cosmos-sdk 0.47
Since: cosmos-sdk 0.47
TxEncodeAminoRequest is the request type for the Service.TxEncodeAmino RPC method.
Since: cosmos-sdk 0.47
BroadcastTxRequest is the request type for the Service.BroadcastTxRequest RPC method.
tx_bytes is the raw transaction.
BroadcastMode specifies the broadcast mode for the TxService.Broadcast RPC method.
BROADCAST_MODE_UNSPECIFIED
Possible values: SimulateRequest is the request type for the Service.Simulate RPC method.
tx_bytes is the raw transaction.
Since: cosmos-sdk 0.43