KiiChain

We express our gratitude to the KiiChain team for the collaborative engagement that enabled the execution of this Blockchain Protocol Security Assessment.

KiiChain is a blockchain project focused on stablecoins and real-world assets, aimed at supporting practical financial use cases. Its broader goal is to improve utility, liquidity, and accessibility for users, businesses, and developers, particularly in emerging markets.

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

• All four custom modules have substantive README files covering state, messages, flows, and edge cases.

• Protobuf definitions have service- and message-level comments; field-level documentation would benefit from more consistent coverage.

• Additional committed documentation includes an EVM upgrade guide and a security vulnerability report in contrib/docs/. The project would benefit from formal specifications to capture design rationale.

• Godoc comments on exported keeper functions are present but brief — more detailed parameter and behavioral documentation would improve maintainability.

• The custom ante handler chain (23 Cosmos decorators, 2 EVM) is documented through inline comments; a standalone design document would help clarify the interaction between fee abstraction, oracle fee exemption, and the EVM path.

Code quality

• All custom modules have unit tests covering keepers, message servers, types, and genesis. The ante/ package and fee abstraction ante decorators also have test coverage.

• The fee abstraction ante decorators are documented forks of the SDK's DeductFeeDecorator and the cosmos/evm mono decorator, with behavioral changes noted in each file's header.

• Simulation test support exists only for tokenfactory.

• 16 linters enabled (including gosec, staticcheck, govet, errcheck, revive) and enforced in CI.

• Error handling in ABCI hooks is sound — errors propagate to callers; non-critical failures are logged and skipped.

• A small number of TODO comments remain in production code.

• CI runs unit tests with coverage (Codecov) and linting on PRs. A separate e2e workflow runs on pushes to main and PRs targeting main.

Architecture quality

• Decentralization: No sudo or admin-privileged module exists. All custom module governance operations route authority through x/gov. Oracle votes are restricted to bonded validators or their delegated feeders. MsgFundPool and MsgCreateDenom are callable by any account; tokenfactory mint, burn, force transfer, and metadata operations require per-denomination admin status.

• Resilience: Fee abstraction self-disables when the native denomination's oracle TWAP becomes unavailable, and independently disables individual fee tokens with missing TWAPs. The oracle handles empty ballot periods gracefully. Price clamping limits per-block fee token price movement.

• Interoperability: Custom CosmWasm plugins expose oracle, EVM, tokenfactory, and bech32 queries to contracts, and tokenfactory message execution. A custom oracle EVM precompile exposes exchange rates to Solidity contracts. The IBC transfer stack is extended with Packet Forward Middleware and rate limiting.

• Module dependencies: Fee abstraction depends on oracle, ERC20, and bank keepers at runtime — failures can cascade into fee processing, partially mitigated by self-disabling. The rewards module must remain first in BeginBlocker order to feed coins to distribution.

KiiChain is a Cosmos SDK appchain built on CometBFT consensus with two integrated smart contract runtimes: an EVM and CosmWasm. IBC-Go provides cross-chain communication. The daemon binary is kiichaind, the native denomination is akii.

The chain extends the standard Cosmos module set with four custom modules, and bridges native functionality into both contract runtimes via EVM precompiles and CosmWasm custom plugins.

Custom Modules

• Oracle (x/oracle) Decentralized price feed. Validators or delegated feeders submit aggregate exchange rate votes via MsgAggregateExchangeRateVote. Feeder delegation is managed through MsgDelegateFeedConsent. The keeper depends on AccountKeeper, BankKeeper, and StakingKeeper. EndBlock (on the last block of each VotePeriod) tallies submitted ballots by denomination against a reference denom, persists weighted-median exchange rates, records per-validator success/miss/abstain counts, clears votes, applies the whitelist, and writes a PriceSnapshot. BeginBlock (on the last block of each SlashWindow) slashes validators who missed vote obligations and prunes stale exchange rates. Two ante decorators — VoteAloneDecorator and SpammingPreventionDecorator — enforce oracle transaction rules.

• Token Factory (x/tokenfactory) Permissionless denomination creation and management. Any account can create native coins under factory/{creator}/{subdenom} via MsgCreateDenom. The denom admin can mint (MsgMint), burn (MsgBurn), force-transfer (MsgForceTransfer), change admin (MsgChangeAdmin), and set bank metadata (MsgSetDenomMetadata). Burn-from, force-transfer, and set-metadata operations are gated by enabledCapabilities on the keeper. The keeper depends on AccountKeeper, BankKeeper, and CommunityPoolKeeper. No BeginBlock or EndBlock logic. This is the only custom module exposed to CosmWasm contracts for both queries and message execution.

• Fee Abstraction (x/feeabstraction) Allows fees to be paid in non-native tokens. The keeper depends on BankKeeper, Erc20Keeper, and OracleKeeper. BeginBlock fetches TWAPs from the oracle over a configured lookback window and updates per-fee-token prices (with clamping); if the native oracle denom has no valid TWAP, the module disables itself by writing Enabled = false to params. At transaction time, custom ante decorators (one for Cosmos txs, one for EVM txs) call ConvertNativeFee. This checks whether the user has sufficient native balance; if not, it iterates enabled fee tokens, computes the ceiling-rounded equivalent amount, and attempts to source it from the user's bank balance or via ERC20-to-native conversion through the erc20Keeper. The first successful token is used, and a convert_fees event is emitted. Governed by MsgUpdateParams and MsgUpdateFeeTokens.

• Rewards (x/rewards) Time-based linear reward distribution. Stores a RewardPool, a ReleaseSchedule (with TotalAmount, ReleasedAmount, EndTime, LastReleaseTime, Active), and Params. BeginBlock computes a linear proportion of remaining rewards based on elapsed seconds, sends that amount from the rewards module account to the fee collector via SendCoinsFromModuleToModule, and updates the schedule. In the begin block ordering, rewards runs before distribution, ensuring released coins are included in the standard validator/delegator distribution. Anyone can fund the pool via MsgFundPool; schedule and params are governance-controlled.

EVM Precompiles

Static precompiles extend the Berlin set with: bech32 and p256 (stateless), plus staking, distribution, ics20, bank, gov, slashing, and a custom oracle precompile (stateful). These are registered in app/keepers/precompiles.go and give Solidity contracts direct access to native chain operations.

CosmWasm Bindings

Custom plugins registered in wasmbinding/ expose four query types to contracts — TokenFactory, EVM, Bech32, Oracle — and one message type — TokenFactory (create, mint, burn, transfer, change admin, set metadata).

IBC Stack

Assembled in app/keepers/keepers.go. The transfer stack layers Rate Limiting over Packet Forward Middleware over IBC Callbacks over the base transfer module. The ICA controller is wrapped with IBC Callbacks; the ICA host runs standalone. A wasm IBC handler is registered on its own port and serves as the contract keeper for callback dispatch. A separate IBCv2 transfer stack with callbacks and rate limiting is also configured.

The scope of the project includes the following components from the provided repository:

Assets in Scope