Skip to main content

Overview

KIRA’s base layer (SEKAI) handles governance, token transfers, multi-staking, and all other system security-related on-chain logic. At the same time, SEKAI assists in the execution of decentralized applications taking place on their dedicated off-chain subnets by enabling their orchestration, communication, and settlement. This separation enables parallel scaling of execution, storage, and networking capabilities of each application. KIRA applications, also known as RollApps, consist of an execution container defining application logic, and a verification container defining how changes in an application state can be verified.

KIRA by default pessimistically assumes incorrectness of all L2 computations. It only allows for application state settlement if the developer-programmable consensus of nodes verifies the application execution. This is in contrast to optimistic rollup systems which by default assume the correctness of all computations unless fraud proofs are presented which unnecessarily prolong the settlement process even if all network participants agree that the application state transitions are correct.

Application Submission​

Before a dApp can be deployed on the KIRA network, it must go through an on-chain governance proposal process. This prevents spam applications and ineffective code from launching. The proposal is submitted by controllers; this proposal also signals the requirements for running the application. A minimum bond in KEX tokens is required to raise the proposal, ensuring developer commitment. A minimum bond must also be reached before the proposal duration ends for the application to be accepted. The minimum bond can be crowdsourced across collaborators. If it is not reached before the end of the proposal period, the dApp is rejected and bonds are returned. There is also a maximum bond that caps total deposits. Once approved through governance, dApp tokens representing ownership are minted and paired with the bonded KEX in a v2 Uniswap pool.

This permissionless, crowdsourced process is similar to Polkadot parachain auctions. However, the bonded KEX crowdsourced through the proposal remain liquid: Upon approval, dApp tokens representing ownership are minted and paired with the bonded KEX in a Uniswap v2-like pool and the LP tokens are distributed to all investors who contributed to crowdsource.

note

More information about the crowdsourcing mechanism is described in Initial Liquidity Offering page.

Permissioned Execution, Permissionless Verification​

There are two primary roles for participation in a RollApp execution process - Executors and Verifiers, also referred to as Fishermen.

KIRA’s Validators have the option to take on either or both of these roles, they are not compelled and do not need to post a bond to take these roles. This is to ensure they can adapt their hardware to suit the application's needs and avoid running content that may pose legal issues in their operating region. However their participation is subject to approval by controllers (application owners), and they can be evicted from SEKAI validator set if acting maliciously. If a validator becomes an Executor, they will run the execution container and serve as Leader for Sessions, proposing state changes while also automatically taking on the role of Verifier when not actively leading a Session.

Any users can permissionlessly become Fishermen, i.e. if they have vested interest in this application. They are not subject to approval by controllers, but must submit a bond in the dApp's liquidity pool tokens. The bond amount is set via governance, defaulting to 0.1% of the pool’s total LP tokens circulating supply. In summary, validators can opt-in to run as Executors or Verifiers, pending approval. Other users can freely become Fishermen verifiers by providing a bond.

The key difference between the Executor and Verifier lies in their responsibilities and how each role is held accountable. Only Executors can become Leaders and propose state changes for an application, while Fishermen solely verify its integrity. Executors are held accountable by risking their validation role and income if removed for misconduct. Fishermen are accountable through the verifier bond they post in tokens, which can be slashed for faulty verification.

Sessions​

In KIRA's Layer 2, computation occurs in timed periods called Sessions, similar to the "challenge periods" in Ethereum optimistic rollups. However, unlike Ethereum rollups which optimistically assume correct execution, KIRA pessimistically assumes incorrect results, and only settles state if sufficient verifications occur in a given Session.

A session proceeds as follows:

  • A single Executor acts as the Session leader and performs computation, proposing a new application state root (the hash of the new app database state) and account balances changes on SEKAI. The leader can only be an active validator and is chosen in equal round-robin fashion among existing application’s Executors.
  • Immediately after the current Executor finishes execution, the next leader optimistically start executing its own session. This mechanism allows for continuous execution without waiting for the prior session's full verification to complete. In rare scenarios where a session was skipped (i.e. Leader timed out) and the following one was not properly executed, both sessions can be discarded, although this is unlikely to occur.
  • Other Executors act as Verifier and collect the leader results and cast their approval on proposed state changes. The end of the session and settlement requires over 2/3 Executor participation and unanimous agreement. In cases where the application has only one Executor, the end of the session relies on the approval of no less than 2/3 of all active Verifiers.
  • Meanwhile multiple verifier nodes (Fishermen) verify integrity of the leader's execution. They can halt settlement if they find incorrect state transitions, but cannot finalize settlement, only Executors can.
note

The number of Verifiers (fishermen) is uncapped and can be much greater than the number of Executors. However, there is only one Leader at any point in time,