@kwenta/sdk v1.2.0

Kwenta SDK

Note: This document is a work in progress, as the implementation of the Kwenta SDK is still in progress. Interfaces, types and overall structure are subject to change.

Architecture

The SDK is a collection of multiple classes, objects and functions which can generally be categorized as follows:

Context

The context class (pending implementation) contains attributes that are used by other classes, especially services (see the section below), to determine what context they are being called in. For example, the context class contains information about the provider, signer, wallet address and network ID.

Services

Services are collection of methods that function together to enable. We have services for futures, exchange, synths and transactions. A service's methods are available under sdk.[service-name]. While services function independently for the most part, they may also call methods on other services.

Events

In certain situations where the SDK needs to inform a client about data changes (for example, exchange rate updates), we emit events that clients can listen to.

Contracts

Based on the currently selected networkId, we maintain a list of available contracts in the context, used for subsequent contract calls. When there is an attempt to access a contract that is not available on the network, an error is thrown.

Synths

Similarly to contracts, we maintain a list of synths on the current network, which is used for fetching balances, synth names etc.

Testing

One of the main benefits of extracting Kwenta's logic into an SDK is the ability to test business logic independently of the UI. The tests folder will contain a number of unit and integration tests that will help us remain confident in the functionality of the SDK, as well as our ability to output sensible errors when one or more of our dependencies do not behave as expected. These tests will also be updated frequently as new features are added and bugs are fixed.