Generating Deposit Addresses for Users

When generating an address, you have the option to choose between 3 security models:

• 1: 81-trit security (low)

• 2: 162-trit security (medium)

• 3: 243-trit security (high)

We advise exchanges to use level 3 security (243-trit) for all addresses that are generated for hot, cold wallet and multisignatures. For efficiency reasons, security level 2 for user deposits is sufficient.

In addition to that, when it comes to addresses that are being used for back-end (internal shuffling around of balances) and front-end (user deposits), we advise exchanges to always generate and enforce address checksums. This is especially important for user-related functions (e.g. processing withdrawal), as users sometimes make the mistake of handing out the wrong address. Check the respective utility functions addChecksum, isAddress and isValidChecksum

iota.api.getNewAddress(seed, {index: 0 , total: 1, security: 3, checksum: true}, function(e, address) {
    console.log(address)
    // Save generated address in database
})

Deposit Address Generation & Management

For exchanges it is important that each user is assigned a unique address for each deposit. This prevents address reuse and ensures that all user funds are safe. Because of that, we advise exchanges to generate and assign a unique seed to each user and carefully track whether key indices were already used as input for a previous transaction (i.e. swept from), and should therefore no longer be used.

If exchanges are not able to generate and store a new seed for each user and instead prefer to use a single seed (or multiple) for the deposit addresses, we advise to use a relational database and carefully assign a unique key index to a user for each deposit. Before generating an address, the table of assigned and spent key indices should be queried to ensure that the right key index will be assigned to a user. Please be aware that this approach comes with hard concurrency issues which the exchanges will need to solve (e.g. atomicity of these checks and marking key indices as used).

State	Description
Assigned	The key was assigned to a user.
Spent	The key index with the respective address was already used in a previous transaction, and as such should no longer be used