# [About the IOTA SDK](https://wiki.iota.org/next/iota-sdk/about-the-iota-sdk/)

The IOTA SDK is a Rust-based project that provides a convenient and efficient way to interact with nodes in the Shimmer and IOTA networks running the Stardust protocol. It consists of two main modules: client and wallet.

The client module is stateless. It aims to provide more flexibility and access to low-level functions.

The wallet module is stateful, with a standardized interface for developers to build applications involving value transactions. It uses high-level functions that simplify everyday operations. It can optionally interact with IOTA Stronghold for seed handling, storage, and state backup.

You can use this documentation to get your wallet or client up and running in the programming language of your choice, connect to the testnet, explore the network, and get test tokens to develop your application.

## Available Programming Languages
The IOTA SDK is written in Rust and also has convenient bindings in Node.js, Python and Wasm.

Each of these languages has specific instructions you will need to follow to use IOTA SDK in your project. Every binding is adjusted for the language's conventions and best practices. For example, Python developers avoid the Builder programming pattern, so our Python binding uses named constructor arguments. However, we always keep the meaning behind our API, which is equally powerful no matter which language you choose.

## Your Application In the IOTA Network
Your application communicates directly with the IOTA SDK in Rust or through one of the language bindings. IOTA SDK turns your requests into REST API calls and sends them to a node through the Internet. The node, in turn, interacts with the rest of an IOTA network, which could be the main operational network (mainnet) or a network for testing purposes (testnet).

## Secure Secret Management
You can use Stronghold for secure secret management. Stronghold can store the encrypted seed at rest. It is not possible to extract the seed from Stronghold for security purposes. Stronghold uses encrypted snapshots that can easily be backed up and securely shared between devices. These snapshots are further secured with a password.

## Join the Discussion
If you want to get involved in discussions about this library, or you're looking for support, go to the #iota-sdk channel on Discord.

# [Getting Started with Rust](https://wiki.iota.org/next/iota-sdk/getting-started/rust/)

## Install the SDK Using Cargo
* `Cargo.toml` dependency is wrong, that's not how you would include it; needs to be pulled from `crates.io`;

## Usage
* update the example code with the latest (see examples/wallet/getting_started.rs);

# [Getting Started with Wasm](https://wiki.iota.org/next/iota-sdk/getting-started/wasm/)

## Before You Start
The IOTA SDK library also offers dedicated Node.js bindings. The differences with this package are outlined below.

The Node.js bindings only needs to be compiled during npm install if a pre-compiled binary is not available for your platform.

# [Account Approaches](https://wiki.iota.org/next/iota-sdk/explanations/account-approaches/)
In the IOTA SDK, you can use an account model to create an account for each user or use one account and generate multiple addresses, which you can then link to the users in your database. The SDK is as flexible as possible and can back up any of your use cases.

The SDK supports derivation for multiple accounts from a single seed. An account is a deterministic identifier from which multiple addresses can be derived.

The SDK also allows consumers to assign a meaningful alias to each account. Since addresses are reusable, they can be mapped to your users clearly and concisely.

## Multi-Account Approach
Use the multi-account approach to create an account for each user. You can link the accounts to the internal user IDs as an account alias, which are distinctly separated.

## Single Account Approach
You should use the single account approach to create a single account and then create an address for each user. You will need to link the associated addresses to the internal user IDs and store who owns which address in a database. Most exchanges are familiar with the single account approach and find it easier to use, implement, and back up.