Tokenization

Nexus' tokenization solution enables custom token ecosystems in which you can easily create and manage a variety of supported tokens like Electronic Money Tokens (EMTs), Utility tokens, Security tokens, Stablecoins and Asset-Referenced Tokens (ARTs).

General description of the tokenization model.

Blockchain

The token operations you will carry out on behalf of your customers imply the payment of a fee on a blockchain to confirm the operation. The crypto of this blockchain, also called the native asset of the blockchain, is needed to pay the transaction fees. Our tokenization solution is developed to run on the below blockchains:

Stellar
Algorand

Issuer account

In Nexus we manage the token issuing through issuer accounts, which are basically accounts that hold the balances regarding any token issued from the native crypto of the blockchain.

Token

A token is a digital asset that can be created to give another asset an economic value. For instance, a token called BURGER could represent a token used to pay the delivery services online, which has a fixed known value and can be used to pay for the food.

External Tokens

A token is defined as external within Nexus if its transaction envelope signing required by this token, cannot be done internally by Nexus, due to its private key used for signing not being stored within Nexus.

An external token in Nexus can be set up by creating the token independent of Nexus, and then adding it to Nexus by going to the portal and selecting the Add External button. During this action, Nexus asks for the token's address, but note the token's private key is never shared with Nexus. This means all future transaction envelope signing required by the token, cannot be done internally by Nexus, and will have to be done externally by the client independent of Nexus.

This functionality is not available for currency pegged tokens but only for asset pegged tokens and only available for tokens on the Stellar blockchain.

Internal Tokens

A token is defined as internal within Nexus if its transaction envelope signing required by this token, can be done internally by Nexus, due to its private key used for signing being stored within Nexus. An internal token in Nexus can be set up in two different ways:

Creating an internal token

Create an internal token using Nexus, by either calling on our create token API or going to the portal and selecting the create internal button.

During the creation process, Nexus generates a new keypair, sets the new token's issuer address equal to the new keypair's public key, and stores the private key within Nexus. This means all future transaction envelope signing required by the token, will be done internally by Nexus.

This functionality is available for currency pegged tokens and for asset pegged tokens.

Importing an internal token

Import an internal token into Nexus, by creating it independent of Nexus, and then importing it into Nexus by going to the portal and selecting the import internal button.

At the moment, importing an internal token is only possible for tokens on the Algorand blockchain.

During the import process, Nexus first checks that the token provided by the user, exists outside of Nexus and on the Algorand blockchain. Nexus then asks the user to update their token, by setting its reserve, freeze and clawback addresses equal to the public key of a new keypair generated by us, and to transfer the token's total supply to this new address. The private key of this new keypair is stored within Nexus. After this the token can be successfully imported into Nexus.

Importing an internal token means a token's creator and manager address will differ to that of the token's reserve, freeze and clawback address, and that all future transaction envelope signing required by the token, will still be done internally by Nexus, while ownership of the token still sits with the client. Client token ownership means that the token's creator and manager address' private key is not stored within Nexus, and that the client has the power to at any stage, change the token's reserve, freeze and clawback address to remove any access which Nexus had to the token, and clawback all tokens.

This functionality is only available for currency pegged tokens, and not asset pegged.

NOTE

Imported internal tokens supports the separation of token ownership and the operational token activities. It is especially relevant in regulated environments where ownership should be connected to the license holder, for example electronic money tokens (EMTs) under MiCAR regulations. By importing a token, ownership still sits with the client due to the creator address' private key not being stored in Nexus. The creator's address can at any stage be used to change the token's reserve account, to remove any access which Nexus had to the token.

NOTE

We provide a separate command-line tool (Algorand Token Creation (C#)) to allow for token creation independent of the Nexus platform. This tool can be used by our partners (in consultation with us if needed) to create new tokens and take ownership of the private key of the Creator account. The private key of this Creator account is only shared once with the operator of the tool.

Pegged token

A pegged token is basically a newly issued token whose value is pegged (i.e. linked to) another collateral asset. As an example, either metals (e.g. gold, silver) or fiat currencies (e.g. dollars, euro) are assets to which token are often pegged to.

Currency-Pegged Token (CPT)

As explained just above, fiat currencies are an asset to which it makes sense to peg a token. The main reason stands in the lower volatility that fiat currencies have compared to other crypto-currencies (e.g. Bitcoin).

CPT balance

Currency-Pegged token balance is the result of tokens issued by the issuer minus tokens burned (CPT balance = issued tokens - burned tokens).

Asset-Pegged Token (APT)

Another way to create a pegged token consists in pegging it to an asset, which could be a real-life painting, an item or simply the representation of something that has no (need for a) specific monetary value. These assets can either be controlled by Nexus or by some external party.

APT balance

Balances do not apply to APTs as they are not pegged by a fiat currency nor they have a value of reference.

Stable coin

A stable coin is basically the same concept as a pegged token, in the sense that it is a token which value is linked to the value of a collateral asset (e.g. fiat currency or another token).

Taxonomy

Taxonomy can optionally be added to a token at token creation stage. Since a token cannot be changed on the blockchain once it has been created, taxonomy provides a token on a blockchain with more meaning than just a code. To add taxonomy to a token, you need to define the set of properties your token must adhere to (called a schema). Now when you create your token, you specify the schema you created, along with a set of properties. These properties are validated against the schema and hashed using SHA256. This hash is stored encoded as a token property on the blockchain. Alternatively, you can provide a hash to store on the blockchain, instead of having to provide a taxonomy schema and properties to calculate one, but note a provided hash is not validated in any way. You can also add an asset URL to the taxonomy of the token. This URL can refer to a webpage describing the asset or can contain a JSON representation of the token properties. It is possible to verify that a token's properties have not been changed by using the hash.

Transactions

There are different types of transactions available in the tokenization model of Nexus. In the following sections you will find details on how they are implemented.

NOTE

In case of a time-out from the relevant blockchain, Nexus will retry 3 times to resubmit the transaction.

Swap

A swap transaction allows to interchangeably switch from a token to another one during a payment transaction. For instance, imagine the case in which a customer wants to pay with the token EXAMPLE1, but the merchant they want to pay only supports the token EXAMPLE2. The payment can be completed with a swap operation, which translates the value between the tokens EXAMPLE1 and EXAMPLE2 based on another token, which is pegged to a fiat currency (e.g. Euro).

Trade

A trade transaction allows customers to exchange tokens at a specified rate, which allows trading at rates different from the fixed one as well as in scenarios where no rate between two distinct tokens can normally be determined. This is particularly useful to exchange Asset-Pegged tokens.

Order

An order allows customer to initiate buy/sell offers. These offers are checked against an existing orderbook and either filled in if they matches or saved on the orderbook until it is either consumed by another order, consumed by a path payment, or canceled by the account that created the order on a price-time priority.

Transaction Envelope Statuses

A transaction can have any of six different statuses.

Created: the transaction has been created
AwaitsSigning: the transaction has to be signed by the involved parties
Received: the transaction has been submitted and is being processed
Completed: the transaction has been successfully executed on the network
Failed: the transaction has failed on the network
Cancelled: the transaction was not submitted to the network, it cannot be retried

Transaction Signatures

The Algorand token implementation supports providing the signature for a transaction as a separate action. Once all required signatures are provided, Nexus will submit the result. Providing the callback URL in the submit signature request will move the submission to a background service. The callback URL will be used to provide the update on the status of the transaction once it has been submitted.