SDK Specification


The SDK enables dApp developers to process Kima transactions on behalf of their clients.

It will include visual and API components that communicate with the Kima RPC nodes. The developers can pick and choose the right level of integration, based on their usage scenario.

SDK Components

Client Side

The client components are a set of React/TypeScript components, encapsulating the desired look and feel of the interaction with the Kima chain. They will be responsive (support mobile), and highly configurable (theme, captions, etc.)

The client components have 3 tasks:

1. Interact with the user’s preferred wallet, and get his approval

2. Collect the parameters’ needed for the transaction

3. Monitor the transaction status, and communicate it to the user

There are 2 main React components:

1. Transfer widget - a form, assisting in collecting the necessary parameters for the transaction

2. Transaction widget - a visual component that monitors the transaction status, once submitted

Server Side

The server side component will be presented as a Docker container, that the developer will deploy to his dApp server side. It’s purpose is to compose, sign, and submit a transaction to the Kima RPC node.

Once the user is done providing the needed parameters and approval, the parameters are submitted to the Server Side component, verified, the target address is added, the transaction is signed with the developer’s Kima key, and it’s sent to the Kima RPC node.

Flow: Payment Scenario

  1. User wishes to interact with a dApp with funds they have on a different chain

    • They request to use their remote liquidity

    • The dApp’s client responds by presenting a form that features the Transfer Widget

    • Because this is a payment scenario, the target wallet is not selectable in the form (as it is the dApp’s wallet)

    • The developer may decide to pre-set other elements: the currency, the amount, the chains they’re willing to support etc., using the Transfer Widget’s parameters

  2. The widget initiates an ERC20/SPL20/BEP20 APPROVE transaction between the user’s wallet and the Kima origin pool

    • The user approves it in his wallet’s interface

    • This may take time and cost gas - paid by the user

    • The approval sum depends on the developer’s needs and the user’s input 3. Once the approval is received, the form is submitted to the Server Side component

  3. The Server Side component verifies all parameters: origin chain, address, sum, currency symbol

    • In a payment scenario, it now adds the dApp’s target blockchain and address to the transaction

    • It uses the dApp’s Kima private key to sign the transaction

    • The signed transaction is submitted to the Kima RPC node

  4. The TX ID is sent back to the Server Side component

  5. The TX ID is used to show the user the Transaction Widget, monitoring the proper transaction

  6. Meanwhile, the blockchain is validating and processing the transaction:

    • It debits the user wallet to the origin pool

    • It pays the dApp wallet from the target pool

    • The transaction is marked PAID and the scenario is done

Flow: Bridge Scenario

Sequence Diagram

A bridge scenario is similar to Payment with a few distinctions:

  1. The user needs to provide both source and target addresses - (possibly) connecting 2 wallets to the Transfer Widget

  2. The user retains more control over the currency and amount

  3. Both addresses are included in the transaction sent by the Server Side component to the RPC node

  4. The user can be presented with 3 links at the conclusion of the transaction:

    • Origin chain explorer

    • Destination chain explorer

    • Kima chain explorer

A secure connection between the Client and Server components

Sequence Diagram

We’re going to be using JWT (JSON Web Tokens) cookies, to make sure only the client component talks to the server component.

Last updated