SDK Specification
Abstract
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
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
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
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
The TX ID is sent back to the Server Side component
The TX ID is used to show the user the Transaction Widget, monitoring the proper transaction
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:
The user needs to provide both source and target addresses - (possibly) connecting 2 wallets to the Transfer Widget
The user retains more control over the currency and amount
Both addresses are included in the transaction sent by the Server Side component to the RPC node
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