Tenant setup options

Blockchain providers, cloud providers, authentication types typical cases

There is a set of basic configurations which should be defined when new tenant is setup. Necessary tenant setup configuration is defined by TEOS API consumer requirements. We collected typical setup configurations which were used so far and described it below. If you are looking for some other options, they can be discussed upon a request.

Blockchain provider

Blockchain options:

• Ethereum Mainnet - you get access to global public Ethereum network using PoS, read more
• SparkNet - private Ethereum based network, used for pilot and productive solutions mainly, read more
• DevilNet - private Ethereum based network run by CoreLedger, used for development purposes mainly

• Your option can be discussed upon a request

	Ethereum Mainnet	SparkNet	DevilNet
Transaction processing time	is more than for other options, estimated in minutes (strongly depends on amount of available nodes and amount of transactions to be processed) Check current statistics	comparatively low, estimated in seconds Check current statistics	comparatively low, estimated in seconds, but more than in SparkNet
Transaction cost	varies, but definitely higher than for other options Read more and Check current statistics	stable and 0 (gas required for signing transactions is distributed automatically to newly registered addresses)	stable and 0 (gas required for signing transactions is distributed automatically to newly registered addresses)

Authentication type

The authentication process for TEOS API consumers is described in Authentication. The description below can help you decide on which option to go.

One tenant can have several TEOS API consumers, they can have different authentication types.

Using TEOS API with API key

Main characteristics of TEOS API consumer for such case:

• TEOS API consumer is a self-sufficient system with server-side

• The server side is designed to perform communication with TEOS API

• TEOS API consumer has its own authentication system for its users

With such an option all operations in TEOS API are performed on behalf of the TEOS API consumer representative registered in the TEOS platform, we call him or her "administrator". An administrator (or several if needed) is registered in the TEOS Platform to configure TEOS API processes and maintain them. API key is generated for the admin user. End users of the TEOS API consumer are authenticated by the TEOS API consumer.

Using TEOS API with the user access token

Main characteristics of TEOS API consumer for such case:

• TEOS API consumer is a client application without a backend on the server side and/or without its own authentication system

• TEOS API consumer is a WLA-based application

With such an option, the TEOS Authentication service is used to authenticate end users. User account data is stored in TEOS authentication service. The integration with TEOS authentication service is a prerequisite for using TEOS API flows.