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.

Issuer Account

In Nexus we manage token issuing through issuer accounts, which are specialized accounts that hold the balances of native cryptocurrency required for token operations on the respective blockchain.

Token

A token is a digital asset that can be created to represent economic value tied to another asset. For instance, a token called BURGER could represent a digital payment method for food delivery services, with a fixed known value that can be used to pay for meals.

External Tokens

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

Setup Process: An external token can be set up by creating the token independently of Nexus, then adding it to Nexus through the portal by selecting the Add External button. During this process, Nexus requests the token's address, but the token's private key is never shared with Nexus.

Operational Implications: Since the private key is not stored within Nexus, all future transaction envelope signing required by the token must be done externally by the client, independent of Nexus.

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

Internal Tokens

A token is defined as internal within Nexus if the transaction envelope signing required by this token can be done internally by Nexus, due to its private key 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 through a two-step Define-Publish flow in the portal interface, or by calling our create token API for direct creation.

Portal Interface - Define-Publish Flow: When using the portal, the token creation process follows a two-step approach:

Define Step: Begin by selecting the create internal button in the portal. During this step, you specify all the token properties and configuration details. 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.
Publish Step: After defining the token, you proceed to publish it to the blockchain using the keypair generated in the Define step.

Draft State and Retry Capability: If the creation fails during the publish step, the token remains in a draft state. In this draft state, you can:

Edit the token properties and configuration
Retry the creation process by calling the publish operation again
Make adjustments to resolve any issues that caused the initial failure

API Creation: Alternatively, you can create tokens directly by calling our create token API, which handles the entire process in a single operation.

Once successfully published or created, the token becomes active and can be fully managed within Nexus. All future transaction envelope signing required by the token will be done internally by Nexus.

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

Importing an internal token

Import an internal token into Nexus by creating it independently of Nexus, then importing it into Nexus through the portal by selecting the import internal button.

Blockchain Support: Importing an internal token is supported for all blockchains except Stellar. The import process varies between blockchains due to their different architectural characteristics and account models.

Import Process: During the import process, Nexus first verifies that the token provided by the user exists on the respective blockchain. The specific steps then depend on the blockchain:

For Algorand: Nexus 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 Nexus, and to transfer the token's total supply to this new address. The private key of this new keypair is stored within Nexus.

For other blockchains (Ethereum, Ripple, ...): The import process is adapted to each blockchain's specific account and token management model. For example, Ripple/Xahau does not have native reserve accounts like Algorand, so the import mechanism works differently to achieve the same operational control while maintaining client ownership.

Post-Import Operations: After successful import, the token can be fully managed within Nexus. Importing an internal token means a token's creator and manager address will differ from the operational addresses controlled by Nexus, and that all future transaction envelope signing required by the token will be done internally by Nexus, while ownership of the token still sits with the client.

Client Token Ownership: Client token ownership means that the token's creator and manager address' private key is not stored within Nexus, and that the client retains the power to, at any stage, modify the token's operational control to remove any access which Nexus had to the token, and potentially clawback all tokens (depending on blockchain capabilities).

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

NOTE

Imported internal tokens support the separation of token ownership and operational token activities. This 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 operational control, to remove any access which Nexus had to the token.

NOTE

We provide separate command-line tools to allow for token creation independent of the Nexus platform for supported blockchains:

Algorand Token Creation (C#) - for Algorand blockchain tokens

These tools 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 a newly issued token whose value is pegged (linked) to another collateral asset. Common examples include metals (gold, silver) or fiat currencies (dollars, euro) as assets to which tokens are often pegged.

Currency-Pegged Token (CPT)

Fiat currencies are assets to which it makes sense to peg a token. The main advantage lies in the lower volatility that fiat currencies have compared to other cryptocurrencies (e.g. Bitcoin).

CPT Balance

Currency-Pegged token balance is calculated as tokens issued by the issuer minus tokens burned:

CPT balance = issued tokens - burned tokens

Asset-Pegged Token (APT)

Asset-pegged tokens are pegged to assets such as real-life paintings, physical items, or representations of things that have no specific monetary value requirement. These assets can either be controlled by Nexus or by external parties.

APT Balance

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

Stable Coin

A stable coin follows the same concept as a pegged token - it is a token whose value is linked to the value of a collateral asset (such as fiat currency or another token).

Taxonomy

Taxonomy can optionally be added to a token at the token creation stage. Since a token cannot be changed on the blockchain once it has been created, taxonomy provides a token on the blockchain with more meaning than just a code.

Schema Definition: To add taxonomy to a token, you need to define the set of properties your token must adhere to (called a schema). When you create your token, you specify the schema you created, along with a set of properties.

Validation and Hashing: These properties are validated against the schema and hashed using SHA256. This hash is stored encoded as a token property on the blockchain.

Alternative Hash Approach: Alternatively, you can provide a hash to store on the blockchain, instead of having to provide a taxonomy schema and properties to calculate one. Note that a provided hash is not validated in any way.

Asset URL: 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.

Verification: It is possible to verify that a token's properties have not been changed by using the hash.

Transaction Signatures

Internal Processing: Internal tokens and fee payer accounts' transaction signatures are internally processed in Nexus to simplify operations for our clients. This is possible because their private keys used for signing are stored within Nexus.

External Signing Requirements: For external tokens and customer accounts to consent to certain actions, signing a transaction with their private key is necessary. This cannot be done internally by Nexus, as their private keys used for signing are not stored within Nexus, and so must be done outside of Nexus.

Algorand Implementation: 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 updates on the status of the transaction once it has been submitted.

Transaction Envelope Statuses

A transaction can have any of six different statuses:

Confirming: The transaction requires additional confirmation before it can move to any other state
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 and cannot be retried